Mini Tokyo 3D：開源東京公共運輸即時 3D 地圖，把開放資料變成可嵌入的視覺化元件

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Mini Tokyo 3D 把東京的捷運、鐵路、地下鐵與國內線班機，渲染成一張會動的 3D 地圖：列車依時刻表與即時位置在軌道上推進、飛機起降、日夜與天色跟著實際時間變化。它是開源專案，任何人都可以把整張地圖嵌進自己的網頁，或下載原始碼自架。這篇文章給的是認識，不是評測。我讀過它的 README、LICENSE、package.json 與 GitHub 活躍度，也看了官網的公開 demo 截圖，但沒有實際部署（理由下面會講）。所以下文講的是「官方資料顯示它做得到什麼」，實際跑起來流不流暢、Mapbox 帳單會多少錢，要你自己驗證。

先回答讀者最常問的四件事：即時動態哪裡來、打開來長怎樣、台灣人看不看得懂、能不能放進自己的網站。這四個問題的答案，正好決定你會不會用它。

即時動態哪裡來：ODPT 開放資料，不是作者自己在算

這張地圖最容易被誤解的一點，是把「即時」想成作者在伺服器端即時運算。其實資料來源是公共交通開放資料中心（ODPT，網址 odpt.org），這是日本官方與多家鐵道業者共同投放的開放資料平台。README 的「About Data」段寫明：資料涵蓋車站資訊、列車時刻表，以及列車即時位置與多條路線的運行狀態，範圍是大東京地區（原文 Greater Tokyo area）。

ODPT 提供的是日本公共運輸的開放資料模型。順帶一提，世界各大城市的公共運輸局多半會用 GTFS 與 GTFS Realtime 這兩個開放標準來投放類似資料：GTFS（General Transit Feed Specification）本是 Google 力推的公共運輸資料格式，把時刻表、站點、路線寫成一份結構化的靜態資料，GTFS Realtime 則是它的即時補充，用來推送列車位置與誤點。Mini Tokyo 3D 在 package.json 裡引入了 gtfs-realtime-bindings 套件來處理即時動態，這也意味著它的視覺化架構理論上能換到其他提供 GTFS 的城市（下一節會講）。

把這些資料變成會動的 3D 地圖，中間的技術棧我在 package.json 裡核對過，分成四層：

• Mapbox GL JS 3.24 當底圖，負責地圖底層的向量圖磚與攝影機控制。Mapbox 是商業地圖服務，這一點待會在「硬限制」會回來講。
• deck.gl 在底圖上疊 3D 圖層，用來畫軌道、建物量體與動態資料圖層。
• Three.js 渲染列車與飛機的 3D 模型，所以列車是有體積的小立體，不是 2D 圓點。
• @turf 做地理空間計算，算列車此刻在兩站之間的哪個座標上；另外有 gtfs-realtime-bindings，解析 ODPT 提供的 GTFS Realtime 即時動態格式。

這裡有個技術細節值得多講一句：時刻表是離散的（一列車幾點幾分到站），但讀者在地圖上看到的列車是連續移動的。中間的「列車現在在兩站之間的哪個經緯度」是由 @turf 沿著軌道做插值算出來的，也就是程式根據時刻表與時間差，推算列車此刻應該跑到軌道的哪個位置。講白一點，作者的程式只做「拿資料、算位置、畫出來」，真正的即時性來自 ODPT 餵什麼就顯示什麼。

順著 package.json 再看一眼，會發現日夜變化也不是寫死的。它引入了 suncalc 這個套件，依套件用途是根據日期與經緯度算日出日落與太陽位置，地圖的天空亮度理論上會跟著這個計算走；另外還引入了 japanese-holidays，依套件用途判斷今天是不是日本假日，而日本鐵道的平日與假日時刻表不同，可能影響列車的發車班次。這兩個小依賴說明作者連「天空幾點暗」「今天排不排假日班表」都交給開源套件去算，而不是手動調參數。

圍繞主專案，作者還另外維護一組外掛，在 GitHub 上能找到的有：煙火（mt3d-plugin-fireworks）、即時攝影機（mt3d-plugin-livecam）、降雨（mt3d-plugin-precipitation）、PLATEAU（日本國交省的 3D 城市模型，mt3d-plugin-plateau），以及之前提到的 GTFS 外掛。這些都是獨立 repo，要哪個裝哪個，不會把主專案撐胖。對想在地圖上加一點季節效果或疊官方 3D 建物的人，這個外掛生態是主專案之外的延伸選項。

