supercarto

supercarto

mcp-name: io.github.Unselfisheologism/supercarto

LLM ネイティブの空間ミドルウェアです。 地理空間データを、AI エージェントが直接推論できる、トークン予算に合わせたトポロジカルグラフにコンパイルします。

トークンの負担をかけずに、エージェントに地図を渡せます。ファイルを 1 つ入力するだけで、両方の数値が得られます。examples/synthetic-dense.geojson は生データで 272,993 バイト（約 68,000 トークン）ですが、トークン予算を 1024 にすると約 890 トークンにコンパイルされます。26 ノード（うち 10 個は名前付き）、34 エッジ（道路とアクセスリンク）で、約 99％の削減です。実際に試すには、supercarto compile examples/synthetic-dense.geojson --budget 1024 を実行してください。トークン数は固定のテストファイルに対する文字数ベースの推定値です。太陽とタイムスタンプの行により、実行ごとに数トークンほど変動します。

npm install supercarto
pip install supercarto      # Python client, talks MCP over stdio

---

座標を渡すだけ

製品全体はこれだけです。

import { SuperCarto } from 'supercarto';

const carto = new SuperCarto();

const result = await carto.maplet({
  lat: 35.6833,
  lon: 139.7620,
  radiusM: 400,
  budget: 1500,
});

console.log(result.yaml);

見出しにあるのと同じファイルを、以下にコンパイルしたものです（出力は省略しています。警告は地図の中に含まれるため、地図だけを読むエージェントにも伝わります）。

map:
  center: "37.7749, -122.4194"
  source: geojson
  note: Simplified for reasoning; call expand_feature for exact geometry.
nodes:
  n530: {type: poi, name: Bank 0, tags: [bank]}
  n531: {type: poi, name: Cafe 1, tags: [cafe]}
  n673: {type: transit, name: Station 0, tags: [subway_entrance]}
edges:
  n515->n516: {dist: 80m, dir: east, path: road}
  n516->n517: {dist: 80m, dir: east, path: road}
omitted:
  - {layer: building, count: 259}
  - {layer: poi, count: 141}
  - {layer: road, count: 441}
tools:
  - expand_feature(id)

予算を 1024 トークンとした場合、抽出全体で約 890 トークンです。各レイヤーにあるすべてのドロップに名前が付いており、何も黙って消えることはありません。

---

課題

エージェントに、物の場所と、物の間の移動方法を把握させたいとします。選択肢は 3 つありますが、どれも問題があります。

• GeoJSON をプロンプトに貼り付ける。 ブロックごとに数千トークンを使います。モデルは生の座標をうまく推論できず、座標を幻覚します。
• 地図 API を呼び出す。 同じ GeoJSON が返されます。変わるのは HTTP の往復だけで、トークンのコストは変わりません。
• コンパクトな独自のワイヤ形式を考案し、モデルに読み方を教える。 コンテキストウィンドウ内の新しい文法は、座標の幻覚を引き起こし、文法の推測にトークンを消費します。モデルは独自形式でトレーニングされていません。

supercarto は 3 つ目の選択肢に真剣に取り組み、実現できる唯一の方法で解決します。モデルがワイヤ形式を読むことはありません。

  coordinates          live sources             reasoning format
  35.68, 139.76  ──▶  Overpass / PMTiles  ──▶  topological YAML graph
                                           distances in metres,
                                           compass directions,
                                           built for models

ワイヤ形式は、お客様が所有する仕様であり、機械向けに最適化されています。推論形式はフロー形式の標準 YAML で、モデルが何十億回も読んできた構文だけを使用します。ミドルウェア内の決定論的なコンパイラが変換を行います。

---

エージェントは人のために動きます

その人は屋外にいます。雨や交通状況によって、移動そのものを取りやめるかどうかが変わるため、これらはルーティングエンジンに後付けされるものではなく、第一級のレイヤーです。

天気

API キーは不要です。アカウントも不要です。課金もありません。

const w = await carto.weatherAt(35.6833, 139.7620, 12);

w.now.summary;          // "heavy rain"
w.now.precipitation;    // "rain" | "snow" | "sleet" | "hail" | "drizzle"
w.now.feelsLikeC;       // what they actually feel

$ supercarto weather --lat 35.6833 --lon 139.762
now  clear night, 23.2C (feels 26.9C), wind 4.3km/h, precip none
  2026-10-01T13:00:00Z  22.7C  none      3.5km/h
  2026-10-01T14:00:00Z  22.1C  none      3.1km/h

