去年秋天，我们接了一个连锁餐饮品牌的活儿。客户有三百多家门店，分布在全国六十多个城市，之前一直用Excel表格管理门店数据。每次总部开会，区域经理们对着密密麻麻的表格，讨论哪家店该关、哪家店该扩，全靠脑补空间位置。老板拍板说，上一套电子地图系统吧，把门店、竞品、商圈、人流数据全揉进去。这个项目从数据清洗到可视化上线，前后折腾了四个月，踩了不少坑，也攒了不少经验。

先说数据这关。客户给我们的原始数据，那叫一个乱。门店地址有写“XX路100号”的，有写“XX区XX街道XX号”的，还有直接写“某某商场三楼”的。最要命的是，同一个商场在不同门店的记录里，名字还不一样，一会儿“万达广场”，一会儿“万达”，一会儿“WD广场”。我们第一周啥也没干，就蹲在电脑前清洗地址。用Python写了个脚本，调用高德和百度的地理编码API，把每条地址解析成经纬度。但地理编码有个问题，模糊地址返回的坐标可能偏几百米，对连锁餐饮来说，几百米可能就跨了一个商圈。后来我们想了个笨办法，把解析出来的坐标再反向地理编码，看返回的地址和原始地址是否匹配，不匹配的人工复核。三百多家店，光这一步就花了两周。

坐标搞定之后，真正的难点来了——怎么定义“商圈”。客户要的不只是把门店标在地图上，他们要分析每个门店周边的竞争环境。比如，方圆一公里内有多少家同类餐饮，周边三公里的人流密度怎么样，附近有没有大型社区或写字楼。这些数据从哪来？市面上有现成的POI数据服务商，但价格不便宜，而且数据时效性存疑。我们决定，用开源的OSM数据加上爬虫补充。爬了大众点评上同类品牌的门店位置，又爬了链家的小区数据，还有写字楼的分布。这些数据混在一起，用PostGIS做了空间计算，给每个门店算出了“商圈竞争指数”和“人流潜力分”。这步技术难度不高，但工作量极大，连续三周，团队每天加班到凌晨。

数据准备妥当，进入可视化阶段。我们最初用Leaflet画了个原型，功能倒是都能实现，但界面太“工程师审美”，客户那边市场部的人看了直摇头。后来换成了Mapbox GL，视觉上一下子现代了不少。但Mapbox的底图在国内访问速度不稳定，我们又做了本地化部署，把底图瓦片缓存到自己的服务器上。门店的展示分三层：第一层是总览，用聚合气泡图显示全国门店分布，气泡大小代表单店营收；第二层是城市级，显示商圈热力图，颜色越红说明竞争越激烈；第三层是单店视角，点击任意门店，弹出详情面板，包括周边竞品分布、人流热力、外卖配送范围预估。这三层切换的交互，我们调试了很久，尤其是热力图和气泡图叠加时的性能优化，一开始一拖拽就卡顿，后来用Web Worker做了数据预处理，才流畅起来。

项目中期，客户提了个新需求——要能模拟新店选址。他们准备明年扩张，想知道在某个候选位置开店，会不会和现有门店抢客流。这需求一听就头大，但客户是金主，硬着头皮也得做。我们基于现有门店的客流数据，训练了一个简单的回归模型，输入候选位置的周边POI特征、人流密度、竞品数量，输出预估的日均客流。模型精度一般，误差在百分之二十左右，但客户说够了，他们以前完全是拍脑袋，现在至少有个量化参考。这个选址功能上线后，成了整个系统里使用频率最高的模块，区域经理们天天拿它试各种位置。

可视化上线后，又遇到一个意想不到的问题——数据更新。门店的营收数据每周更新一次，但POI数据是静态的，半年才更新一次。结果有一次，某个商圈新开了两家大型购物中心，我们的系统里还是旧数据，导致客户在选址模拟时，给出的建议明显过时。这事儿闹了个小风波，客户反馈说“系统不准”。我们紧急加了数据更新提醒机制，在系统里标注了各层数据的更新时间，并设置阈值，当某区域POI变化超过一定比例时，自动触发重新采集。虽然麻烦，但至少让客户知道，哪些数据是新鲜的，哪些是历史快照。

项目收尾时，我们做了个复盘。最大的教训是，企业电子地图的核心难点从来不是画地图，而是数据治理。地图本身是成熟的工具，真正花时间的，是把企业内部的业务数据和外部的空间数据，清洗、匹配、融合成一个能用的整体。另一个教训是，别追求大而全的功能，客户一开始列了二十多项需求，我们砍掉了三分之一，聚焦在门店管理、竞品分析、选址模拟这三个核心场景，反而用得最勤。那些砍掉的功能，比如配送路线规划、会员分布热力，等他们业务成熟了再上也不迟。

现在这套系统上线跑了五个月，客户那边的使用率稳定在每周两百多次。区域经理开会时，不再对着表格空想，而是直接打开地图看数据。老板也养成了习惯，每周一早上先看一遍全国门店的态势图。前几天客户打电话来，说今年计划再开八十家店，选址模拟帮他们省了不少前期调研的功夫。虽然这个项目赚的钱不算多，但看着一帮人从Excel表格升级到用空间思维做决策，还是有点成就感的。企业电子地图这事，说到底，就是把业务放到真实的地理世界里去审视，数据从表格里站起来，变成看得见的位置和关系。