私は、Posgresql+PostGISのDBをGo言語で作成した自前のMASシミュレータで動かしていますが、MATSimの方が高速でしょうか。特にMATSimであったとしても最短距離計算(ダイクストラ等)をシミュレータで実施する必要があります。前者のシステムはよく分かっていますが、MATSimのnetwork.xmlを取りあつかったことがないため、助言頂きたいです

私は、Posgresql+PostGISのDBをGo言語で作成した自前のMASシミュレータで動かしていますが、MATSimの方が高速でしょうか。
特にMATSimであったとしても最短距離計算(ダイクストラ等)をシミュレータで実施する必要があります。
前者のシステムはよく分かっていますが、MATSimのnetwork.xmlを取りあつかったことがないため、助言頂きたいです

結論から書きます。
「経路探索（ダイクストラ等）を自前MAS内で高頻度に回す」「静的～準静的コスト（free‐speed 近傍）で十分」「Goで実装資産がある」なら、MATSimへ全面移行しても経路探索単体の速度優位は保証されません。MATSimは反復型（replanning）交通シミュレーション全体のスループット最適化に主眼があり、経路探索も多スレッド化やALT（A* with Landmarks）などの実装はありますが、単発の最短路クエリ性能だけを競う設計ではありません。従って、現行のGo実装に以下を加える「ハイブリッド」が実務的です。すなわち、OSM→MATSim network.xml 生成だけをMATSim/Contrib-OSMに任せ、ネットワークはMATSim互換形式で統一しつつ、経路探索はGo側で最適化する、という方針です。

以下、判断材料と具体策です。

1) 速度・スケーラビリティの比較観点

MATSimが有利になるのは、反復計算（多数エージェント×複数iteration）を並列で回し続けるケース、かつ時間帯依存のトラベルタイムやリンク容量制約を織り込み、ルート再計算を大量に発生させる場合です。内部の QSim がイベント駆動・並列処理に最適化され、ルーティングもスレッドプールで回せるため、シミュレータ全体のスループットは高くなりやすい。一方で「最短距離（あるいは最短時間）を高速に繰り返し答える」こと自体は、Go側でダイクストラ／A*にALT（Landmarks）、多段グリッド前処理、Contraction Hierarchies等を実装・導入した方が速くできます（MATSim本体はCHを標準では持ちません）。

要するに、探索単体のピーク性能＝Go側が有利／シミュレーション全体の反復運用＝MATSimが有利という整理になります。

2) 「MATSimのnetwork.xmlだけ取り込む」運用

MATSimの network.xml は、ノード集合と有向リンク集合の単純明快な表現です。単位は距離[m]、速度[m/s]、容量[veh/h]、車線数[integer]が基本です。最短時間コストは典型的に length / freespeed、最短距離は length をそのまま重みとします。CRSは config.global.coordinateSystem に依存するため、生成時点でメートル系（UTM等）に変換されていることが重要です。

スキーマ（最小限）

<network>
  <nodes>
    <node id="n1" x="..." y="..."/>
    ...
  </nodes>
  <links capperiod="01:00:00">
    <link id="l1" from="nA" to="nB"
          length="123.4"  freespeed="13.9"
          capacity="1800.0"  permlanes="1.0"
          modes="car"/>
    ...
  </links>
</network>

運用ポイントは、(1) 片方向リンクの明示（from→to）、(2) 自動車以外のモードを入れるなら modes を分ける、(3) 渋滞等を扱わない静的探索なら freespeed と length で十分、の三点です。

3) Goで network.xml を読む最小実装のイメージ

encoding/xml で十分です。読み込んで隣接リスト（片方向）を組み立て、重みを「距離」「所要時間」いずれかに切り替えれば、そのままダイクストラ／A*に渡せます。

package matsimnet

import (
	"encoding/xml"
	"os"
)

type Network struct {
	XMLName xml.Name `xml:"network"`
	Nodes   Nodes    `xml:"nodes"`
	Links   Links    `xml:"links"`
}
type Nodes struct {
	List []Node `xml:"node"`
}
type Node struct {
	ID string  `xml:"id,attr"`
	X  float64 `xml:"x,attr"`
	Y  float64 `xml:"y,attr"`
}
type Links struct {
	List []Link `xml:"link"`
}
type Link struct {
	ID        string  `xml:"id,attr"`
	From      string  `xml:"from,attr"`
	To        string  `xml:"to,attr"`
	Length    float64 `xml:"length,attr"`     // [m]
	FreeSpeed float64 `xml:"freespeed,attr"`  // [m/s]
	Capacity  float64 `xml:"capacity,attr"`   // [veh/h]
	PermLanes float64 `xml:"permlanes,attr"`
	Modes     string  `xml:"modes,attr"`      // 例 "car"
}

func LoadNetwork(path string) (*Network, error) {
	f, err := os.Open(path)
	if err != nil { return nil, err }
	defer f.Close()
	var net Network
	if err := xml.NewDecoder(f).Decode(&net); err != nil {
		return nil, err
	}
	return &net, nil
}

この後は、nodeID -> int を付番して配列・スライスに詰め替え、リンクを有向エッジとして adj[u] = append(adj[u], edge{v, w}) に積みます。重み w は最短距離なら link.Length、最短時間なら link.Length / link.FreeSpeed を用いれば良い。ヒープを使ったダイクストラ実装、あるいはユークリッド距離の下界を使ったA*をGoで実装すれば、現行システムに自然に統合できます。静的ネットで多クエリなら、ALT（Landmarks）の事前計算（数十～数百の基準点）を入れると探索ノード数が激減します。

