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

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

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

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

一句话概括就是：

跑过一格，点亮一城。

为什么选择 H3 ？

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

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

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

• 每个网格都有稳定、唯一的 Cell ID ；
• 可以根据活动范围选择不同的网格精度；
• 相邻网格关系清晰，方便继续扩展路线与区域玩法；
• 客户端可以根据 Cell ID 还原六边形边界。

当前实现方式

1. 根据挑战范围动态选择网格精度

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

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

2. 客户端只根据 Cell ID 还原边界

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

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

3. 点亮结果由云端校验

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

1. 校验经纬度和坐标类型；
2. 过滤定位精度过低的数据；
3. 过滤明显异常的移动速度；
4. 将位置转换成 H3 Cell ID ；
5. 判断该 Cell ID 是否属于当前挑战；
6. 写入用户的点亮记录。

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

4. 使用确定性 ID 避免重复计分

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

挑战 ID + 用户 ID + H3 Cell ID

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

踩坑最多的地方：WGS84 与 GCJ-02

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

• H3 使用 WGS84；
• 腾讯地图展示使用 GCJ-02；
• H5 原生定位和小程序定位返回的坐标类型还可能不同。

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

目前采用的处理方式是：

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

具体原则是：

• H3 网格计算统一使用 WGS84 ；
• 地图展示前转换为 GCJ-02 ；
• 客户端上报时明确标记原始坐标类型；
• 服务端只进行一次标准化转换，避免重复纠偏。

项目技术栈

• 前端： uni-app + Vue 3
• 地图： 腾讯地图
• 空间索引： h3-js
• 后端： 阿里云 uniCloud 云函数
• 数据库： 阿里云 NoSQL
• 目标平台： 微信小程序、H5 、Android 、iOS 、鸿蒙 NEXT

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

想听听 V 友的意见

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

1. 六边形网格用在跑步探索场景里，大家觉得是否有趣？
2. 除了定位精度和速度限制，还有哪些成本不太高的防作弊方案？
3. H3 网格与国产地图坐标系的处理，还有没有更优雅的做法？
4. 如果是你，会更愿意点亮家附近的街区、公园，还是参加全城范围的长期挑战？

体验入口

小程序名称：快乐跑团

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

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

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