MCP ツールはフィールドではなく文章を返します。モデルは「雨が降っているので、バスに乗ってください」という文章なら確実に繰り返せますが、12 個の数値から同じ情報を再導出するのは不確実だからです。

データソースに接続できない場合は、すべての測定値に NaN を返して degraded を設定し、ツールはエラーを発生させます。ゼロは返しません。precipitationMm: 0 を渡されたエージェントは、天気は晴れだと判断し、誰かを嵐の中へ自転車で出発させてしまいます。

交通状況

const t = await carto.routeWithTraffic({ from, to, mode: 'drive' });

t.freeFlowOnly;   // true when no flow credential is configured
t.worstLevel;     // "severe" - the segment that makes someone late
t.delayS;

交通情報には認証情報が必要なため、キーを設定するまで get_traffic はツール一覧に表示されません。キーがない場合、ルーティング経路は自由流の状態を報告し、次のようにラベル付けします。

$ supercarto traffic --from 37.7749,-122.4194 --to 37.7849,-122.4194
traffic: unknown (no flow source configured)
free-flow estimate: 244s, ignores congestion
note: set TOMTOM_API_KEY or HERE_API_KEY for live conditions

渋滞中のルートに自由流の所要時間を提示することは、答えを提示しないよりも悪い結果を招きます。エージェントが伝えた予定どおりに、その人が出発してしまうからです。これをリアルタイム情報として提示することは、このライブラリが引き起こしうる最も有害なことなので、そうはしません。

TOMTOM_API_KEY または HERE_API_KEY を設定すると、リアルタイム情報が利用可能になり、平均ではなく最も混雑している区間の状況が報告されます。

屋内フロア

これを公開しているのは、ほかに誰もいません。Google は自社ユーザー向けに屋内マップを構築しており、サードパーティのエージェントにフロアごとのクリーンなグラフを渡す理由はありません。Mapbox にも同等のものはなく、MCP のラッパーはどれも同じ平坦な GeoJSON を返します。

indoor:
  storeys: 0,1,2
  multi_storey: true
  0: {label: ground, rooms: 12}
    L0n1: {type: corridor}
    L0n2: {type: shop, name: "Blue Bottle"}
    L0n1->L0n2: {dist: 11m}
  v1: {type: lift, levels: [0,1,2], wheelchair: true}
  missing: [1]

エレベーターは階をまたいで、1 本の垂直リンクにまとめられます。部屋は同じフロアの廊下にのみ接続されます。コンクリートの床スラブを通るエッジがあると、利用者を階の中へ送り込んでしまいます。どの廊下からも 40m を超えて離れている部屋は接続されません。途中の壁を直線で突っ切るより、エッジがないほうがましだからです。タグのない階は、作り上げた情報ではなく missing として報告されます。

交通機関の時刻表

SUPERCARTO_GTFS に任意の静的 GTFS フィード（展開済みのディレクトリまたは .zip）を設定すると、get_transit が利用可能になります。停留所、路線、指定日の運行時間帯が表示されます。実際の時刻表に基づいて「9 時までに着けるか」という質問に答える、唯一のエージェント向けマップツールです。また、各事業者で起こりうる失敗はすべて、推測ではなく誠実な状態表示で扱います。

transit:
  center: "36.913, -116.77"
  radius: 3.0km
  feed: sample-feed
  note: Stop distances are straight-line. Schedule from GTFS feed for 2007-01-11 in America/Los_Angeles.
nodes:
  STAGECOACH: {type: stop, name: "Stagecoach Hotel & Casino", tags: [bus], routes: ["30", "40"], first: 06:00, last: 06:58}
  NADAV: {type: stop, name: "North Ave / D Ave N", tags: [bus], routes: ["40"], first: 06:14, last: 06:44}
edges:
  NADAV->DADAN: {dist: 601m, dir: south, path: bus 40}

