市面上的AR工具包，从苹果的ARKit到谷歌的ARCore，再到RoomPlan、Polycam，提供的都是一体化封闭方案。SLAM、物体检测、交互界面，所有功能打包在一个笨重的黑箱里，开发者只能全盘接受。如果你只想要中间那一环——把相机姿态和目标检测的数据流转成一张干净的、去重后的2D地图，告诉你“这里有把椅子，那里有扇门，坐标分别在哪”——目前市面上找不到一个轻量、可嵌入的工具专门干这件事。

一位开发者动手填补了这个空白，开源了一个名为geomap-engine的Rust工具包。它的功能定位极其精准：只做一件事。喂给它一个帧数据，包含相机姿态、内参，以及一系列二维边界框检测结果，它就维护一张“场景地图”——地图上每个真实物体只对应一个稳定条目，而不是把每次检测都当成新物体记录下来。

这套引擎刻意划清了自己不管的边界。它不跑SLAM，开发者得自带ARKit、ARCore或ORB-SLAM3之类的方案。它不做目标检测，模型同样由开发者自己准备。它更没有UI界面。它像一个粘合层，安静地坐在传感器感知模块和上层应用之间，专门处理姿态与检测结果的融合，然后把产出的结构化地图交给上层的App、机器人决策系统或车载工具链。

引擎内部的工作原理走了一条务实的流水线。第一步叫“投影”，把平面内的2D边界框，结合相机姿态和内参，通过与地平面的射线-平面求交，估算出物体在真实世界中的2D位置。目前的v0.1版本做了一个简化假设：相机距离地面的高度是已知且固定的。第二步是“关联”，针对标签类别和位置邻近度，与地图中已存在的追踪物体做最近邻匹配。第三步“融合”是这套引擎的核心设计：来自多次观测的结果并非简单取平均值，而是将置信度当作独立证据进行累加。每次观测都在增强可信度得分，值会朝着1的方向单调逼近，而非被过往的低置信度拉低。最后一步是地图维护，只用一条“陈旧度规则”就统一处理了噪声过客、长期静止后消失的对象，以及被移动过的物体——逻辑上三件事，实现上只需一个准则。

使用上非常直接。开发者引入Engine结构体，按Protobuf定义的格式组装好CameraIntrinsics、CameraPose和Detection，塞进一个Frame，调用engine.ingest_frame(frame)，就能拿到一张SceneMap。输出的格式是GeoJSON，标准的FeatureCollection构型，里面全都是点状地物。拿到这段JSON可以当场丢进geopandas、matplotlib，或者任意一个地图查看器里可视化，不需要再写额外的格式转换代码。示例代码中，相机被设置为1.5米高、垂直俯视地面，检测框“椅子”以0.8的置信度标出了归一化坐标，一行println就吐出整个场景的GeoJSON字符串。

技术选型背后有明确的跨平台考量。选择Rust语言，除了性能与内存安全外，更关键的是后续可以通过FFI接口打通iOS和Android端的调用。帧数据与场景地图的数据结构用Protobuf定义，这使得前端无论用Swift、Kotlin，还是Python搭建的测试工具，都能以语言无关的方式喂入数据，不需要关心后端引擎用的是什么语言实现。

目前版本v0.1已经完成实现并通过了测试。代码库配置了持续集成，每次推送都会触发cargo build、cargo test和cargo clippy检查，三项均干净通过。总共11项测试覆盖了两类场景：一套基于手工编写的固定数据，用于验证基本逻辑；另一套用上了来自TUM RGB-D基准数据集的真实相机轨迹，叠加带合成目标的检测框以及真实施加上的检测器噪声。后者的目的很明确——确保关联与融合逻辑在真实的传感器抖动和检测噪声下依然能站稳，而不是仅仅在理想化的合成输入面前好看。由于版本尚未达到1.0，API仍可能发生变动。