這也意味著兩件事：第一，離線或 ODPT 資料延遲時，地圖上的動態會跟著延遲，地圖的即時性上限等於資料來源的上限；第二，如果你想把同一套視覺化套用到東京以外的城市，得自己找當地的 GTFS 或即時資料來源。作者另外有 mt3d-plugin-gtfs 外掛，可以接其他 GTFS 與 GTFS Realtime 資料流，但那是另一個 repo 的工作，不在主專案範圍裡。

把開放資料做成可複用的視覺化元件，這個定位和 OpenGridWorks 把電網與資料中心畫進同一張地圖是同一類思路：公開資料本身人人可取，價值在有人把它變成讀得懂、還能嵌進網站的成品。

打開來長怎樣：一張可以拖、轉、傾斜的立體東京

官網 minitokyo3d.com 就是作者自己託管的即時 demo，用作者申請的 token 在跑。README 列了一份操作對照表，整理出來是這樣：滑鼠拖曳平移、滾輪縮放、右鍵拖曳傾斜與旋轉、Shift 加拖曳框選縮放，點列車或車站可以啟用追蹤或選站，畫面上還有路線搜尋、地下模式、播放模式、eco 模式與圖層設定等入口（README 只命名這些功能，實際效果要自己點開驗證）。

Pin

要強調的是，上面這張是官方發布的 demo 截圖，不是我自己跑起來拍的。我沒有實際操作 demo，所以無法替你背書「在你的瀏覽器跑起來多順」「延遲多少」，這些是官方資料無法證明、要你自己開網頁看的事。同理，README 宣稱它支援地下模式、播放模式、eco 模式等功能，這些都是「作者宣稱」的能力，官網 demo 看得到入口，但每個模式的實際效果需要你自己點開驗證。

它和 Google Maps、Yahoo!乗換ナビ（Yahoo 轉乘指南）這類熟知的工具，定位其實不同。Google Maps 是拿來找路、導航、看自己離捷運站多遠的工具；Yahoo!乗換ナビ 是給你排轉乘路線、查發車時間的工具。Mini Tokyo 3D 不做這些，它不做路線建議、不告訴你怎麼從 A 到 B 最快。它做的事情更接近「把整個東京公共運輸的運行狀態，變成一張可以欣賞、可以嵌入、可以二次開發的視覺化作品」。把它當導航用會失望，把它當資料視覺化元件看才對。

台灣讀者看得懂嗎：繁中介面有，繁中文件沒有

README 的 Language Support 表列得很清楚：繁體中文在「使用者介面」「地圖標籤」「站名與鐵路航空名稱」三欄都標 Yes，這對台灣讀者是直接的友善訊號，打開 demo 不會只看到日文或英文。但同一張表的「使用者文件」欄，只有英文、日文、法文三種語言有完整 guide，繁中沒有。也就是說，介面看得懂，但你想搞懂怎麼自架、怎麼調參數，只能讀英文（或日文）文件。

貢獻翻譯的管道是開放的，README 歡迎貢獻者從各語言的 dictionary 字典檔下手（繁中對應的是 repo 裡的 dictionary-zh-Hant.json），再補上各資料集的繁中標題。所以「沒有繁中文件」目前還沒人補齊，但不是硬封鎖。對願意貢獻開源翻譯的人，這是一個明確可切入的入口。

能不能放進自己的網站：可以，但要先過三個 token

嵌入的技術門檻其實不高。package.json 同時設了 main、module、jsdelivr、unpkg 四個欄位，等於告訴你三種取用方式：用 npm 安裝成套件、用 ES module 引入、或直接用 CDN（jsdelivr 或 unpkg）載入 dist/mini-tokyo-3d.min.js，再 new 一個 mt3d.Map 就能放進網頁。對只想嵌一張會動的東京地圖到部落格或活動頁的人，CDN 路線通常最短。

真正的門檻不在引入，而在金鑰。README 的「How to Build」寫明，自架要準備三個 access token：

