GRASSを使ったネットワーク解析について

[ryory...@gmail.com]

「ネットワーク分析・GISオープン教材」と調べれば出るサイト（URLを張るとnot foundになるためサイト名で）を参考にネットの分割を試しているのですが、うまくいきません。

ある点から100ｍ、200ｍ、300ｍ、400ｍ、500ｍという風に、ある点から任意の距離にある道路を出したいのですが、分割されずに入力した道路データがそのまま出てしまいます。

この方法でつかうベクタデーターには絶対に含まれていなければならない属性データなどはあるんでしょうか？

使っている道路データは空間データ基盤25000に収録されている道路データです。

使用環境

Windows10

QGIS2.18.21

[yoh_chan]

こんにちは。

参考のサイトはこちらでしょうか。

http://bit.ly/2OZTat2

あまりQGISからはGRASSを利用しないのですが、いくつか原因になりそうなこととしては、

①CRSが地理座標系になっている（緯度経度になっている：例えばJGD2000：EPSG4612とか）

②カテゴリの指定が違う（参照サイトでは「1」になっていますが、中心とする点のカテゴリ値がそうでないかもしれない）

③GRASS内でベクトルデータにカテゴリが設定されていない

といったところでしょうか。

まずは①のCRSを確認してみてください。

[ryory...@gmail.com]

分作成途中で投稿してしまいましたすみません。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

コメントありがとうございます。

色々試しているのですが、いまだ解決に至っておりません。

画像の場合カテゴリの指定は「1」でよいのでしょうか？

右の「Not enough・・・・」を見る感じ、ポイントの指定がうまくできていないような気がしています。

また、もしQGISのGRASSを使用しない方法があるのでしたらそちらのやり方も検討したいため、教えていただけないでしょうか？

[shamro...@gmail.com]

こんばんは

使っているバージョンが2.18のようですね。

それでは Processing toolbox を使って処理してみてはいかがでしょうか。

yoh-chanさんのご指摘通り

データを同一のCRS かつ 単位が m のもの(例えばUTMや平面直角座標系)にそろえられているのであれば

添付した画像の通り

1) v.net.connect

2) v.net.iso

処理を順に実施してみることをお勧めします。

(v.net.connectのThreshold for connection distance を 500mと大きな値にしていますが

これはとりあえずすべてのポイントデータを無理やりネットワークにつなげるために

設定したものです)

ご利用のデータである空間データ基盤25000は所有していませんが

http://www.gsi.go.jp/common/000075438.pdf
上記の資料の通り対応している数値地図（国土基本情報）にある道路中心線(RdCL)データで

同じ処理を実施し期待した通りの結果が得られています(OSMでも同様です)

また属性については単純に各フィーチャにIdを振っただけのものでも

実施しましたが、得られる結果は同じです。

よって少なくともお示しいただいた資料と同等の結果を得るだけであれば

特に気にしなくてもよいように思います。

ではでは。

[ryory...@gmail.com]

詳しい解説ありがとうございます。

しかし、いまだ解決するに至っておりません...

QGISの基礎をしっかり学んではいないため、もっと根本的なところが間違っているのではないかと思い、僕が実際にやっている工程を説明いたしますのでもし間違っている箇所があればご指摘願います。

QGISでGRASSを用いて分割をする方法とProcessing toolboxを用いて分割する方法に挑戦してみました

GRASSを使うやり方では明らかに違うものが出てきているような気がします。

ーーーーーーーーーーーーーGRASSを使う方法ーーーーーーーーーーーーーーーーーーーーーー

1.使用するデータはこの2つでCRSはEPSG:6691、JGD2011/UTM zone 54Nに設定してあります。

2.新しいマップセットを作成します。ここでも投影法を「EPSG:6691、JGD2011/UTM zone 54N」に設定。

3.GRASS領域をJapanで設定。

4.v.in.org.qgisでpointとroadのレイヤを読み込む。

5.v.netでconectする。

6.v.net.isoで分割する。

7.処理を終えたsplit_roadを表示させてみる。

ーーーーーーーーーーーーーProcessing toolboxを使う方法ーーーーーーーーーーーーーーーーーーーーーー

