network-accessibility-analysis

ネットワークとアクセシビリティの分析

目的: 直線距離による推測を、ネットワークに基づく実際の移動コストへ置き換えること。適切なスケールで、速度と交通手段に関する誠実な仮定のもとで行います。あらゆるタスクにおける最初の判断基準: ユークリッド距離が許容されるのは、明示された近似としてのみです。それがアクセシビリティの代わりとして使われているのを見つけたら、必ずその旨を指摘してください。

スケール別のツール選択

スケール	ツール
近隣〜都市、研究上の柔軟性	OSMnx + NetworkX
都市〜地域、多対多のOD (>10⁴×10⁴)	r5py (GTFSを用いたマルチモーダル + 公共交通) または pandana (コントラクションヒエラルキーによる高速化)
本番用ルーティングサービス	Valhalla / OSRM / OpenRouteService API
プロプライエタリなスタック	ArcGIS Network Analyst (ヘッドレスでスクリプト化)

NetworkX はメトロスケールの多対多では処理しきれません。数千の起点に対して shortest_path をループさせないでください。ツールを切り替えましょう。

グラフの構築 (OSMnx)

import osmnx as ox

G = ox.graph_from_place("City, Country", network_type="drive")  # walk/bike/all
G = ox.add_edge_speeds(G)          # imputes from highway tags where maxspeed missing
G = ox.add_edge_travel_times(G)    # edge attr: travel_time (s)
G = ox.project_graph(G)            # metric CRS before any distance work

• network_type は重要です: drive グラフ上での歩行者分析は、小道、階段、広場を見落とします。all での走行は歩道を利用してしまいます。モードを一致させてください。
• 補完される速度は道路クラス別の平均値です。これはノイズではなく体系的なバイアスです。その旨を明記し、重要度が高い場合は既知のトリップに対してキャリブレーションしてください。
• ルーティングには強連結成分を保持してください (ox.truncate.largest_component(G, strongly=True))。孤立した島は誤った無限大を引き起こします。
• スナッピング: 起点/終点は最近傍のノード/エッジにマッピングされます (ox.distance.nearest_nodes)。スナップ距離の分布を報告してください。2 km 離れた場所 (河川敷、立入禁止区域) にスナップされた施設は、結果を気づかれないまま歪めます。

主要な成果物

• アイソクロン / サービスエリア: travel_time のカットオフによるエゴグラフ → 到達したエッジ周辺のアルファシェイプまたはバッファ付きエッジ和集合。ノードベースの凸包は、河川や高速道路をまたぐカバレッジを過大評価します。エッジベースのポリゴンを優先してください。仮定 (モード、速度モデル、カットオフ) は必ずラベル付けしてください。
• OD 行列: 多対多の移動コスト。アクセシビリティと施設配置の基盤です。大規模な行列には pandana/r5py を使用し、起点/終点の ID とともに Parquet として保存してください。
• 最近傍施設: ネットワークコスト (ユークリッド距離ではない) による k 近傍。割り当てられた施設とコストの両方を報告してください。
• 中心性: travel_time 上の媒介中心性 (大規模グラフではサンプリング k を使用。厳密計算は O(nm) です)。エッジ媒介中心性 ≈ 通過交通のポテンシャル。観測された交通量ではなく、ネットワーク構造として解釈してください。

アクセシビリティ指標 — 意図的に選択する

指標	答える問い	弱点
累積機会数 (T 分以内の雇用/POI数)	シンプルで伝達しやすい	T での崖。オール・オア・ナッシング
重力ベース (距離減衰和)	滑らかなアクセス	減衰パラメータを正当化する必要がある
2SFCA / E2SFCA	需給比によるアクセス (医療の標準)	商圏サイズの選択が結果を左右する
最近傍施設までの時間	最悪ケースのニーズ	容量/混雑を無視する

公平性分析では、指標を人口/人口統計ポリゴンに結合し (面積加重またはダシメトリック — geo-data-engineering を参照)、都市平均だけでなくグループごとの分布を報告してください。格差の統計的検定については spatial-statistics に回してください。

施設配置

OD 行列上の最適立地 (p-メディアン、最大カバレッジ): PuLP/OR-Tools で定式化します。入力は OD 行列 + 需要ウェイト + 候補地です。目的関数を明示してください。平均移動時間の最小化 (p-メディアン) と T 以内のカバレッジ需要の最大化 (最大カバレッジ) では異なる答えが出ますが、ステークホルダーはどちらを求めたのかほとんど把握していません。配置がネットワークアクセスと他の基準を組み合わせる場合は、結果を mcda-suitability-analysis にフィードバックしてください。

公共交通 (GTFS)

OSM + GTFS フィードで r5py を使用してください。結果は出発時刻に敏感です。単一の出発時刻ではなく、時間帯 (例: 07:00〜09:00 のパーセンタイル) にわたって計算してください。フィードを検証してください (分析日のカレンダーカバレッジに注意!)。期限切れの GTFS カレンダーは、もっともらしく見える徒歩のみの所要時間を生成します。

検証プロトコル

1. 3 つのルートを外部ルーター（Google/OSRM）と照合してスポットチェックします。誤差が約 20% 以内であること、またはその理由を説明してください。
2. 到達不能またはコストが無限大のペアをマッピングします。通常はスナッピングや接続性のアーティファクトであり、実際の到達不能ではありません。
3. 等時線を目視確認します。河川、高速道路、一方通行を正しく反映していますか？

落とし穴チェックリスト

• 「サービスエリア」として提示されたユークリッド距離バッファ。
• モードに対して誤った network_type。
• 障壁をまたいでしまう凸包の等時線。
• スナップ距離が未確認。
• 公共交通のアクセシビリティに対して出発時刻が 1 つだけ。
• 交通量として提示された媒介中心性。
• 度単位の CRS における OD 行列の「移動距離」。

実行契約

• ワークフロー： モード、時間、インピーダンス、出発地、目的地、公平性の問いを定義し、ネットワークを構築・検証し、入力をスナップし、ルートまたは行列を計算し、アクセスを要約し、検証します。
• 意思決定ルール： 制約のある移動にはネットワークコストを、観測されたトラックには移動分析を、アクセシビリティがより広い選好モデルにおける 1 つの基準となる場合にのみ MCDA を使用します。
• 検証プロトコル： 接続性とスナッピングを監査し、ルートをスポットチェックし、到達不能なペアをマッピングし、出発時刻またはインピーダンスの感度をテストし、OD の次元と単位を突き合わせます。
• 失敗モード： 非連結グラフ、誤ったモードまたはターンルール、期限切れの GTFS サービス、過剰なスナッピング、ユークリッド距離による代替、または不安定な出発時刻の結果については、アクセスの主張を保留します。
• 成果物： ネットワークの来歴、前提とコスト関数、ルートまたは OD 行列、等時線またはアクセス指標、到達不能ケースのレポート、検証の証拠、公平性に関する注意事項。
• ソースの鮮度： ネットワーク、GTFS、またはルーティング API を使用する前に権威あるソース登録簿を参照し、ソースの日付をアーカイブしてください。