geo数据集处理原则：9年老鸟血泪总结，别再被清洗搞崩溃了

做geo这行九年，真的，有时候真想砸键盘。不是技术难，是人心太杂，数据更杂。每天看着那些乱七八糟的坐标、缺失的地址、重复的门店，我就头疼。今天不整那些虚头巴脑的理论，就聊聊我踩过的坑，还有这该死的geo数据集处理原则。你要是不想半夜起来改bug，就老老实实看完。

先说个真事。上个月接了个电商客户的单子，要清洗全国几百万条门店数据。客户拍着胸脯说数据很干净，结果拿到手一看，好家伙，经纬度反了是常态，有的地方坐标在太平洋中心，有的地方直接标成了0,0。我当时那个气啊，真想顺着网线过去问问他们是怎么采集的。这就是为什么我说，geo数据集处理原则里，第一条永远是：别信原始数据。

第一步，得做异常值检测。这一步最烦，但也最关键。你不能只看平均值，得看分布。比如，你发现某个城市的门店密度突然飙升，或者某个区域的坐标点都挤在一个小方块里，那肯定有问题。我一般会用热力图先扫一遍，肉眼看着不对劲的地方，再拿代码去查。别嫌麻烦，这一步省了，后面全是雷。

第二步，坐标转换和统一。这个坑太深了。国内常见的有WGS84、GCJ02、BD09，这三种坐标系混着用，简直是要命。如果你把WGS84的坐标直接画在百度地图上，那偏差能大到让你怀疑人生。我见过有人把高德的数据直接塞进百度的系统里，结果客户投诉说门店位置全飘了。所以，必须统一坐标系。我的建议是，先确认源数据的坐标系，然后统一转换到GCJ02或者BD09，具体看你的下游应用是用哪家地图服务。这一步，千万别偷懒，一定要做校验。

第三步，地址解析和补全。很多数据只有地址文本，没有坐标。这时候就得靠NLP或者调用地图API去解析。但API是有调用限制的，而且不是所有地址都能解析成功。我通常的做法是，先批量解析，把解析成功的存起来，解析失败的单独拎出来，人工复核或者用更高级的模型去跑。这里有个小细节，地址里的“省市区”有时候会缺失，或者写错，比如“广东”写成“广东省”，这种细微差别会导致解析失败。所以，地址标准化也是必不可少的一环。

第四步，去重和合并。重复数据是geo数据的大敌。两条数据，经纬度差0.0001，算不算重复？这得看你的业务场景。如果是找附近500米的店，那肯定算；如果是找精确到门牌号的店，那可能不算。我一般会用空间索引，比如R-tree，来快速查找相近的点。如果距离小于阈值，且其他属性（如名称、电话）高度相似，就判定为重复。这一步，参数调整很关键，调得太松，漏掉重复；调得太紧，误杀正常数据。

最后，总结一下。geo数据集处理原则，核心就三个字：信、准、稳。信，是指对数据源保持怀疑；准，是指坐标和地址必须精准；稳，是指流程要稳定，可复现。别指望一次就能搞定，数据清洗是个迭代的过程。

我见过太多同行，为了赶进度，跳过异常值检测，直接跑模型，结果模型效果差得一批，最后还得返工。真的，别省这一步的时间。你花在清洗上的每一分钟，都会在模型训练时省回来十倍。

如果你还在为geo数据头疼，或者不知道自己的数据质量到底行不行，欢迎来聊聊。我不一定能帮你解决所有问题，但至少能帮你避开几个大坑。毕竟，这行水太深，一个人摸索太累。咱们一起，把这堆烂数据理清楚。