• 運行状態は 2 つではなく、必ず 3 つです。 当日の運行がある場合は、路線と始発・最終便の時刻が表示されます。運行がない日は、routes: [] の停留所が残ります。交通機関が運行していないことは、停留所がないことを意味しません。その旨は注記にも記載されます。カレンダーのないフィードでは、ネットワーク全体を表示し、フィード全体のデータを当日の時刻表として提示するのではなく、運行時間帯が不明であると伝えます。
• 午前 0 時を過ぎた時刻は、そのまま表示します。 GTFS では、運行日の午前 0 時を過ぎた発車時刻は 24 時間を超える時刻（25:10）で表します。これを見やすい 01:10 に変えると判断を誤らせるため、フィードに記録されたとおり、フィード独自のタイムゾーンで表示します。
• エッジは構造であり、時刻表はノードに紐づきます。 運行のない日でも隣接関係は維持されます。停留所間を歩くエージェントにとって、引き続き必要な情報だからです。
• GTFS-Realtime を指定すると、遅延をリアルタイムで反映します。 SUPERCARTO_GTFS_RT に事業者の TripUpdates URL を設定すると、予測情報が時刻表に加わります。ノードの路線情報には、bus 16 +300s や bus 16 cancelled などの live: 属性が追加され、フィードの鮮度も注記に記載されます。仕様の優先順位も守られます。明示的な停留所の更新は便単位の遅延より優先され、絶対時刻による予測はフィードのタイムゾーンを使って変換されます。最も重要な誠実さのルールは、リアルタイム情報がない停留所は定刻運行ではなく、状態不明であるということです。その旨は注記に明記されます。フィードを読み込めない場合（404、タイムアウト、不正なデータ）は、一文の説明を添えて時刻表のみの回答に切り替わり、何も言わずに情報が消えることはありません。
• 当日の運行時間帯だけでなく、次の発車便も表示します。 各ノードの next: 属性には、その停留所からの次の発車便が、フィードの時刻順かつフィードの時計表示で一覧されます（tram 9 25:10 は午前 0 時を過ぎた時刻のまま表示されます）。最大 3 件まで表示され、残りは件数（+2 more）で示されます。リアルタイムフィードが設定されている場合、発車案内には予測がインラインで表示されます（bus 16 07:05 +300s または cancelled）。すでに発車案内に表示された情報は live: の一覧から除かれるため、重複して表示されません。当日の最終便が出発済みの場合は、発車案内が壊れたフィードのように見えないよう、その日が終了したことを注記で伝えます。
• 2 つの座標間で、検証済みの乗車プランを提示します。 get_transit_route は停留所まで歩き、両方の徒歩圏に停車する 1 つの路線に乗って、降車後に歩きます。直線距離による区間にはその旨を明記し、フィードで証明できない乗り換えは提示しません。プランの信頼性は発車案内と同じ原則に従います。運行日を基準に検証され、各便に予測情報が付加され、運休した便は件数を示す注記とともに除外されます。検証できる経路がない場合は、どの区間で失敗したのかを注記で示します。
• 情報の出どころを明示します。 発車時刻、時刻表の日付、フィードのタイムゾーンは note に記載されるため、マップだけを見るモデルにも伝わります。

---

予算は実際の予算です

エージェント向けの地図コードの多くは、切り詰めて期待するだけです。supercarto は、切り詰めを正確性の問題として扱います。

• ランキング。 名前のあるランドマークは残し、名前のない交差点から先に削除します。
• 接続性。 関節点は削除しないため、残ったネットワークは連結したままです。エージェントが通れるものの、接続できない地図は、規模が小さくても使える地図より劣ります。
• 名前だけが残らないようにします。 エージェントから見えても経路を設定できないランドマークは削除します。エージェントは自信を持ってそこまで歩こうとするためです。
• 検証。 emitAndVerify は実際に出力された YAML を再計測し、収まるまで再度削除します。報告される予算は推定値ではなく、実際に提供される予算です。
• 透明性。 削除項目はすべて omitted: に記録され、レイヤーごとに集計されるため、モデルは「そこにない」と「表示されていない」を区別できます。

---

ベンチマーク

現在は独立したリポジトリにあります： supercarto-bench。

質問もモデルも地図も同じで、異なるのはコンテキストウィンドウに入る内容だけです。コンパイル済みグラフ、生の GeoJSON、または何もなしを比較します。生の実行結果、固定されたテスト用地図、採点コードはすべてここにあるため、競合する地図ツールを開発する人なら誰でも同じテストを実行し、スコアに挑戦できます。

現在の主な結果は、2 つの AI モデルで、コンパクトなグラフが 9/9、生のデータが約 4/9、地図なしが 0/9 です。経路に関する質問は測定できません（公開テストルーターが実行不可能な回答を返すため）。そのため、route は実現可能性の回答に格下げされています。直線距離、方角、そして「到着したら進入経路を確認してください」を返します。ターンバイターン案内には、自分でホストして検証したルーターが必要です。OSRM はオプションであり、デフォルトではありません。隠さず明記しています。

