道路網はノード (交差点) とエッジ (道路リンク) のグラフ。最短経路の基本は Dijkstra 法 (1959) だが、日本全国 ~千万ノード級では 1 クエリ数秒かかる。 実用エンジンは前処理で高速化する: CH (Contraction Hierarchies、階層の ショートカット追加) や、このラボの OSRM が使う MLD (Multi-Level Dijkstra、 領域分割 + セル間の事前計算)。前処理数分・クエリ数 ms — 高松→松山 161km が 16ms で返るのはこの仕組み。
クリック点・GPS 点は道路上に無いので、まず最寄り道路リンクへ射影する (グレー破線)。連続する GPS 軌跡を道路列に対応させる本格版がマップマッチング (HMM ベースが定番)。スナップ距離が大きい点は「そこに車道が無い」ことを意味する — 検証ツールとしての読み方。
OSM は highway=motorway/trunk/primary/…/residential の階層 + oneway・maxspeed・maxheight 等の属性タグ。本ラボの実測 (四国): 属性の付与率は中心市街地の幹線で ~50%、全域では ~6%。 「地図データはタグの集合であり、品質は場所とタグで大きく違う」— レイヤ表示で その分布が直接見える。実運送の法規制準拠にはゼンリン/MapFan 等の商用データが必要。
経路探索の「最短」はコスト関数次第。truck プロファイルは車高 3.8m/幅 2.5m の 制約 + 細街路の速度を大幅に下げたもので、同じ経由点でも幹線寄りの経路を選ぶ。 商用トラックナビはこれに重量・危険物・時間帯規制まで積む (HERE/国産データの領分)。
「⇄ 最適順」は始点/終点を固定した open TSP。OSRM の trip API は 貪欲 + 2-opt 近似で瞬時に解く (厳密解は NP 困難)。運送業の配車計画 (VRP) は この上に車両数・時間窓・積載を載せた一般化 — tln 系との連携ポイント。
「📍 到達圏」はグリッド点への所要時間を 1×N の行列 API (/table) で一括計算した 簡易版。滑らかな等値線が要るなら Valhalla の isochrone が定番。到達圏は 店舗商圏・救急カバレッジ・配送拠点配置の基本ツール。