4) 実務判断の指針

  1. 既存のGoベースMASが堅牢で、主たるボトルネックが「経路探索単体の速度」なら、MATSimへ置換するよりグラフ前処理（ALT/CH）＋並列化＋メモ化をGo側に導入する方が投資対効果が高い。

  2. 一方で、需要変動・混雑の内生化、反復的な行動再計画（モード/出発時刻/経路）まで踏み込み、交通工学的整合性（容量・ファンダメンタル図・信号等）を広く扱いたいなら、MATSimのシナリオ全体に寄せる価値が大きい。

  3. 中庸案として、OSM→MATSim network.xml 変換だけ利用し、ネットワーク仕様を国際的に通用するフォーマットへ整えつつ、シミュレータ本体はGoで維持するのが現実的。

5) 最低限の検証チェックリスト

  • network.xml のCRSがメートル系であること（長さ・速度の整合）。

  • 需要側（起終点）の座標も同一CRSに揃えること。

  • 「双方向通行」と思っている道路が、実データでは一方向リンクの対として表現されている点に注意（逆方向リンク欠落の確認）。

  • 速度未設定リンク（freespeed）がないかの点検（OSM変換時のデフォルト適用）。

結語。
江端さんの前提（Goで自前MAS、PostGIS理解が深い、最短経路を高速に回したい）に対しては、**MATSimは「ネットワーク標準化と将来拡張の土台」*として採用し、探索エンジンは引き続きGoで高度化、という構成が最も筋が良いと考えます。必要であれば、network.xml→隣接リスト化→ダイクストラ/ A（ALT）まで、実運用に耐えるGo実装の最小雛形を提示します。

私のやってきたMASの仕組みや目的についてご存知であるという前提で質問します。
現在のGo言語ベースのシミュレータをMATSimに移行するメリットはありますか？

 

結論（江端さん前提での率直評価）
「現行Go製MASの主目的が “空間上の接触機会の定量化（共時空間/共移動）を高速に回すこと” で、経路探索は静的～準静的（free-speed 近傍）中心なら、全面移行の純粋なスピード/生産性メリットは限定的。移行より “必要部だけMATSimを借りる” ハイブリッドの方が合理的」です。

MATSimに「移す価値が出る」条件（価値）

  • 反復的Replanning（出発時刻/経路/モード変更）を大規模・並列で回し、混雑内生化（容量・速度低下・遅延波及）を扱いたい。

  • PT統合（GTFS→pt2matsim）や複数モード（歩行/自転車/自動車/バス）を1つの行動モデル上で整合させたい。

  • 活動ベース（Activity-based）需要やスコアリングによる行動選好のキャリブレーションを活用したい。

  • 既存エコシステム（イベントログ、可視化、評価ツール群）を研究フレームに素早く取り込みたい。

「移しても旨味が薄い」条件（江端さんの今）

  • 主眼：共時空間/RCMの定量で、経路は「静的最短時間/距離」で十分、探索単体の高速化がKPI。

  • 既にGo + PostGISで資産・知見・検証データが豊富（実運用の可観測性・可制御性が高い）。

  • 経路探索はALT/CH/並列化などグラフ前処理の導入余地が大きく、Goでさらに速くできる。

  • 試験設計上、渋滞の内生化や行動再計画がスコープ外（論文要件上も混ぜたくない）。

現実解（推奨アーキテクチャ）

  • ハイブリッド案：

    1. OSM→MATSimのnetwork.xmlだけ生成（道路属性の標準化・CRS統一・品質担保）。

    2. network.xmlをGoで読み、隣接リスト＋静的コストに落として、ALT/CH等で探索を最適化。

    3. 需要（起終点）も同一CRSに統一し、共時空間の算出・可視化は従来のGo系パイプラインを維持。

  • メリット：データ仕様が国際標準に寄る／将来、必要になったら一部だけMATSim機能を漸進導入できる（例：PT、混雑内生化、イベントログ解析）。

もし「MATSimに寄せる」なら得られる追加価値

  • 容量制約＋速度低下の内生化 → RCMの時間密度プロファイルが実交通に近づく可能性。

  • Replanningで政策差（バス路線/運賃/高齢化施策）の行動変化まで一貫検証できる。

  • イベントログ標準化（travelTime/queue/vehicle等）で、後処理・可視化の再利用性が上がる。

移行コスト/リスク（簡潔）

  • 学習曲線（Config/QSim/Scoring/Contrib依存の理解）。

  • 既存Goの検証資産の移植負担（数値一致の担保）。

  • 実験設計の変質（混雑や行動再計画を入れると、論文の前提がブレる恐れ）。

今すぐの実務アクション（最小コスト順）

  1. 現行フロー維持のまま、MATSimでnetwork.xmlのみ生成（CRS=UTM、速度/車線のデフォルト表を固定）。

  2. Go側でnetwork.xml読込 → 最短“時間/距離”切替実装を共通化。

  3. 探索高速化：ALT（Landmarks）→並列バッチ→CHの順に導入して効果測定。

  4. 余力が出たら、**pt2matsim（GTFS）**でPTネットを別ブランチに試験統合（RCM比較の将来拡張）。

要約

  • 速度KPI中心・静的探索中心の今の研究段階では、全面移行のリターンは小。

  • **“ネットワーク標準化（MATSim）×探索最適化（Go）”**の二段構えが最も筋が良い。

  • 将来、政策比較や混雑内生化まで踏み込む段で、段階的にMATSim機能を取り込むのが安全です。

 

2025,江端さんの技術メモ

Posted by ebata