1.pointとroadを読み込む。CRSはEPSG:6691、JGD2011/UTM zone 54N

2.v.net.conectを実行。（出力されたレイヤは「Network」）

3.v.net.isoを実行

4.Network＿ISOが出力された。

[AAEE]

スレッドをざっと流し読みした程度で状況をしっかり把握していないのですが、

v.net.isoを実行すると、ぱっと見は入力と同じデータが出力されますが、100m・200m・300m…を分類する属性値が付与されているはずです。

出力データの属性テーブルを確認してみてください。

見当違いの回答かもですが・・・。

[yoh_chan]

こんにちは。確認が遅くなってしまってすみません。

すごく詳細にキャプチャを送ってくださってありがとうございました。

まず、shamrock3ireさんご提案のProcessing Toolboxの結果、貼付していただいたキャプチャを拝見しましたが、AAEEさんのおっしゃる通りちゃんと出力されているのでは…？という気がします。得られたNetwork_Isoの属性テーブルを確認してみていただければと思います。

GRASSツールを利用した方ですが、v.net.isoの設定（7番目のキャプチャ）が間違っていると思います。

「ノードを入力する」の部分の指定を（Input arcsと同じ）「Conect_raod」にしてみてください。

GRASSは、一つのデータに異なる種類のジオメトリ（ポイントとかポリゴンとか）を持つ複数のレイヤを持つことができます。v.netでconnectを実行する際に、「Arc レイヤー：1」「ノードレイヤー：2」とあるのはそういう意味です。

なので、v.netを使って生成した「Conect_raod」も、レイヤ1に道路線を、レイヤ2に今回接続した点を持つデータの両方を持っています。

左のブラウザパネルから今回のロケーションを作成した場所をたどってみると、GRASSにインポートされているレイヤを確認することができます。（参考キャプチャを添付しました。）

> また、もしQGISのGRASSを使用しない方法があるのでしたらそちらのやり方も検討したいため、教えていただけないでしょうか？

言葉足らずでごめんなさい。

QGISのGRASSツールは、GRASS GISというソフトの解析機能を利用できるもので、バックグラウンドでGRASS GISが動作しています。このQGISのGRASSツールが使えるということは、GRASS GISがスタンドアローンでもインストールされていると思うので、こちらを利用することもできるということです。

ただGRASSの機能を使っていることは同じなので、今回は敢えてGRASSのスタンドアローンを利用する必要はないと思います。

[ryory...@gmail.com]

皆様ありがとうございます。

何とか分割することに成功しました。

返信してくださった皆様本当にありがとうございます。

分割することができたのですが、また1つ疑問が出てきました。

今回、最終的にはProcessing Toolboxを用いて分割処理を行いました。

これには理由があり、また疑問点でもあります。

GRASSを使った方法でv.net.isoを実行するとき、100mごとに分割したかったため100、200...と入力していましたが属性テーブルを見たところ「1」しかありませんでした。

そこで1、2...と入力値を変え実行してみたところ何とか「2」まで現れるようになりました。ここで初めてm単位ではないと気付きました。

GRASSを使う方法のv.net.isoでは0.1など入力することができなかったため、Processing Toolboxのv.net.isoで0.001、0.002...と入力していったところやっと100mごとに分割されたデータが出力されるようになりました。

CRSによっては単位が変わってくるのでしょうか？

今回設定したCRSはUTM Zone 54Nでした。

[AAEE]

UTM Zone 54Nは緯度・経度を用いる座標系（地理座標系）です。

今回はメートル単位で分割したいということですので、入力データをメートル単位のデータ（投影座標系）にあらかじめ変換しておく必要があります。

100mが何度になるかは緯度によって異なります。また、0.001と入力して100mごとになったとのことですが、厳密に計測するとぴったり100mにはなっていないと思います。

参考：http://source.hatenadiary.jp/entry/2013/07/08/144118

[AAEE]

度々すみません。補足です。

上に書いたとおり、入力データをメートル単位のデータ（投影座標系）に変換しておけば、

素直にパラメータを100,200,300,...として希望どおりの結果が得られるはずです。ご確認ください。