• Mapbox access token：底圖與圖磚來自 Mapbox，需要到 Mapbox 官網申請。
• ODPT Center token：到公共交通開放資料中心申請。
• Challenge 2026 token：ODPT 有一個「Challenge 2026」方案，README 要求連這個 token 一起拿。

這三個 token 缺一不可。它們也點出 Mini Tokyo 3D 的真實成本結構：應用本身是 MIT 授權免費，但底圖是 Mapbox 這個商業服務（依地圖載入次數計費，費率依流量而定，官方資料未列出級距），資料是 ODPT 的開放資料但要走它的申請流程。所以「開源所以免費自架」只講了一半。

Pin

會改變你決定的硬限制

把官方資料能證明、與不能證明的事分開列，你比較好判斷它適不適合你：

• 覆蓋範圍只有大東京。README 原文寫 Greater Tokyo area，沒有全日本，更沒有台北或首爾。想用它看自己城市的公車與捷運，除非你願意接自己的 GTFS 資料（透過作者的 gtfs 外掛），不然它就是東京專用。這會直接決定它對你有沒有用。
• Mapbox 會計費。地圖每次載入都算 Mapbox 用量，自架放公開網站的人要在「曝光量」與「帳單」之間拿捏。官方資料沒有講費率，我也不替你估數字；想精算的人要去 Mapbox 官網查當前計價級距，再乘上你預期的月載入量。
• 三個 token 的申請門檻。ODPT 與 Challenge 2026 要走註冊流程，Mapbox 要綁帳號，這對「只是想在部落格嵌一張酷地圖」的輕度使用者是實質摩擦。只想看熱鬧的人，直接連官網 demo 最省事。
• 沒有繁中文件。介面親切，但自架與客製化要讀英文或日文文件，對不擅長讀技術英文的人是隱形門檻。
• 最新版是 beta。npm 上的最新 beta 是 4.0.0-beta.3（2026 年 6 月發布，要用 @beta tag 安裝），直接 npm install 拿到的穩定版停在 3.6.0（2025 年 1 月）。要 embed 到正式站的人，要自己決定押 beta 還是押穩定版；beta 拿得到新功能，但可能還有未修完的問題。

專案本身倒是健康。我在 GitHub API 看到：4147 顆星、374 個 fork、2019 年建立、最後一次推送是 2026 年 7 月底，不處於 archived 狀態，v4.0.0 仍在開發。作者是 Akihiko Kusanagi（GitHub 帳號 nagix），長年維護並接受 GitHub Sponsors 與 PayPal 贊助。這些是能客觀核對的活躍訊號，也是判斷「這個專案會不會三年後還在」的依據。

把這層觀察拉大一點看，Mini Tokyo 3D 與其說是「比 Google Maps 好用的東京地圖」，不如說是把日本公共運輸開放資料，變成任何網頁都能重用的視覺化元件。這個定位和 Track Policy 把 AI 法案畫進一張地圖、或 Future Style Periodic Table 用 3D 互動呈現元素週期表是同一個族譜：公開資料或公開知識本來就在那裡，差別在有人把它做成讀得懂、還能嵌走的成品。

值不值得你花時間：先開 demo，再決定要不要自架

如果你只是好奇東京的鐵路怎麼動，直接打開 minitokyo3d.com 看 demo 就夠了，不用安裝任何東西。這是最省成本、也最能判斷「這東西對我有沒有價值」的動作。看見列車會動、日夜會切換、點車站會跳出資訊，你會知道這個視覺化的密度與精度是不是你要的，這一步值得花三分鐘；看不見這些，或覺得「也不過如此」，那自架就不用再花時間，因為自架只會更費工，不會讓 demo 變得更精彩。

看過 demo 之後，如果你確定要把它嵌進自己的網站，下一步是去公共交通開放資料中心（developer.odpt.org/signup）與 Mapbox（account.mapbox.com）註冊帳號、把三個 token 拿齊，再用 CDN 把 mini-tokyo-3d.min.js 引進頁面。沒有 token，自架這條路走不通；有了 token，剩下的就是流量與 Mapbox 帳單的取捨。判斷標準很清楚：先看 demo 滿不滿意，再決定要不要扛後續的金鑰與帳單。對多數人，停在「看 demo」這一步就會得到八成的價值；會走到自架那一步的，多半是本來就打算做交通類主題網站或資料視覺化專案的人。