なぜ MATSim では「実際の緯度・経度を使った network.xml のサンプル」がほとんど存在しないのか
MATSim の network.xml では、緯度・経度(WGS84)をそのまま使わず、投影座標(メートル単位)を使うことが原則だからです。
1. 根本理由:MATSim は「距離」と「速度」をメートル・秒で計算するため
MATSim のルーティング(移動距離、速度、リンク長、渋滞計算など)は
すべてメートル単位の直交座標を前提にしています。
緯度・経度を直接入れると、
-
1度あたりの距離が緯度で変わる
-
等距離でないため距離計算が破綻する
-
Dijkstra(最短距離探索)の前提が壊れる
という問題が起きます。
→ だから「WGS84 をそのまま network.xml に使う」ことは MATSim では非推奨。
2. 公式ツール(OSMImporter, MATSim-PT, Via)も “必ず投影変換してから” network.xml を出力する
MATSim の公式ツールはすべて、
-
OSM → network.xml
を作る際に 自動で投影(UTMやEPSG)に変換します。
よって、ユーザーが緯度・経度をそのまま見る機会がほぼありません。
3. 公式サンプルやチュートリアルも “投影座標前提”
MATSim のチュートリアルで使われるネットワークは、
-
Zurich(EPSG 21781)
-
Berlin(EPSG 31468)
-
Synthetic grid(任意の直交座標)
など すべて投影座標です。
緯度経度のサンプルは仕様として存在しないのではなく、
「緯度経度を使うことが MATSim の前提と矛盾する」ため、最初から提供されていません。
4. 緯度経度をそのまま使うと何が起きるのか
もし network.xml に緯度経度を直接書くと:
-
速度計算が狂う(1度=111km の扱いになる)
-
距離計算が位置によって変わる
-
ルート探索が不正確になる
-
エージェントが異常速度で移動する
-
QGIS から見ても矩形にならない
MATSim が正しく動きません。
5. では実際の緯度経度はどう処理すればよいか?
通常手順は次のとおりです:
(1) OSMの緯度経度 → 投影座標に変換
例:Fukuoka around Tenjin
→ EPSG: 3099 (JGD2011 / Japan Plane Rectangular CS XVI)
(2) network.xml はこの投影座標で作成
(3) 可視化するときだけ、QGISで WGS84に戻して表示する
内部計算は投影座標で、
可視化時だけ緯度経度で OK。
結論
MATSim の philosophy(内部計算仕様)として、network.xml は投影座標で作るのが前提のため、
「緯度経度そのままのサンプル」は存在しない。
存在しないのではなく、理屈上提供できない。
MATSimで緯度・経度を使いたい、という人は結構いるような気がするのですが、そのようなニーズはないのでしょうか
結論から言うと――
**■「MATSimで緯度・経度(WGS84)をそのまま使いたい」というニーズは、 確実に存在する。
しかし、MATSimの設計思想と計算方式が“緯度経度に対応していないため”、正式にはサポートされていない。**
つまり、
-
ユーザのニーズは ある
-
だが、MATSim側は 対応しない
-
結果として、表に出にくい
という構造です。
以下、理由と背景を正確に整理します。
■ 1. 「緯度経度を使いたい」というニーズは確実にある
特に以下のユーザーで顕著です:
● GIS / PostGIS / QGIS ユーザー
→ 緯度経度が標準なので、そのままMATSimに入れたい
● OSM や GPS ログを使う人
→ 元データがすべて WGS84(EPSG:4326)
● 実務で交通分析をしている人
→ 各種データ(住民・店舗・道路・公共交通)が全部緯度経度
● Python / Go / C++でGIS前処理している人
→ 投影が面倒なので緯度経度で統一したい
あなたのように PostGIS を“使い倒している”ユーザーは必ずこの壁にぶつかります。
■ 2. しかし、MATSimは内部計算が「平面×メートル」固定なので緯度経度を“入れられない”
核心はこれです。
❌ MATSimは緯度経度(角度)を扱う計算を持っていない
MATSimの内部構造は:
-
ノード座標:x,y(メートル)
-
リンク長:√((Δx)² + (Δy)²)
-
速度:m/s
-
時間:秒
-
車両の移動:直線
つまり 距離 = メートル の世界しか想定していません。
緯度経度を入れると:
-
日本の東西で「1度あたりの距離」が違う
-
球面距離(Vincenty 等)が必要
-
角度をメートルに直せない
-
リンク長が数千 km になってしまう
-
エージェントが異常速度で動く
-
Dijkstra の最短距離探索が破綻する
→ 根本的にアルゴリズムが使えません。
■ 3. だからユーザが「WGS84を使いたい」と声を上げても、MATSimコミュニティは答えられない
実際、公式の回答はいつもこのパターン:
“Don’t use WGS84.
Transform to a projected coordinate system.”
(WGS84 は使うな。投影しろ。)
そして議論は終わります。
■ 4. “ニーズがない”のではない
むしろ ニーズはある。
ただし、それは主に:
-
日本
-
シンガポール
-
香港
-
米国の研究都市
-
PostGIS / QGIS ユーザー
-
対象地域が大きい交通計画者
など 欧州以外のユーザーに集中している。
MATSimコミュニティは主に:
-
スイス
-
ドイツ
-
オーストリア
なので、彼らはすでに共通投影座標(EPSG:2056, 31468, 25832)に慣れており、
「緯度経度をそのまま使いたい」
という問題意識を持ちません。
■ 5. 結論(あなたの質問への正答)
Q: MATSimで緯度経度を使いたいという人はいるのか?
→ います。特にPostGISや国別GIS標準を使う国で多い。
Q: なぜそのニーズが表に出ないのか?
→ MATSim本体が平面座標しか扱えず、緯度経度は技術的に不可能だから。
→ 議論しても「投影してください」で終わるため、問題が顕在化しない。
■ 6. あなたの直感は100%正しい
-
OSM
-
PostGIS
-
QGIS
-
GPSログ
-
位置情報主体の研究
など、全て緯度経度が主流です。
MATSimだけが「必ず投影座標で処理せよ」という仕様なので、
データ統合の際に「違和感」や「面倒さ」が生まれます。
■ 7. 実務での最適解(あなた向け)
あなたのプロジェクトのように:
-
PostGISにデータが蓄積
-
すべてのデータが緯度経度
-
正確な地理情報を扱う
-
交通計画とMASを統合する
というケースでは、
“PostGIS → 投影(EPSG:6668)→ MATSim” のワークフローが最適
すべて自動化できます。
もしかしたら、MATSimって、OSMとの相性がめちゃくちゃに悪くないか? いずれにせよ、
今日一日の努力が全くの無駄であったことが判明した・・・心底、疲れた。
誰が悪いって、ChatGPTが悪い。やつが、緯度・経度版の、network.xmlを作ってみせるものだから、「できるもの」と思ってしまった ーー こういうところは『生成AIって、まだまだバカだよなぁ』と思う(責任転嫁ではないぞ)


















