[分享创造] 我用 Uber H3 做了一个跑步版「地图涂色」：跑过一格，点亮一城

大家好，我最近给自己开发的「快乐跑团」小程序做了一个新功能：城市点亮计划。

它有点像现实世界里的地图涂色：

跑友可以在地图上圈定一片公园、街区或江边路线，创建一个限时挑战。参与者实际跑到某个区域后，就能点亮对应的六边形网格，最后按照点亮数量进行排行。

一句话概括就是：

跑过一格，点亮一城。

为什么选择 H3 ？

这个功能使用了 Uber 开源的地理空间索引库 H3，项目中对应的 JavaScript 依赖是 h3-js。

H3 可以把地球表面划分成不同精度的六边形网格。获取定位后，不需要自己编写复杂的“点是否落在多边形内”判断，只需把经纬度转换成 H3 Cell ID，就能确定用户当前进入了哪一格。

这套模型很适合跑步探索场景：

创建挑战时，用户可以选择 100m 到 2000m 的覆盖半径。

系统会从较细到较粗尝试多个 H3 分辨率，优先选择网格数量不超过 300 格的最细方案，在探索精度、数据量和地图渲染性能之间做平衡。

云端保存挑战所包含的 H3 Cell ID 。客户端拿到数据后，通过 cellToBoundary 计算六边形边界，再交给地图组件绘制。

这样不需要为每个网格保存和传输完整的多边形坐标。

客户端上传 GPS 位置，uniCloud 云函数负责：

基础校验放在云端，避免由客户端直接决定点亮结果。当然，这目前只是基础异常过滤，还不敢称为完整的反作弊系统。

点亮记录使用以下信息组合成确定性文档 ID：

挑战 ID + 用户 ID + H3 Cell ID

同一个用户在同一个挑战中重复经过同一格时，不会重复计分。这个设计也让重复请求的处理更简单。

真正让我折腾最久的，其实不是六边形，而是国内地图坐标系。

如果直接把 H3 网格画到腾讯地图上，网格会出现明显偏移。

目前采用的处理方式是：

GPS 定位
   ↓
识别原始坐标类型
   ↓
统一转换为 WGS84 进行 H3 计算
   ↓
生成 Cell ID 与六边形边界
   ↓
转换为 GCJ-02 后绘制到腾讯地图

具体原则是：

目前还实现了挑战创建、网格预览、实时点亮、进度展示、在线参与者提示、排行榜和分享等功能。

这个功能还在继续打磨，比较想听听大家对下面几个问题的看法：

小程序名称：快乐跑团

微信小程序搜索“快乐跑团渝你同行”首页 banner 就能看到。

如果大家感兴趣，我后面也可以单独整理一篇 H3 、GCJ-02 与腾讯地图叠加网格的踩坑记录。

感谢阅读，也欢迎直接拍砖。🙂