机场地图不是把平面图叠到室外底图上就结束了。旅客需要从道路、航站楼入口一路切到正确楼层的登机口；地勤和网约车则要在同一地点理解不同的工作区域。若楼层状态、室内外过渡或自有 POI 与底图不同步，再精细的图形也会把人带到错误位置。
Mapbox 在 2026 年 7 月发布的机场室内地图 tileset 提供了一个产品化案例：数据、渲染与楼层控件共同交付。对 GIS 团队而言，重点是把这些能力拆成可验收的地图状态，而不是把“支持室内地图”写成一个笼统功能。
可核查事实
-
Mapbox 于 2026 年 7 月 1 日发布机场室内地图 tileset 公告。
-
官方称该 tileset 面向 200 多个国际机场，覆盖范围仍在扩展。
-
数据以可直接接入应用的矢量 tileset 提供，可用于 Web 和移动 SDK，并可在 Mapbox Studio 或代码中启用。
-
公告列出的预设内容包括航站楼轮廓、入口、登机口、安检点、休息室和零售点，并可在 Mapbox Standard style 中预先着色。
-
SDK 的渲染逻辑支持从室外高层视图平滑过渡到详细楼层图，并提供楼层选择器切换楼层或室内外视图。
-
启用方式是把 Standard Style basemap import 的
showIndoor设为true，并在 Web 或移动应用加入indoorSelector。 -
团队可叠加自有图层和 POI，也可自行设计楼层切换组件及调整样式和交互。
-
Android 集成要求 opt-in 实验性 API；iOS 集成要求实验性 SPI import，二者均需显式启用楼层选择器。
这些事实来自 Mapbox 公告，描述的是产品能力与文中示例。它们不保证某一个机场、某个楼层或自有 POI 的实时状态；运营信息仍需由机场、航空公司或业务系统单独校验。
核心机制：室外坐标进入室内楼层
室内图最先要验证的不是图标，而是状态转换。用户从道路缩放或平移进入航站楼时，地图应进入可识别的室内范围；用户离开建筑时，又应回到室外视图。公告说明 SDK 已提供室内外过渡与楼层选择器，但团队仍须拿实际入口、航站楼边界、跨层电梯和出口做路径测试。
验收记录应包含测试机场、航站楼、入口、起止楼层、SDK 版本、样式版本和设备类型。若某一位置不能触发室内层，不应靠人工解释“这里暂不支持”掩盖；应把覆盖缺口显示为数据状态，并提供室外回退。
GIS 场景：楼层选择器到业务任务
showIndoor=true 与 indoorSelector 只完成控件启用，不能证明用户选到了正确楼层。测试应覆盖自动进入室内、手动切换楼层、切回室外、缩放和旋转后的状态保持，以及多楼层 POI 的可发现性。
以登机口为例，地图卡片、楼层选择器和路径终点必须指向同一楼层。以网约车接客点为例，自有接客区图层应和出口及室外道路保持一致。将当前楼层、选择方式和图层版本写入分析日志，客服或运维人员才能复现“为什么用户看到了这个点”。
技术路径：平台底图与自有 POI
公告允许叠加自有图层和 POI，这是机场应用真正产生差异的地方：航空公司可显示服务柜台与贵宾室，运营团队可显示受航班状态影响的登机口，网约车可显示接客区。但自有 POI 不应覆盖或静默替换基础数据。
为每个 POI 保存来源系统、有效期、楼层、坐标精度、更新人和版本；上线前检查它是否落在合理的航站楼与楼层内、是否与现有 POI 冲突、以及过期后是否会被隐藏。样式自定义也要回归测试：颜色、文字密度和图层顺序不能让登机口、楼层指示或无障碍路径失去可见性。
检查清单：最小验收步骤
-
在目标 SDK 和 Mapbox Standard style 中启用
showIndoor，记录版本与配置。 -
加入
indoorSelector，在至少一个多层航站楼验证室内外进入、每层切换和返回室外。 -
对入口、安检、登机口、电梯、零售点与接客区建立已知答案样本，逐项核对楼层和位置。
-
叠加一组自有 POI，验证其来源、有效期、楼层和样式不会遮挡基础信息。
-
在 Web、iOS、Android 分别验证；移动端还需记录实验性 API opt-in 状态。
-
将覆盖范围与未覆盖机场显式呈现，室内数据或业务 POI 不确定时回退到室外地图和文本指引。
风险边界
室内地图只提供空间表达，不能替代航班、安检排队、店铺营业、登机口临时变更或无障碍设施的实时运营数据。200 多个机场是公告所述的产品覆盖量，并非对所有航站楼和楼层完整度的保证。实验性移动 API 也意味着升级前必须重跑室内状态和楼层控件回归。
结论
机场室内地图的价值在于把道路、航站楼、楼层与业务点连成连续空间体验。要做到这一点，团队必须分别验收室内外转换、楼层状态和自有 POI 血缘。把这三条链写进发布门禁，室内图才能从好看的底图成为可用、可维护的导航能力。