前阵子帮朋友搞地图数据可视化，我问他：“你手里的点位数据啥样？” 他甩过来一个Excel表，说是从某个免费网站扒下来的经纬度，让我直接往里导。我一看头大，这哪是数据，简直是乱码集。很多人第一次折腾地理空间数据，最常踩的坑就是文件格式不对，问得最多的就是geo什么格式。今天不整那些虚头巴脑的定义，我就按我踩过的雷，给你捋捋这条道。

说白了，GeoJSON就是目前Web前端最讨喜的格式。它长啥样？就是JSON的一个子集，人类可读性极强。你随便拿个记事本打开，全是花括号大括号，看着跟代码似的，但逻辑特别清晰。比如一个点，它得有type，是Point，还得有coordinates，那是经纬度数组，顺序是 lng, lat，别反了，反了坐标就飘到太平洋去了。如果是多边形，那更麻烦些，得定义外环和内环， hole 的处理得小心，不然地图渲染出来全是窟窿眼或者重叠块，看着别扭。

但有时候你也别只盯着GeoJSON，Shapefile (.shp) 依然是不少传统GIS软件的老大哥，像ArcGIS那些专业户，离了它还真转不开。这玩意儿是个“全家桶”，一个文件不算啥，得有好几个伴随文件：.shp存几何形状，.shx是索引，.dbf是属性表。你要是只拷一个.shp文件给别人，人家打开一看：“啥也没有？” 这种尴尬事儿我见过太多。所以很多人问geo什么格式能通用，其实得看你的下游工具吃哪一套。

再说说KML/KMZ，这俩是Google Earth的亲儿子。如果你只是想快速在Google地球上看一眼轨迹或者地标，这格式最直接。但它有个毛病，文件容易臃肿，特别是当你的要素特别多、属性特别杂的时候，渲染速度掉得让你怀疑人生。而且它在Web端的支持度不如GeoJSON那么无脑，很多时候还得转码。

那具体该咋操作？别光听我说，咱得来点干货。

第一步，先把你的原始数据扒干净。不管你是用Excel、CSV还是直接从数据库里拉出来的，先确定两件事：一是有没有明确的经度、纬度字段，二是有没有空值。我见过直接把中文地址扔进去让程序猜经纬度的，那不叫处理，那叫碰运气。如果源数据只有文字地址，先去调一下地图API的逆地理编码接口，虽然慢点，但总比一堆Null强。

第二步，根据用途选格式。如果你是要在前端Web页面上展示点、线、面，交互要丝滑，那就果断转成GeoJSON。可以用Python的geopandas库，几行代码的事儿：读入数据，确认坐标系（别用加密过的GCJ-02，尽量转成WGS84），然后导出。你要是还得照顾一些老旧的桌面GIS软件，那就顺便备份一份Shapefile格式，虽然繁琐，但稳妥。

第三步，检查与校验。这步最容易被省，也最容易出事。用在线工具或者QGIS这类软件打开你生成的文件。重点看：边界有没有闭合？（多边形必须首尾点相同）；坐标范围对不对？别把北京的坐标当成纽约的标上去；属性字段有没有丢失？有时候为了精简，导出时会自动把长字段截断，导致数据对不上。

举个例子，我有个做物流的朋友，之前用Excel存车辆轨迹，几千条数据，导出个CSV，再转成GeoJSON。结果发现很多点因为小数点位数不对，连不成线，或者连线乱飞。后来他加了个清洗步骤，统一保留小数点后6位，并且把空行剔除干净，最后渲染出来的路径流畅得像德芙。这就叫细节决定成败。

其实，纠结geo什么格式，本质上是在纠结兼容性和性能。GeoJSON胜在轻量、标准、Web友好，适合绝大多数现代应用；Shapefile胜在通用性（针对传统行业）；KML胜在直观。别再死磕一个死胡同，看你的场景下菜碟。要是你正卡在某个节点打不开，多半是坐标系没对齐，或者文件结构缺胳膊少腿。多试两次，心里就有底了。

配图1：GeoJSON结构示意代码截图

ALT: GeoJSON格式的具体代码结构展示

配图2：QGIS打开Shapefile与GeoJSON对比界面

ALT: 在GIS软件中对比不同地理数据格式的显示效果

其实这事儿没你想的那么玄乎，就是把数据“翻译”成机器能看懂的语言。多折腾两回，手感就来了。别光看书，上手敲几个例子，哪怕报错报错，也比干瞪眼强。

最后唠叨一句，数据清洗虽然烦，但它是地基。地基打歪了，上面盖再高的楼也得塌。别嫌麻烦，每一步都踩实了，后面干活才能爽。希望这点经验分享，能帮你少走点弯路。毕竟，谁也不想在深夜加班时，对着满屏的错误提示发呆，对吧？