本文转载自《构建高性能高程 API》

在彩云科技，我们始终致力于为用户提供更高时空分辨率的气象数据。在过去这些年中，我们始终面临一个挑战：由于高程数据分辨率的限制，徒步、越野等户外活动爱好者用户经常遇到彩云提供的数据与实际感受有着明显偏差，这种情况在海拔变化剧烈的山地和高原地区尤为突出。

TLDR

前几日查资料的时候发现了 MapTiler 制作的轨迹高程数据可视化页面，效果非常好：

这个做的是真好的啊，而且完全在浏览器实现的https://t.co/R1vQMbdYAo pic.twitter.com/IyTYy5Fxo1

— ringsaturn.me (@ringsaturn_me) January 10, 2024

在其官方的 Blog 找到了 2019 年的博文 提到了使用的技术是将高程数据编码到图片的 RGB 通道值中，然后在浏览器中解码，这样就可以在浏览器中实现高程数据的可视化了，特别是轨迹数据这种连续的数据，下载几张图片就能绘制连续的高程曲线。

tzf 及相关项目的基础开发工作基本稳定了，在之前的文章零星有些开发和设计过程的资料:

• 2022-05-29, 在 Go 中将经纬度转时区
• 2022-08-01, Python 中经纬度转时区新的选择
• 2022-08-27, 用 Go 编写 Python 扩展
• 2022-09-10, tzf 预览图制作
• 2022-11-24, tzfpy Rust 重写

这一篇是最终的总结，从项目的启动到逐步优化和演进的过程。

本文转载起《彩云天气地理查询优化(2): 行政区划查询》

在彩云天气 App 和 API 里可以获取到当前经纬度的气象预警信息，比如「大风蓝色预警」。 不同国家地区的预警发布规则不一样，在中国是按照行政区划层级来发布的，其中最小到县级行政区。 所以在实现中，需要将经纬度转换成行政区划层级信息，再查找相关的预警信息。 在过去几年中，这部分模块经历了多次重构和完善，在此分享下每个版本的实现方式。

本文转载自《彩云天气地理查询优化: 最近的 N 个点》

我们从一个实际业务场景的谈起：

如何找到离北京市海淀区 768 创意产业园最近的 K 个国家级观测站？

最简单的思路是完整遍历所有候选站点，然后计算每个站点和 768 的距离，按照距离从小到大，选最多前 K 个。 这个代码并不难写。但是问题是慢。

书接上文:

• 在 Go 中将经纬度转时区

经过一个周末的各种折腾，终于用 Rust 实现了 tzf 的功能，代码在 ringsaturn/tzf-rs。

又用了晚上跑了多次 CI 将 Python 移植也重写出来了 ringsaturn/tzfpy。

tzfpy 只要安装 >= 0.11.0 版本的就是用纯 Rust 实现的，在这个版本号之前都是 Python+CGO 实现的。 API 参数和之前一样，没有变化，但是索引命中的时候只需要 3～4 微妙，之前 Python+Go 需要 16 微妙。 最慢的单次查询 300 多微妙，timezonefinder(用 C 实现的多边形算法版本) 最慢的时候会有 1000 多微妙。

在处理大规模的散点数据时，有时候我们需要提供一个只读的查询 API 在地图上做可视化。 当数据量过大，比如百万这个量级，将数据一口气全部返回给前端在浏览器上处理是不太合适的。 应当在后端服务内完成一定聚合，将聚合后的搜索返回给前端。 这里介绍下在 Go 中如何使用 MongoDB + Tile 索引实现这件事。

上回 说到在 Go 里弄出了一个 tzf 的库，可以非常快速得到经纬度所在的时区信息。

当时的想法是用 Rust 实现出来然后用 maturin 制作 Python 扩展。

经过一段时间的摸索发现 Rust 的坑有点大，于是 2022-07-23 转换了方向，在 Python 里调用 Go 编译出来的 .so 文件。 验证 demo 还算简单 ringsaturn/tzf#11。

• 2022-05-29 01:04 +0800 立了个年度 Flag：在 Go 里用多边形搜索实现经纬度转时区
• 2022-05-29 20:47 +0800 搞出来了 https://github.com/ringsaturn/tzf

基本数据处理流程：

挺想用 Rust 实现一遍，然后用 pyo3 封装下，看看能不能比 Numba 加速的 timezonefinder 更快。