現在のスコアには、独自の再現手順（モデルを呼び出さず、生の回答アーカイブから再導出した scoreC certificate）、モデルごとのリーダーボード、アダプター枠も含まれています。競合ツールは単一の { name, prepare } モジュールを登録するだけで、同じタスク、モデル、合格ルールを利用できます。現在の証明書では、アーカイブされたすべての実行を通じて、supercarto は 38/47、geojson は 15/44、none は 0/47 です。

• ライブ証明書 — すべての数値は、モデルを呼び出さずに、コミット済みのアーカイブから再導出できます。
• ライブリーダーボード — モデルごと、アダプター枠ごとの結果を掲載しています。自分で実行できる無料モデルも含まれます。

このリポジトリに残しているのは、トークンコストの簡易チェックです。

npx supercarto bench <file.geojson>

---

データソース

ソース	状態	用途
Overpass	デフォルト	開発用。1 回の呼び出しに 15～40 秒かかり、レート制限があります。
PMTiles / Protomaps	SUPERCARTO_PMTILES	本番用。 オブジェクトストレージへのレンジリクエストで、数ミリ秒、レート制限なしです。
OSRM	デフォルト	徒歩・自転車・車のターンバイターンルート案内です。
Open-Meteo	デフォルト	天気です。キーは不要です。
TomTom / HERE	キーが必要	リアルタイムの交通情報です。
Terrarium tiles	デフォルト	標高と傾斜です。キーは不要です。
GTFS feeds	SUPERCARTO_GTFS	交通機関の停留所、路線、時刻表です。任意の静的フィードを使用でき、キーは不要です。リアルタイムの遅延情報は、SUPERCARTO_GTFS_RT 経由で GTFS-Realtime TripUpdates URL から結合します。

export SUPERCARTO_PMTILES=https://your-bucket/planet.pmtiles

本番規模で使うなら、PMTiles が最適です。リーダーは組み込み済みなので、pmtiles 依存関係も、mapbox-gl もなく、推移的パッケージはゼロです。

すべてのデータは単一のファクトリーが環境から読み込むため、CLI と MCP サーバーでデータの取得元が食い違うことはありません。以前は食い違っていましたが、誰も報告しませんでした。

SUPERCARTO_PMTILES      PMTiles archive URL; primary source when set
OVERPASS_ENDPOINT       your own Overpass instance
TERRARIUM_ENDPOINT      elevation tile template
TOMTOM_API_KEY          enables get_traffic
HERE_API_KEY            enables get_traffic
SUPERCARTO_NO_TERRAIN   disable elevation
SUPERCARTO_NO_WEATHER   disable weather
SUPERCARTO_GTFS         path to a GTFS feed (dir or .zip); enables get_transit
SUPERCARTO_GTFS_RT      TripUpdates URL; adds live delay lines to get_transit

大都市圏全体のフィードはメモリにすべて読み込まれます。0.6.1 以降、読み込みは カラムナー方式です。stop_times は行オブジェクトを作らず、各 trip の配列に直接格納されます。そのため、 Translink SEQ（35 MB の zip）ほどのフィードも Node のデフォルトヒープに収まり、 0.6.1 より前のビルドとバイト単位で同一の回答を返します。この規模で実環境にて検証済みです。時刻表、発車案内、750 件以上の リアルタイム予測を、NODE_OPTIONS をまったく指定せずに 1 つの回答に結合できます。さらに大きなフィードは、 展開後のサイズに比例してメモリを使用します。そのような実行には NODE_OPTIONS=--max-old-space-size=4096 を指定してください。

---

エージェント連携

Claude Desktop（ワンクリック）

各リリースには supercarto-X.Y.Z.mcpb（MCPB バンドル）が含まれます。 最新リリースからダウンロードし、 Claude Desktop で開けば、マップツールをワンクリックでインストールできます。 インストール時の任意の設定として、天気の上限を引き上げる Open-Meteo キーと、 交通機関ツール用のローカル GTFS フィードのパス（および運行事業者の TripUpdates URL）を指定できます。必要なのは Node ≥ 18 のみです。バンドルにはサーバーが含まれており、npm 依存関係はゼロなので、サイズは 0.5 メガバイトです。

MCP

{
  "mcpServers": {
    "supercarto": { "command": "npx", "args": ["supercarto", "mcp"] }
  }
}

