上周花了点时间学习下 mbtiles 文件格式，顺手给 tzf 项目制作了一个 social preview media: 制作流程很简单: 安装 https://github.com/mapbox/tippecanoe 安装 https://github.com/mapbox/mbview 下载时区的 GeoJSON 文件 1 2 3 # 根据 GeoJSON 制作 .mbtiles 文件 tippecanoe -o timezone.mbtiles -l Timezons -z7 combined-with-oceans.fmt.json mbview ./timezone.mbtiles 网页里调整合适的角度，截图，调整下图片的分辨率即可。

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

警告这篇文章的内容已经被废弃，仅供参考。tzfpy 已经用 Rust 重写。 ...

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

由于过往的各种条件限制，如数据库性能不够、PaaS 平台功能不足、对特定领域的问题理解不充分，线上的服务一定会有很多妥协解决方案。这些问题不会让服务彻底不可用，但一定会困扰团队，容易让人担忧系统的可靠性。特别是提供 toB 服务而言可靠性与准确性是一样重要的。 ...

看的书不多，在了解到的中国历史有两段我觉得称得上典型的时期，一个乱世，一个在某些人看来「有点乱」。第一个是北宋末年的汴京之围《汴京之围》：在北宋的朝廷内，随着勤王军队的到来，那些求和的大臣也在加紧行动。如果金军最终被勤王军击溃，就意味着他们主持的求和工作是错误的，这些大臣很可能被愤怒的群众撕成碎片。只有让金军尽早离开，才能证明他们的求和是正确的，不需要承担责任。因此，北宋君臣也越来越配合金军的赔款移交工作。于是产生了奇怪的一幕，一方面，军事将领们变得越来越高调，另一方面，北宋的搜刮工作也在加速，皇帝由于参与了求和，甚至眼都不眨就将祖宗传下的财宝尽数献出，换取金军赶快离开。当皇帝舍弃的东西越多，求和的大臣们越赞赏皇帝的大公无私。接下来皇帝更是将各种美食、珍禽、驯象送给金军，甚至女人都送过去为金军服务。 ...

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

简而言之，写了个工具包