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 索引实现这件事。

tzfpy 是 tzf 的 Python binding。 如果只是本地可用，Go 代码加上 CGO 扩展编译成 .so 文件就能用了。 不过要做成发布到 PyPI 上在其他地方能直接安装的 wheel 是有些曲折的，看 CI 失败的记录就挺明显的。

上回 说到在 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 更快。

在 Go 里定义 struct 及其序列化&反序列化的方式都是通过 Tag 的方式做的， 但是在我开始使用 Apollo 的时候没有找到社区的解决方案，所以翻了下 BSON/JSON/YAML 的反序列化实现方式， 觉得用反射机制好像是可以做的，于是就开搞了，项目在 https://github.com/caiyunapp/oap。

好奇想试下能否实现聚合一些数据然后再处理，情况是：

1. 有多个生产者在生产数据；
2. 消费者尽量批量处理，比如一个批次是 10；
3. 有个最小处理时间间隔， 比如生产者有 20ms 没有添加任务了，需要把积累的数据（如有 6 个）推到 out chan 中； 如果没有积累的数据就继续空转；

基本实现：