7 つのツール：get_maplet、route、search_places、expand_feature、 get_daylight、get_terrain、get_weather に加え、キーがある場合は get_traffic、 GTFS フィードが設定されている場合は get_transit と get_transit_route も利用できます。各 maplet には、そのデプロイで回答可能なツールのみが正確に列挙されるため、エージェントが動作しないツールを呼び出すことはありません。get_daylight は常に利用できます。太陽の位置は算術演算で求められるため、データソースも認証情報も不要です。

maplet が場所について伝えること

地形や距離に加えて、ノードには、出かける価値があるかどうかを決める情報も含まれることがあります。

n3: {type: poi, name: Blue Bottle, tags: [cafe], hours: 07:00-18:00, brand: Blue Bottle}
n4: {type: poi, name: Central Rx, tags: [pharmacy], hours: 09:00-17:00}
map:
  sun: up, elevation: 43.4deg, twilight: day, azimuth: 22deg, sunrise: "..."

上記の 2 つの店は、現地時間の 12:00 に営業中です。同じ 2 店でも 04:00 には営業時間が記録されており、閉店しているため、 hours: closed と表示されます。営業時間が記録されていないベンチでは、hours フィールド自体が出力されません。

hours は特定の時点に基づいて評価され、サーバーのタイムゾーンではなく、マップのタイムゾーンで評価されます。状態は 2 つではなく、3 つです。時間範囲、closed、または記録がないために項目が存在しない状態です。項目がないことは意図的に closed と区別されています。両者では正反対の案内になり、一方は行って確かめることを意味し、もう一方は別の場所へ行くことを意味します。

twilight は真偽値ではなく、day、civil、nautical、night のいずれかです。これらはそれぞれ異なる判断につながるためです。市民薄明なら歩いても問題ありませんが、航海薄明では避けるのが賢明です。夏や冬に北極圏の外側では、日の出をでっち上げる代わりに、マップは polar: day または polar: night を報告します。

compile.utcOffsetMinutes と compile.now を渡すと、どちらも既知の場所と時点に固定できます。テストではこの方法を使います。

Python

import asyncio
from supercarto import SuperCarto

async def main():
    async with SuperCarto() as carto:
        m = await carto.maplet(lat=35.6833, lon=139.7620, radius_m=400, budget=1500)
        print(m.yaml)
        w = await carto.weather(lat=35.6833, lon=139.7620)

asyncio.run(main())

実行時の依存関係はありません。SDKをインポートする代わりに、stdio経由でNodeサーバーとJSON-RPCをやり取りします。これは、mcp パッケージがhttpxとpydanticを取り込み、どちらか一方にすでに依存しているエージェントフレームワークに、重複したコピーを持たせないためです。

HTTP

curl 'localhost:8787/maplet?lat=35.6833&lon=139.762&radiusM=400&budget=1500&format=yaml'

ホステッドモード（デプロイ済み）

コンパイルパスはWorkersに対応しています（fetchベースのソースを使用し、Node組み込み機能は使いません）。また、cloud/worker/ ではCloudflare Workerとしてパッケージ化しています。ローカルHTTP APIと同じ /maplet、/scr、天気、日照時間、地形の各機能を提供し、IPごとのレート制限と、すべての地図レスポンスへのODbL帰属表示に対応しています。これは意図的に機能を絞った構成です。WorkerにはGTFSフィード用のファイルシステムがなく、ホステッドモードにはフロープロバイダーのキーも含まれていないため、公共交通機関と交通状況は提供しません。そのことは GET / に明記されています。詳しくは cloud/worker/README.md をご覧ください。

https://supercarto-compile.jeffrinjames99.workers.dev にデプロイされています。/maplet と /scr のデータソースは、まずライブのOverpassを参照し、次にホステッド版のPMTilesによるOpenStreetMapベースマップを使用します。既知のすべての公開Overpassインスタンスが、共有Cloudflareの送信元IP範囲を拒否するため（HTTP 521）、実際にホステッド版のmapletを提供するのはフォールバックです。アーカイブの詳細度はz10前後より拡大すると粗くなります。また、WorkerのCPU予算内にplanetタイルを収めるため、デプロイ環境ではリクエストごとのタイル取得数とフィーチャー取得数に上限を設けています。切り捨ての情報は警告としてドキュメントに含まれ、フォールバックで提供された場合は source: 行に protomaps と表示されます。天気、日照時間、レート制限は利用できます。地形は正直に503を返します（TerrariumタイルはPNGエンコードされており、同梱の依存関係ゼロのデコーダーは生のTerrariumバッファーのみを読み取るためです）。GET / に記載されている理由により、公共交通機関と交通状況は提供されません。GET /healthz が確認するのはOverpassのみです。そのため、そこで503が返る場合はOverpassへの接続ができないという意味であり、PMTilesのフォールバックが停止しているという意味ではありません。

