内容: geo数据分列

昨天半夜还在改表，真的栓Q了。搞数据清洗这几年，最烦的不是代码报错，而是产品经理扔过来一坨数据，说：“哎，这个地址和经纬度混在一起了，你帮我分列一下。” 我一看，好家伙，全是这种脏数据。有的用逗号，有的用空格，有的干脆就是一串乱码混着汉字。这时候如果谁还告诉你“用Excel的分列功能，简单快捷”，我真心建议把电脑屏幕摔他脸上。别信！真别信。

咱们先说说那个所谓的“标准流程”。很多人习惯选中那一列，然后点击数据->分列。选分隔符，勾选逗号或者分号。听起来是不是特别完美？天真。我遇到过那种带引号的字符串，里面还有逗号做地址的一部分。比如“北京市朝阳区建国路88号,SOHO现代城A座”。你一看有逗号，选分隔符，结果好嘛，“朝阳区”分过去了，“建国路”又分过去了，最后整个逻辑全乱。更别提那些非标准格式的经纬度，有时候是度分秒，有时候是十进制，混在一堆，Excel根本识别不出来它到底是个坐标还是个普通的街道名。

这时候你就得上真家伙了，Python的pandas库。但我必须说，现在市面上有些教程，写得那叫一个高大上，什么正则表达式、什么解析库，看得人头大。其实核心就两个动作：清洗和分割。但是！这里有个巨大的坑，就是边界情况处理。比如你面对的是一个GeoJSON格式的数据嵌套在JSON里，或者是那种半结构化的文本。你如果只是简单地按空格split，绝对会炸。

我拿最近的一个客户案例来说吧。他们有十万条POI数据，来源是三个不同的爬虫渠道。A渠道返回的是标准的“经度,纬度”，B渠道是“纬度,经度”，C渠道直接是个字符串“北京,116.4,39.9”。你想只写一套脚本跑通？做梦。我以前吃过亏，为了赶项目，没做预处理直接硬跑，结果导出的数据库里，一半的数据经纬度反了。你想想，北京的数据变成了经纬度互换的位置，那地图标记全跑到海里去了或者飞到国外去了。后来查了整整三天日志，才把这些问题揪出来。

所以，说到geo数据分列，真不是点几下鼠标的事儿。你得先看数据结构。如果是CSV，最好先用文本编辑器打开看一眼前五十行，别嫌麻烦。很多时候，乱码、隐藏字符、不可见的制表符，都会让你的分隔符失效。我有个习惯，就是先统一把所有非数值和非标准标点替换掉，再尝试分割。但这也有代价，就是性能。以前我们处理一千万条数据，用pandas的apply配合split函数，跑了一个半小时。后来优化了一下，用矢量化操作，虽然写起来代码稍微复杂点，但时间缩短到了十分钟。这个性价比，你自己算。

还有啊，现在有些SaaS工具宣传“一键清洗geo数据”，号称傻瓜式操作。我试了两次，发现它们对异常值的容错率极低。一旦碰到格式稍微有点出入的数据，它就静默跳过，不回报告也不报错。这种隐形丢失比直接报错还可怕。你都不知道少了多少数据。真实的价格呢？这种靠谱点的工具，按调用次数或者按数据量收费，几十万条数据起步价都在几百到上千块不等。与其花这个钱买教训，不如花半天时间学学基础的正则或者简单的字符串处理。

再聊聊那个让人头秃的精度问题。geo数据分列之后，你还得校验坐标的有效性。国内经纬度范围是有固定区间的，如果分出来某个点的经度是150，那绝对是错的了。我见过有人在清洗数据时，把小数点后三位的精度和六位的精度混用。三分割后，有的保留两位，有的六位，直接导致后端计算距离时误差巨大。哪怕只差0.01度，在地图上那也是几公里的距离。这在配送、定位场景下，都是致命的bug。

总之， geo数据分列这事儿，别追求速度，追求的是准度。遇到那种奇奇怪怪的格式，宁可手动抽样检查，也别信全自动清洗。现在的 AI 工具虽然火热，但对于这种结构化要求极高的数据，很多时候还不如人工规则来得靠谱。如果你正在被这些脏数据折磨，不妨静下心来，先看看数据的源头和分布规律。别急着动刀，先做好体检。这点耐心，能帮你省下后面一周的加班时间。真心话，不写模板，不灌鸡汤，就这点血泪经验，希望能帮到正在debug的你。