干咱们这行十五年，见过太多因为数据格式不对头导致项目延期甚至返工的惨案。特别是搞GIS开发的，经常要处理各种乱七八糟的矢量数据，Shapefile、KML、GeoJSON... 其中geo2json转换是个高频动作，但也是坑最多的地方。今天不整那些虚头巴脑的理论，就聊聊我最近帮一个做智慧城市项目的哥们儿解决的真实bug，顺便把geo2json转换那些事儿掰扯清楚。

上周二，那个哥们儿急得电话都打爆了。他说他们团队从不同部门收集来的地理数据，有的来自国土局的shp文件，有的来自测绘队的kml，现在要统一入库，结果导入数据库后，地图上的点位全飘了，有的甚至变成了乱码或者根本显示不出来。我让他把原始数据和转换后的文件发我一份，打开一看，好家伙，典型的geo2json转换没处理好坐标系和拓扑关系。

很多人以为geo2json转换就是把数据格式变一下，其实不然。geo2json本身是一种轻量级的数据格式，非常适合Web端展示，但它对坐标系的依赖性很强。如果源数据是CGCS2000坐标系，而转换工具默认输出的是WGS84，那在地图上偏移个几百米是常有的事。我那个哥们儿用的工具，默认没做坐标转换，直接就把shp里的经纬度扔进geojson里了，导致数据全错位。

再一个坑，就是拓扑关系丢失。shp文件里是有拓扑结构的，比如相邻的多边形共享边界。但很多简单的geo2json转换工具，为了追求速度，直接把几何对象转成json字符串，完全不管这些多边形是不是重叠、有没有缝隙。我那个项目里，两个相邻的行政区在转换后，边界处出现了重叠，导致后续做面积统计的时候，总面积比实际大了好几平方公里。这要是上报给领导，那可不是闹着玩的。

还有个小细节，很多人忽略属性字段的类型。geojson标准里，属性值可以是字符串、数字、布尔值等，但如果源数据里的属性包含特殊字符或者超长文本，转换工具可能会截断或者报错。我见过一个案例，一个社区的名称里带了生僻字，转换后变成了问号，导致前端展示全乱套。

所以，做geo2json转换，千万别偷懒。第一，确认源数据的坐标系，必要时在转换前进行重投影。第二，选择支持拓扑检查的工具，或者转换后用PostGIS等工具校验一下数据的完整性。第三，仔细检查属性字段，确保没有数据丢失或格式错误。

我那个哥们儿听完我的建议，回去换了个支持坐标转换和拓扑检查的专业工具，重新跑了一遍数据。这次导入后，地图上的点位严丝合缝，属性也完整显示。他后来跟我说，这一下省了他们至少三天的调试时间。

其实，geo2json转换看似简单，实则考验的是对地理数据底层逻辑的理解。别指望一个工具能解决所有问题，多看看文档，多测试几种情况，才能避免踩坑。毕竟，数据质量是GIS项目的生命线，这点马虎不得。

本文关键词：geo2json