---

CLI

supercarto fetch --lat 35.6833 --lon 139.762 --radiusM 400 --budget 1500 --metrics
supercarto weather --lat 35.6833 --lon 139.762 --hours 12
supercarto traffic --from 37.7749,-122.4194 --to 37.7849,-122.4194
supercarto transit --feed city-gtfs.zip --lat 36.913 --lon -116.77 --radiusM 3000
supercarto route --from 37.7749,-122.4194 --to 37.7849,-122.4194 --mode walk
supercarto mcp
supercarto serve --port 8787
supercarto compile city.geojson --budget 1024 --metrics
supercarto encode city.geojson --out city.scr
supercarto decode city.scr
supercarto bench city.geojson

fetch レイヤーでは、生のOSMタグに加えて road と poi を指定できます。それ以外は、何も返さずに黙って処理を終えるのではなく、拒否されます。名前付きの場所が取得できても道路が取得できないリクエストは、誤解を招く地図を返す代わりに、明確なエラーを返します。POIのみの地図には --layers poi を渡してください。警告はstderrだけでなく地図の出力にも含まれるため、エージェントにも確認できます。

---

精度

距離は、ハヴァサイン式で算出した地上距離を正解値として、中緯度および高緯度で検証されています。

• サンフランシスコ（北緯37.77度）で誤差0.11％
• オスロ（北緯59.91度）で誤差0.11％

これを実現するには、Web Mercatorの縮尺補正を正しく適用する必要がありました。Mercatorの距離は、両軸とも地上距離を 1/cos(latitude) 倍上回ります。また、符号を間違えると中緯度で26％の誤差が生じ、極に近づくにつれてさらに大きくなります。正方形でないbboxに平均等方縮尺を使うのも誤りであるため、縮尺は軸ごとに適用します。

ベンチマークのタスクセットは、意図的に北緯64度から南緯33度までを対象としています。北緯37度だけでベンチマークを実行しても、1ケースを測定するだけで、極に近づくほど顕在化するすべての符号の誤りを見逃します。

---

状況

461 件のテストに合格しています。内訳は、328 件のユニットテスト（GTFS 交通レイヤーの 42 件、protobuf のワイヤー形式と TripUpdates スキーマの 14 件、リアルタイムオーバーレイの結合の 5 件、PNG 標高デコーダーの 7 件を含む）、ライブソースを対象とした 121 件、MCP エンドツーエンドの 12 件です。 出力は Python 版とバイト単位で一致します。パリティエンジンはプッシュのたびに実行されます。ライブの OpenStreetMap、ライブの Open-Meteo、および Python から制御したライブ MCP サーバーで検証済みです。

実装済み：SCR コーデック（テキストとバイナリ、差分ジオメトリ、リンググループ、3 種類のヒートエンコーディング、省略、ルート、参照）、軸ごとのスケール補正を備えた Web Mercator、Visvalingam-Whyatt による簡略化、OSM 分類を伴う GeoJSON の取り込み、ジャンクションの統合とランドマークの付与を行うトポロジーのコンパイル、接続性を保証するトークン予算管理、YAML の出力、垂直移動を含む屋内フロアグラフ、場所密度ヒートマップ、ライブ Overpass、組み込み MVT デコーダーを備えた PMTiles、実現可能性の評価に限定したルーティング（デフォルトでは直線距離と方角を使用。OSRM のターンバイターン案内は、検証済みのエンジンを使用する場合に限りオプトインで有効化できます。公開デモ用ルーターはあり得ない距離を返します）、測定値を捏造しない、機能低下時の経路を備えたキー不要の天気情報、実態を偽らない自由流フォールバックを備えた交通情報、地形の標高と傾斜、3 つのサービス状態を正直に示す GTFS 時刻表、不明を定刻扱いしないセマンティクスで時刻表に結合した GTFS-Realtime の運行情報更新、stdio 経由の MCP、HTTP API、CLI、Python クライアント、および OSRM の正解データを使用したタスクレベルのベンチマーク。

未実装：スタイル配信を伴うホスト型ベクタータイル、および重心を超える完全な屋内の部屋ジオメトリ。

---

ライセンス

Apache-2.0