一、开篇：楼找到了，人在第几层还不知道
高层综合楼里一名检修人员失联，控制中心的地图上，红点落在建筑轮廓内，却给不出楼层。应急队伍进入建筑只能逐层搜索，一层层喊、一间间找。平面定位在这一刻暴露了它的输出边界：经纬度把整栋楼压成一个点，垂直方向的信息被完全抹掉。楼层不是锦上添花的显示需求，它直接决定搜索路径的长短。本文拆解楼层级定位的一条工程实现路径：基准站如何架设、大气压如何换算成海拔、建筑模型如何把海拔翻译成楼层。
二、痛点定义：平面坐标回答不了“第几层”
室外场景下，卫星导航给出的经纬度连续且可用；人一旦进入建筑，信号遮挡让这条链路失效。多数室内方案把位置投影到一张平面地图上，问题随之而来：所有楼层重叠在同一张图上。三楼的人与五楼的人在图上是同一个点，电子围栏判定分不出垂直方向。
行业内常见的替代思路有两类。其一是用楼宇进出记录与楼层停留统计做推断：数据来自门禁与定位记录，能回答“这个人去过哪层、待了多久”，但它是事后统计视图，用于考勤与追溯合适，用于正在发生的搜救与处置则时延不够。其二是NFC 刷卡点位：人刷过哪台读卡器，位置就停在哪个点，粒度是点、更新靠人走过去刷卡。两类方法的共同短板是输出的不是实时海拔。楼层判定真正需要的观测对象是高度——这正好回到物理层：大气压随海拔升高而降低，高度是可以测量的量。
三、核心技术原理：把“第几层”换算成“海拔落在哪个区间”
楼层定位的机制可以类比成一摞托盘：每层楼是一个高度区间明确的托盘，知道人所在的高度落在哪个区间，就知道他在哪层。整套机制分三段：测高、校准、建模。
测高靠气压。大气压随海拔升高按对数关系下降，终端内置的气压计（测量大气压强的传感器）读出气压即可换算海拔。气压计成本低、没有累计误差，是终端测高的主流路线。
校准靠基准站。气压是个易变量，天气过程会让同一地点的气压一天内明显波动，各终端若各自换算，早晚读数对不上。平台因此要求接入基准站——架设在坐标与海拔都已知的固定点上的参考设备。以手持基准站为例，登记时需填写机身标签上的设备编号、架设点的纬度、经度与预估海拔，其中预估海拔用于换算楼层高度。终端勾选「上报海平面基准大气压 P0」后，气压读数统一折算到海平面基准（气象学中把气压归算到海平面高度的标准做法），天气带来的基准漂移被显式消除。
建模靠建筑管理。沿建筑外轮廓在地图上依次描点圈定建筑轮廓，按实际层高逐层添加楼层并覆盖全部楼层，系统按层高自动生成各层海拔区间，再填写地平海拔（首层地面海拔）并把地平层指定为首层。此后终端海拔落进哪个区间，三维建筑地图就把它画在哪一层。设备参数中还有 GNSS、RTK（载波相位差分卫星定位，行业通行为厘米级平面精度，以厂商资料为准）与 LoRa（中距离低功耗无线技术）的启停项：RTK 有服务账号时开启并填写账号与密码，没有则保持关闭。图1 给出三段机制的完整链路。
图1 三维楼层定位原理拓扑：基准站与终端气压计提供观测，P0 海平面基准统一气压换算口径，建筑模型的层高海拔区间完成“海拔到楼层”的判定，结果呈现在三维建筑地图中。
四、多路线横向对比：四种楼层级定位路线
楼层粒度的输出在业内不止一条路线，观测机理与实时性差别明显（表1）。气压基准站法直接测高度，实时输出楼层归属，代价是基准站接入与建筑建模两笔配置工作。蓝牙信标以 MAC 地址（如 ff:10:00:1b:9c:f4）登记，终端开启信标扫描后定位方式变为信标定位，适合楼宇内平面补盲，楼层粒度取决于布点密度。楼宇进出记录与楼层停留统计属于数据侧的派生能力，回答“去过哪层”而非“此刻在哪层”。NFC 刷卡记录则把位置锚定在读卡点位上。
表1 四种楼层级定位路线的观测依据、输出粒度、实时性、部署工作量与适用场景对照（精度量级以厂商资料为准）。
五、工程落地细节与现场踩坑
平台给定的部署流程是五步：添加基准站 → 配置设备参数 → 现场部署验证 → 添加建筑与楼层 → 开启三维显示查看定位。每一步都有可核对的验收点。
步骤一，添加基准站。进入设备的基准站页面，类型按实际机型选择，填写设备编号、纬度、经度与海拔。步骤二，配置设备参数。依次启用设备、勾选「上报海平面基准大气压 P0」，GNSS、RTK、LoRa 按现场条件启停。步骤三，现场部署验证。手持基准站要安置于室外露天、视野开阔、无遮挡的固定点位——开阔是为了让基准站自身的定位与气压读数有代表性，遮挡会让参照系先失真。开机联网上报后，打开设备首页查看海拔数值：显示为绿色即表示数据上传正常；数值异常则返回配置页核对。步骤四，添加建筑与楼层。建筑轮廓描点要贴合外墙，层高按实测填写并覆盖全部楼层；地平海拔填首层地面海拔，地平层指定为首层。层高填错是隐性错误：海拔区间整体错位后，每层判定都平移，系统却不会报错。步骤五，开启三维显示。在地图配置中把地图视图由平面切换为三维，打开监控页面等待数据刷新，即可在三维建筑地图中查看人员所在楼层。
踩坑集中在三项核对上：三维地图里看不到楼层信息时，依次核对基准站是否在线、是否勾选了「上报海平面基准大气压 P0」、建筑的「地平海拔」与「地平层」是否填写正确——这三项覆盖了多数现场问题。另一处台账细节：监控数据基于监控对象（人员），修改绑定的设备后原数据依然保留，人员与终端、基准站的对应关系要在部署前理清。图2 汇总五步链路与核对要点。
图2 楼层定位五步部署链路拓扑：从基准站登记、设备参数配置、现场验证到建筑建模与三维显示，底部为平台给定的三项核对清单。
六、技术局限性说明：楼层维度的能力边界
气压测高对环境敏感。空调气流、频繁开关门、天气骤变都会让气压短时波动，楼层判定在区间边界附近可能抖动；基准站参照能消除慢变漂移，压不掉局部扰动。建筑模型是硬前提。没有建模的建筑输出不了楼层，改建加层后模型要同步维护，这在多楼栋园区里是一笔持续的运维量。RTK 增强依赖账号，无服务账号时保持关闭，对应的平面精度增益随之缺位。场景上也有明确边界：单层厂房、露天作业面用平面定位已经够用，为楼层维度增加基准站与建模投入没有收益。还要说清一点：楼层定位缩短的是寻找与处置时间，它改变不了事故是否发生，任何把系统能力表述成消除风险的说法都不成立。
七、总结：给架构师与集成商的一条判断标准
回到开篇场景：红点给不出楼层，搜救就只能逐层扫。楼层定位的价值由此定义——当“此刻在第几层”直接决定处置路径时，它不是显示特性而是响应资源。可落地的判断标准是：先看业务是否存在垂直维度的实时处置需求，再看现场能否满足基准站室外开阔架设与建筑建模两个前提；两者同时成立才引入楼层维度，否则用楼宇进出记录与楼层停留统计做事后推断已是成本更低的答案。基准站接入方式、精度量级与各配置项取值，以厂商资料为准。
