Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie PosGIS/pgRoutingとRの連携による道路ネットワーク分析（埼玉大学・国府田様）
Ähnlich wie PosGIS/pgRoutingとRの連携による道路ネットワーク分析（埼玉大学・国府田様） (20)
Mehr von OSgeo Japan
Mehr von OSgeo Japan (20)
PosGIS/pgRoutingとRの連携による道路ネットワーク分析（埼玉大学・国府田様）
- 1. 2012.11.04 Tokyo Road Network Analysis Using Combination of PostGIS/pgRouting and R PostGIS/pgRouting と R の連携による 道路ネットワーク分析 国 府 田 諭（埼玉大学環境科学研究センター研究員） Kouda Satoshi
- 2. ● 報告の内容 1. まず実例から 構築した道路ネットワーク分析システムの利用例 ▼ 2. 本システムの考え方 デスクトップアプリとは違う スクリプティング GIS 」 「 ▼ 3. 技術側面 とくに PostgreSQL / PostGIS と R の連携について ▼ 2
- 3. まず実例から 基本テスト：二点間の最短経路探索 ▼ 応用①：駅から各種施設への道路距離 ▼ 応用②：道路ネットワークの密度評価 ▼ （いずれも Windows XP 上での動作例） 4
- 4. ● 基本テスト：二点間の最短経路探索 PostgreSQL に付属する クライアントツール ① pgAdmin Ⅲから ② R スクリプトを起動 ③ PDF 表示が終了の合図 5
- 5. ● テスト結果を PDF で自動保存、開く 6
- 6. ● テスト結果をテーブルでも自動保存 pgAdminⅢから 直接テーブルの中身を確認 7
- 7. ● テスト動作の流れ ク デ R ラ ー で イ タ 直 テスト用の R スクリプトを作成（二点の地理座標入り） ア ベ に ン ー 実 ト ス 行 ツ 作 し R スクリプトを PostgreSQL 内に文字列として保存 ー 業 て ル 中 も か い よ ら つ い pgAdmin Ⅲから R を起動し、スクリプトの中身を渡す 実 も が 行 開 、 で い き て 、 い R と PostGIS/pgRouting の連携で、最短経路を探索 便 る 利 探索結果を PostGIS テーブルと PDF に保存 pgAdmin Ⅲ用 のプラグインを 自作 R スクリプトから PDF を開く 8
- 8. ● テスト結果 PDF の表示内容 起点・終点 経路探索に使用した 手法・アルゴリズム別の 道路距離 使用した地図別の結果 （ここでは OpenStreetMap の二つの時期） 9
- 9. ● テスト結果 PDF の表示内容（続き） 全ての探索手法・アルゴリズム別に地図を作成。違いを確認できる 10
- 10. ● 経路探索の手法・アルゴリズム pgRouting R の igraph 自作の関数 （PostGIS 拡張） パッケージ （PostGIS 2.0 上） 機能、柔軟性を 得るため独自開発 ・pgRouting PostGIS のバージョンに 制約。機能が少ない ・R の igraph 本来、抽象的な「グラフ 理論」での利用が主。 地理データとの連携には アルゴリズム 2 種 アルゴリズム 3 種 手間が多い 11
- 11. ● 手法・アルゴリズム間の差は少ない 全ての手法・アルゴリズムの経路を重ねている。 経路の差が出れば一目で分かる。 結果の道路距離も が、そういう例はめったになかった。 同じ場合がほとんど 12
- 12. ● 独自開発に至った一つの理由 実際の経路探索は「ノード間の最短経路」だけでは不足 起終点 ⇒ アクセスできる道路 ⇒ ノード の距離を考慮した最短経路探索が必要 例（右図） A … 起点から最も近い道路を使う B … 2 番目に近い道路を使う B C … 最も遠い道路を使う 終点に最も近いのは C しかし実際に道路に出れるか不明 C A 起点 終点↙ 13
- 13. ● 自作関数での処理 ・ 起終点から「アクセスできる道路」の範囲（下の赤い円）を 自由に設定可能にする ・ 起終点から「接続できる全てのノード」を抽出し、 ノードまでの距離を考慮して最短経路を探す 例（右図） Y A 、B… 設定された範囲内なので 起点から使える道路とする B X C … 範囲外なので使わない 起点とノード X、Y までの距離を 考慮して最短経路を探索する C A 起点 終点↙ 14
- 14. ● 独自開発に至ったもう一つの理由 最短経路探索では、起点と終点が確定している場合しか 使えない 起点のみを決め、「道路距離で○○メートル行ける範囲」 を算出できれば、さらに有用と考えた ● 現在の到達点 探索結果の比較から判断すると、pgRouting、igraph と ほぼ同じあり、実用的と言える。 ⇒ 以下の応用例では、すべて自作関数を使っている 15
- 15. ● 応用①：駅から各種施設への最短道路距離 ① pgAdmin Ⅲから ② R スクリプトを起動 ③ PDF 表示が終了の合図 16
- 16. ● 半径 1.5km 内での探索結果 ・色別の円 … 施設種類（大分類）ごとの位置 ・赤い線 … 各施設への最短経路 三国駅（福井県、えちぜん鉄道） 三国駅（大阪府、阪急電鉄） 17
- 17. ● 対象駅ごとに PDF の 1 頁で出力 18
- 18. ● 施設の大分類別の集計、直線距離との関係 三国駅（福井県、えちぜん鉄道） 三国駅（大阪府、阪急電鉄） 19
- 19. ● 応用②：道路ネットワークの密度評価 ① pgAdmin Ⅲから ② R スクリプトを起動 ③ PDF 表示が終了の合図 20
- 20. ● 起点から道路距離 1.5km 以内の全経路 ・ 中心 … 三国駅（大阪府） ・ 赤い線 … 中心から道路距 離 1.5km 以内の全経路 ・ 経路から両側 20m のバッ ファを作成（白い縁） ・ 外側の線…各経路の終端を 結ぶ凹包 （PostGIS の ST_ConcaveHull 関数で作成） 直線距離で描いた円に対し、 かなり均等に経路が伸びている 21
- 21. ● 道路からのバッファに含まれない区画の分布 ・ 中心から道路距離 1.5km 以内の凹包の中で、道路から両側 20m のバッファに含まれない全てのポリゴンを抽出。 ・ ポリゴンの面積と、中心からの距離の関係を散布図にした。 （面積は大小の差が大きいので対数値） 駅から離れても大区画 （道路密度が低）が多くなっていない 22
- 22. ● 今後の応用、拡充について ・各種施設への道路距離 今回の例では「見た目の分かりやすさ」から駅を起点に したが、住宅地からの評価も重要。今後取り組みたい。 ⇒ 例えば、住宅地から歩いてアクセスできる生鮮食料品店 が消滅する「フードデザート問題」の考察など。 ・システムの拡充 現状、道路ネットワークデータは OpenStreetMap のみを 用いており、データが少ない地方部には使えない。 ⇒ 今後は、他の道路データと、様々な施設データを用いて、 より広い範囲を対象にしたい。 23
- 23. 本システムの考え方 デスクトップアプリとは違う ▼ 「スクリプティング GIS 」について
- 24. ● データが多い、だけじゃない現状 様々な 大量の 様々な 様々な 計算方法と データ 組み合せ 分析手法 パラメータ ピンポイントでデータを扱うには、デスクトップアプリが便利だが （本システム構築でも、データチェックに QGIS を多用） しかし、使えるデータと分析手法を最大限に活かすには デスクトップ 外注や プログラミングによる アプリでは 人海戦術の 連続・一括・自動処理で 限界がある… 予算なし… 実現を模索してみた 25
- 25. ● PostgreSQL / PostGIS と R の連携へ 様々な 大量の 様々な 様々な 計算方法と データ 組み合せ 分析手法 パラメータ データベースへのクエリ 何らかの統計処理言語 ⇒ 地理情報も扱うなら ⇒ オープンソースなら R PostGIS が定番 ・グラフや地図プロットもできる ・外部プログラムも実行できる それなら、全体を R スクリプトで制御するのが効率的 27
- 26. ● スクリプティング GIS の利点と目的 シ 全ての処理過程がテキストで記録されている ス テ ▼ 似た処理の複製が容易 ム ▼ 上 複数スタッフ間の処理の共有、継承、カスタマイズが容易 ▼ の 利 処理の所要時間を記録でき、予測も容易 ▼ 点 途中の処理ミスがあった場合、修正と再実行が容易 ▼ 手作業では不可能な量・質の分析を気軽に実行し、 目 ▼ 新たな事実発見や仮説構築につなげる 的 マウスやメニュー画面操作の時間を減らし、 ▼ 人による思索と分析の時間を増やす 29
- 27. 本システムの技術側面 構成要素（ソフトウェア） ▼ PostgreSQL / PostGIS と R の連携 ▼ 処理の流れ ▼
- 28. ● 構成要素の一覧、利用バージョン 作業フォルダ プログラム R スクリプト本体 R 2.15 パッケージ igraph、maptools psql PostgreSQL に文字列で PostgreSQL / 格納し、pgAdmin Ⅲから PostGIS に付属 起動する方法もあり pgsql2shp pgAdmin Ⅲ データベースサーバ PostGIS 2.0 PostGIS 1.5 （道路データ） （pgRouting + dblink） PostgreSQL 9.1（on Windows XP SP3） 31
- 29. ● PostgreSQL / PostGIS と R の連携の要 コ マ データベースにクエリを行い、 ン psql.exe 結果を標準出力 or ファイル出力 ド （PostgreSQL に付属） ラ イ ン ツ PostGIS のテーブル or クエリ結果を ー ル pgsql2shp.exe シェイプファイルに出力 （PostGIS に付属） ともに、R から外部プログラムとして実行。 結果を標準出力 or ファイルから取り込む 35
- 30. ● コマンドラインより効率的な方法は？ PostgreSQL 内のユーザ定義関数として R の機能を導入可 PL / R システム全体の制御は難しい ▼ PostgreSQL に接続する RpgSQL 等がある R パッケージ 今回の環境では接続できず ▼ PostgreSQL 用ドライバ、R のパッケージ（RODBC）あり ODBC データソースの設定・管理が面倒 ▼ 直接の連携は、コマンドラインでの どのみち R と PostGIS は シェイプ出力経由しかない 本システムは、コマンドラインでの連携に統一 42
- 31. ● 処理の流れ ① 起終点を含む道路データ取得、 全 道路データを「リンクとノード」形式に変換 体 を 一 PostGIS あらかじめ、起終点を引数に一括で処理する つ ユーザ定義関数を作成しておき、実行 の R ス ② 経路探索を実行 … 三通りの手法 ク リ Rと PostGIS で プ pgRouting igraph パッケージ 自作した関数 ト で 実 行 ③ 結果保存 Rと シェイプ出力 pgsql2shp 地図プロット maptools パッケージ 44
- 32. ● 処理の流れ … PostGIS 内の処理を統合すれば ① 起終点を含む道路データ取得、 全 道路データを「リンクとノード」形式に変換 体 経 起 を 路 終 一 PostGIS あらかじめ作成したユーザ定義関数 探 点 つ 索 を の + が 渡 R 完 す ス pgRouting 了 ク ② 経路探索を実行 す エ ク または自作の る リ リ 経路探索関数 一 プ 回 ト で で 実 行 ③ 結果保存 Rと シェイプ出力 pgsql2shp 地図プロット maptools パッケージ 49
- 33. ● 構成要素と処理のまとめ システムの中心 ▼ （道路データ取得、経路探索、結果保存） PostGIS の役割 全処理をユーザ定義関数で一元化 ▼ （起終点座標のクエリ 1 回で済む） R ⇒ PostGIS 起終点座標のクエリ（psql） ▼ アクセスは最小 2 回 結果のシェイプ出力（pgsql2shp） ▼ 全体の制御（含 : PostGIS へのクエリ） ▼ R の役割 結果の出力（含 : シェイプを取り込んで地図化） ▼ さらなる処理（分析、グラフ化など） ▼ 50
- 34. ● 最後に：本システムを可能にしたもの PostgreSQL ▼ PostGIS ▼ 偉大な OSS 群 pgRouting ▼ R とパッケージ igraph, maptools ▼ 全国規模の道路データが無償で使える ▼ OpenStreetMap データ整備が急速に拡大中 ▼ 多数の解説と とくにウェブ上のリファレンスとブログ。 利用事例 これ無しでは、本システムはできなかった これら全ての関発者・関係各位に深く感謝します 51
- 35. 以上です。ご清聴ありがとうございました。 本発表に関する連絡先 ▼ 国府田 諭 / satkouda@gmail.com