理想 NPN 先验网络 （三）：
• 一些疑问和工程化问题
定位问题
关于离线地图查询时的定位问题这里并没有说明，事实上，之前 Tesla 在 AI Day 上也提到过 Spatial RNN 众包建图方案，与理想本次提出来的方案具有非常强的相似性。
但是这些任务都基于一个非常强的假设，因为需要有不同时空同一位置的地图更新，也就是说定位需要非常准确。
但是，实际上，车端的定位是无法准确到满足这个强假设的。
不准确的定位可能在查询整体离线地图时会出现偏差，也就会影响最后的感知结果。
所以一般来说，还需要实时位置特征去满足定位的要求，这一点应该也需要工程师们持续的努力。
这里有一个细节是，是否可以在查询地图时也加入一个隐式网络，将目标路面特征作为查询的来源，而不是纯显式地图定位表达。
地图的成熟度自动确认
在发布会上，郎博提到一个路口成熟度的概念，也就是在多次更新之后，离线地图会达到一个可以被使用的阈值。
关于什么时候可以被使用，郎博并没有给出来， 这里假设两点：
实际高精定位车辆采集地图，并且与目标比对，但是此时又回落回到高精地图采集的传统工作流中去。当然我相信，在早期项目设计开发时，一定需要实时地图采集作为真值训练网络的。
实时特征比对，一定存在一个合理的误差值，达到该误差时，路口结果会被释放。这是积累了足够多的数据之后，数据驱动产生的效能。
存储和实时云端互传
在论文中，提到使用 Nuscenes 数据集作为验证，整体 2km X 1.5 km 的小区域，0.3m 的分辨率，使用了 11GB 的存储空间。
关于本车如何使用这些数据，如何从云端下载数据，事实上也是一个需要实践解决的工程问题。
因为如果实时云端查询并且下载地图先验特征，常常会因为网络问题造成数据并不能实时传输完成，这样无法完成实时地图更新。
我的猜测应该也是与高精地图的使用方式一样，根据地图定位提前下载小片区的地图，例如通勤模式，可以将整个通勤范围内的地图提前下载并且查询由车端实时完成。
关于本车数据不断上传问题，并且理想并没有实时绘制地图，保存的只是地图的中间值特征，不具有地图拓扑含义，因此应该不算测绘，不需要特殊的测绘资质。
这也是一次数据驱动面对数据保护条例的小小胜利。