IMDF 是一份給「找路的人」用的地圖資料
建築師手上的 CAD 圖告訴你牆在哪裡、管線怎麼走。IMDF 回答的是另一組問題：這個空間叫什麼、做什麼用、門開在哪裡、從這層怎麼到那層、裡面是哪家店、幾點營業。
這個分工決定了 IMDF 的長相。它不畫牆的厚度，也不記錄建材，只用多邊形和點描述「可以被找到、被走到」的東西，而且每一筆都要對上真實世界的經緯度。所以 IMDF 圖資可以直接疊在手機地圖上，CAD 圖不行。兩者不是取代關係，IMDF 通常就是從 CAD 或平面圖整理出來的。
| 項目 | 內容 |
|---|---|
| 全名 | Indoor Mapping Data Format |
| 制定者 | Apple |
| 標準地位 | OGC 社群標準（Community Standard，文件編號 20-094），2021 年 2 月 2 日核准 |
| 目前版本 | 1.0.0 |
| 底層格式 | GeoJSON（RFC 7946），座標一律為 WGS 84 經緯度 |
| 交付形式 | 一個 ZIP 壓縮檔，內含 manifest.json 與各類圖徵的 .geojson 檔 |
| 主要用途 | 提交 Apple 地圖的室內地圖；場域自有的導覽圖台與內部營運系統 |
| 費用 | Apple 表示，註冊、使用 IMDF 與其室內定位服務都不收費 |
打開一個 IMDF 檔，裡面有什麼
把 IMDF 的 ZIP 解開，會看到一份 manifest.json 和一組 .geojson 檔，每個檔只裝一種圖徵。規格裡必備的只有三個：manifest.json（版本、建立時間、預設語言）、venue.geojson（場域本身，一份 IMDF 只能有一個）和 address.geojson（地址）。其餘十四種都是選用。
選用不等於可以不做。驗證規則要求每棟建築至少有一個樓層、每個樓層至少有一個空間，只要地圖上想看得到任何一層樓，Level 和 Unit 就跑不掉。實際會用到的圖徵大致分成四組：
| 分組 | 圖徵 | 描述什麼 |
|---|---|---|
| 場域與建築 | Venue、Building、Footprint、Address | 場域本身、場域裡的建築、建築外輪廓、地址 |
| 樓層與空間 | Level、Unit、Opening、Section、Fixture、Kiosk、Detail、Geofence | 樓層；房間、走道等空間；門與通道；分區；櫃檯之類的固定物；獨立攤亭；線狀細節；虛擬範圍 |
| 內容 | Amenity、Occupant、Anchor | 廁所、電梯這類設施點；店家與服務單位；把店家掛到空間上的定位點 |
| 關聯 | Relationship | 圖徵之間的連通，例如跨樓層的電梯與樓梯 |
最常被誤解的一組：Occupant 和 Anchor
Occupant（進駐單位，通常就是店家）在 IMDF 裡沒有幾何形狀。它不知道自己在哪裡，只記得自己掛在哪個 Anchor 上；Anchor 是一個點，落在某個 Unit 裡。店名、類別、營業時間、電話、網址都存在 Occupant 上，另有一個 validity 欄位可以標示有效期間。
對要長期維護的場域來說，這是 IMDF 最實用的設計。商場和航廈的店家一直在換，如果店名直接寫在空間的多邊形上，每換一家店就得改一次地圖。拆開之後，空間歸空間、店家歸店家，換店只動 Occupant 一筆紀錄，地圖幾何一筆都不用碰。
多語系不必做三份地圖
名稱類欄位在 IMDF 裡是以語言標籤為鍵的物件，同一個空間可以同時存 zh-Hant、en、ja 三種名稱，預設語言寫在 manifest 裡。要做三語導覽，維護的是同一份圖資，不是三份。驗證規則也會擋下空白名稱和無效的語言標籤。
為什麼用 IMDF，而不是自己定一套格式
很多場域的室內地圖是導覽 App 廠商順手畫的，存在廠商自己的格式裡。平常用起來沒問題，直到要換廠商、要上架 Apple 地圖、或要把同一張地圖接到內部派工系統的那一天。
IMDF 是公開標準，讀得懂 GeoJSON 的工具都打得開，資料不會被哪一家的私有格式鎖住。同一份圖資可以提交 Apple 地圖，也可以餵給場域自己的網頁導覽、App 和內部營運系統。如果你的場域是機場、購物中心或車站，Apple 的規範還另外寫了這三類場域的建模說明，不必從零摸索。
我們自己的圖台就是這樣搭的：圖資以 IMDF 原生建置，前端用 MapLibre GL 開源引擎和 PMTiles 靜態圖磚顯示，沒有地圖引擎授權費；場域用 iframe 或 WebView 把圖台嵌進官網或 App，不必裝 SDK。圖資和顯示端分開，哪天換掉前端，地圖不用重畫。
但 IMDF 是資料格式，不是導航系統。它描述空間、出入口和跨樓層的連通，「從 A 到 B 怎麼走」要由使用它的應用來算；「你現在在哪裡」更要靠另一層定位技術。這兩件事後面再談。
建置流程：從平面圖到一份驗證通過的 IMDF
- 盤點資料。各樓層的平面圖（有 CAD 最理想，只有平面圖也能描繪）、每個空間的名稱與用途、樓層之間的對應、要放上地圖的設施和店家清單。這一步缺什麼，後面就卡在什麼。
- 對上真實座標。GeoJSON 規定用 WGS 84 經緯度，平面圖卻是相對座標。要先找控制點把圖對齊到地球上，地圖疊上手機時才不會偏到隔壁棟。
- 由大到小建模。先建 Venue、Building、Level，再切 Unit，然後補 Opening、Fixture、Amenity，最後用 Anchor 把 Occupant 掛上去。每個 Unit 都要指定類別（走道、廁所、房間等），導覽能不能分類查詢，靠的就是這個。
- 跑驗證。規格附有整套驗證規則，分成違規（Violation）和警告（Warning）兩級。
- 上架或自用。要上 Apple 地圖，透過 Apple Business Register 的室內地圖計畫提交；只自用，就直接接到自己的圖台。
驗證最常卡在哪
違規是硬錯誤。圖徵 ID 必須是 v4 UUID 而且不能重複，每個引用的 ID 都要找得到對象，一份檔案只能有一個 Venue，Anchor 必須落在它引用的 Unit 裡。這類錯誤多半出在產製工具，修一次就好。
警告比較需要判斷。同一層的 Unit 不該互相重疊，所有 Unit 加起來應該剛好鋪滿整層樓，門要落在空間的邊界上；門寬超過 45 公尺或小於 0.8382 公尺（33 英寸）會被標為可疑。真實的建築不一定守這些規矩，後場的窄門、挑高中庭在樓板上留下的開口，都可能觸發警告。警告不必全部清零，但每一條都該有人看過，知道為什麼留著。
規格沒寫、但一定要做的事：ID 要穩定
IMDF 只要求 ID 是唯一的 UUID，沒有要求改版前後要一樣。不少產製流程每重做一次就重發一批 UUID，檔案照樣驗證通過。麻煩出在下游：官網上每個店家的「在地圖上查看」連結、維修系統裡掛在某個空間的紀錄、App 裡的收藏，全都指向舊 ID，地圖改一版就斷一次。
我們把 ID 當成空間的身分證：同一個空間不論地圖改幾版，ID 都不變，空間真的拆了或合併了才發新的。每個地標的專屬連結、掛在空間上的維修紀錄，靠的都是這一點。這件事要在第一版建置時就決定，等地圖已經被別的系統引用了再回頭補，代價大得多。
手上有平面圖，想知道做成 IMDF 還缺什麼？把圖傳給我們，先幫你盤點。
預約圖資評估上架 Apple 地圖：誰能申請、要做什麼
Apple 的室內地圖計畫（Indoor Maps Program）透過 Apple Business Register 申請，對象是大型場域的擁有者或營運者，Apple 舉的例子有機場、購物中心、體育館和醫院。換句話說，提交的人要能代表這個場域；顧問或建置廠商負責把圖資整備好，不是代替場域去申請。
Apple 另外提供 IMDF Sandbox，可以在網頁上檢視自己的 IMDF 並做小幅修改。要讓 iPhone 在室內也顯示「你在這裡」，則要用 Apple 的 Indoor Survey App 做一次 Wi-Fi 訊號採集；Apple 表示這套室內定位利用場域既有的 Wi-Fi 基地台，不需要另外佈建硬體。
上架 Apple 地圖解決的是「iPhone 使用者打開 Apple 地圖時看得到你的室內」。場域自己的官網、App、Android 使用者和內部人員，還是需要自己的圖台。所以我們建議把 IMDF 當成場域自有的資產來建，Apple 地圖只是會用到它的地方之一。
建好之後：地圖從驗收那天開始過時
IMDF 專案最常被低估的是後半段。店家進駐汰換、營業時間調整、施工封閉，內容天天在變；沒人維護的室內地圖，遲早會把人帶到已經撤櫃的店門口。
維運要先回答三個問題：誰可以改、誰來審、改錯了怎麼退回。我們的圖台把這三件事做成固定流程：場域人員在後台或手機上編修，送審核可後才發布，每一版留快照，可以一鍵回復。前面提到的 Occupant validity 欄位也派得上用場，限期進駐的快閃店可以直接標上有效期間。
還有一條要寫進合約：圖資的著作財產權歸誰。我們服務的合作機場，圖資著作財產權歸屬機場，格式又是開放的 IMDF，換廠商時可以完整帶走。如果你的合約沒寫這一條，簽約前值得補上。
機場、醫院、政府機關常有資料落地或服務不得中斷的規範，純雲端的圖台未必過得了資安審查。好在地圖產物只是靜態圖磚和 JSON，鏡像到場域地端主機的成本不高，雲端異常時可以切到地端續供。部署方式與公開價格整理在 IMDF 圖台託管服務。
地圖之後：定位是另一層
IMDF 回答「東西在哪裡」，不回答「你在哪裡」。要在自己的 App 裡顯示藍點，得另外選一種室內定位技術：
| 技術 | 精度 | 特性 |
|---|---|---|
| WiFi 電磁指紋 | 3–5 米 | 利用場域既有的 WiFi 基礎設施 |
| 藍牙 iBeacon | 1–3 米 | 信標以電池供電，可用 2–3 年，免拉線 |
| UWB | 10–30 公分 | 更新率可達 10Hz，單站覆蓋 50–100 公尺 |
選哪一種看場域條件。2017 年我們在香港國際機場參與藍牙 iBeacon 應用，部署超過 700 個信標做全區域定位導航；2014 年 Computex 則在三個展館佈建 5,000 顆 Beacon，尖峰時段現場 WiFi 與 3G 連不上，導航照常運作，那次的架構取捨寫在為什麼展場人一多，室內導航就失靈？。不管用哪一種技術，算出來的座標最後都要落在一張地圖上，地圖畫錯了，藍點再準也沒用。
常見問題
使用 IMDF 要付費嗎？
格式本身不用。IMDF 是公開的 OGC 社群標準，Apple 也表示註冊室內地圖計畫、使用 IMDF 與其室內定位服務都不收費。真正的成本在圖資建置與後續維護的人力：我們的建置費依樓地板面積與樓層數估算，維護成本則看場域異動的頻率。
用什麼軟體可以打開 IMDF 檔？
IMDF 是用 ZIP 包起來的一組 GeoJSON 檔，解壓縮後，QGIS 這類支援 GeoJSON 的 GIS 軟體都能直接開啟。Apple 另外提供網頁版的 IMDF Sandbox，可以檢視整份圖資並做小幅修改。
IMDF 只能給 Apple 地圖用嗎？
不是。IMDF 是 OGC 社群標準，任何應用都可以讀取。場域可以用同一份 IMDF 建置自己的網頁或 App 導覽圖台，也能接到內部的派工與設施管理系統；上架 Apple 地圖只是其中一種用途。
一個場域有好幾棟建築，要做幾份 IMDF？
一份。規格要求每份 IMDF 恰好有一個 Venue（場域），Venue 底下可以有多個 Building，每棟建築各自有自己的樓層與外輪廓。
IMDF 有新版本嗎？
目前只有 1.0.0。OGC 在 2021 年 2 月核准這個版本為社群標準，規格也規定 manifest 的版本欄位只能填 1.0.0。
參考資料
- OGC：Indoor Mapping Data Format 標準頁（英文）
- OGC 20-094：IMDF 1.0.0 規格全文與驗證規則（英文）
- Apple：IMDF 規範與機場、購物中心、車站建模說明（英文）
- Apple：Indoor Maps Program（英文）
相關方案
- IMDF 室內地圖圖台 — 新場域的第一步：把場域建成符合規範的 IMDF 圖資
- IMDF 圖台託管服務 — 圖資建好之後的月租託管、管理沙盒與雲地混合部署，價格公開
- 輕量化 BIM 圖台 — 從既有竣工圖或平面圖出發，2D、3D 與 IMDF 同源
- 室內定位技術 — 地圖之後的那一層：WiFi 指紋、藍牙 iBeacon 與 UWB