[adachi]

投稿された画像を拝見して、

QGIS画面下のバーで「CRSが6691（投影座標系）になっているのに表示位置が明らかに緯度経度の数字になっている」のが気になりました。

（>AAEE様　私の認識ではUTMは地理座標系ではなく投影座標系のはずですが、もし誤ってましたらご指摘ください）

想像ですが、

・緯度経度座標系で作られたはずのデータ（道路等）を読み込む際に、無理やり「このデータのCRSは6691ですよ」と指定してしまった

あるいは

・読み込んだあと、レイヤプロパティの画面からCRSを6691に変更した

のではないかな？と思います。

ネットからダウンロードしたデータを含め、既成のベクタデータ等はすでに「このデータは◯◯座標系で作られました」というのが決まっており

読み込む際にそれを適切に指定する必要があります（例えばOpen Street Mapであれば地理座標系の「WGS84」など）。

適切に読み込んだあとCRSを変えたい場合には、レイヤパネル上で対象データを右クリック→名前をつけて保存する

の画面で、ご希望のCRSに変換してやる必要があります。

まずは、もとデータがどのような座標系で作られたのかを探ってみてはいかがでしょうか。

想像したまま書いてしまいましたが、見当違いでしたらご容赦ください。

[wata909]

よこからすみません。座標系についてですが、UTM54は投影座標系ではないでしょうか？

以下、参考に

http://d.hatena.ne.jp/tmizu23/20091215/1260868350

[wata909]

こんにちは、

処理を見ていると、UTM54に設定されているようです。

ですが、読み込んでいるデータはいかがでしょうか。

たとえば、JGD2011のデータを使っている場合、GRASSの処理するときの座標系をUTM54に設定しても、投影変換は行われず、

緯度経度の座標値を持ったまま、UTM54として処理されます。

ですので、まず初めにUTM54に座標変換して、それから処理を行うと良いかもしれません。

[wata909]

あ、かぶりました（汗

ご指摘の通り、読み込む段階で6691にしているだけ、つまりprjファイルが無い可能性もありますね。

国土地理院のデータだと、JGD2000（時期によってはJGD2011）で読み込んで、その後UTM54に変換すると

いいのでしょうね。

[AAEE]

adachi様、wata909様のご指摘のとおりUTMは投影座標系で、私の勘違いでした。ご指摘いただきありがとうございました。

お二人のご回答のとおり、入力レイヤのCRSを適切に変換・設定してあげれば解決すると思います。

[yoh_chan]

こんにちは。

みなさまからの返信でほぼ解決済みだと思いますが、わたしも読み込み時のCRSの認識違いの問題と思います。

お使いのデータ

> 空間データ基盤25000に収録されている道路データ

ですが、以下の国土地理院のページから「ファイル仕様」のpdfファイルを確認すると「座標参照系は、参照系識別子 : JGD2000 / (B,L)を参照する。」とあります。

> http://www.gsi.go.jp/geoinfo/dmap/dm25ksdf/index.html

(B,L)というのは、緯度経度座標のことなので、これは「JGD2000の地理座標系で作られたデータです」という意味です。

したがって、QGISにデータを読み込む際にEPSG4612で読み込みをする必要があります。

その後、みなさまのご指摘のようにデータを保存して、投影座標系（EPSG6691など）に別名で保存して、これをGRASSに読み込む必要があります。投影変換をしないままGRASSにデータを読み込むと、GRASSのロケーションが正しく設定されていても、それに合わせて再投影をしてくれるわけではないので、やはりおかしなデータになってしまいます。

（再投影しつつGRASSにデータを読み込むv.importというコマンドもありますが、この機能はQGISのGRASSツールからは利用できません。）

ので、手順としては、

１）QGISに正しいCRSで道路データを読み込む

２）レイヤの「名前をつけて保存」から、投影座標系に設定したデータを別名保存してQGISに再度読み込む

３）v.in.ogr.qgisを利用してGRASSへ読み込む

（processing toolboxを利用する場合も、２までの操作は必要です。）

とすることで、うまくいくと思います。

お試しくださいませ。