こぼれネット

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

ebata

私は、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) 最低限の検証チェックリスト

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

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

 

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

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

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

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

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

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

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

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

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

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

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

要約

 

モバイルバージョンを終了