一些在查阅资料时了解到的历史片段

在 中国气象数据网•综合实况 的网页中，降水数据是以如下格式的瓦片路径加载的:

https://image.data.cma.cn/tiles/China/RADAR_L3_MST_CREF_GISJPG_Tiles_CR/20250126/13/06/3/2/6.bin

我对这个 BIN 文件非常好奇，于是在 Cursor 的帮助下尝试解析这个文件。

一般而言，常规的非图片格式的瓦片更多是 Mapbox 的矢量瓦片，而中国气象数据网的这个 BIN 瓦片文件不管是文件名 GISJPG_Tiles 还是实际的内容（降水）都不是矢量瓦片的常见使用场景。所以猜测这个 BIN 文件是自定义的。

在维护 PyPI 包和项目的过程中，我常遇到两大痛点：

1. 上传发布繁琐：过去，上传 PyPI 包通常需要配置 PyPI Token，有一定的安全隐患，同时还需要在本地或 CI 中打包上传，尤其是当涉及 .whl 文件的项目还需要额外的环境配置，工作量会增加不少。
2. 固定子依赖耗时：稍大型的 Python 项目，子依赖往往较多，不固定版本会有上游库的不兼容风险。传统工具如 PDM、Poetry 等在锁定依赖时速度不尽人意，在开发过程中不得不忍受漫长的耗时甚至固定失败。在 2021 年是我用 Poetry 固定一个项目花了 10 分钟还失败了，自此之后就不用了。

近两年内，这些问题有了舒服的解决方案。

工作中，我们用了 uv 来管理 Python 项目，可以快速安装依赖和固定子依赖的版本信息。 我在一段时间的休假回来后例行更新电脑上的包库，发现 uv 有了新版本，于是我就更新了 uv。 结果在一个项目中更新 uv.lock 文件后发现有很多依赖的 wheels 从锁文件中消失了。 比如如下配置的 pyproject.toml 文件：

在我休假回来之后，在 PyPi Stats 中发现 tzfpy 下载量增长了很多：

于是在 ChatGPT 的帮助下在 Big Query 上查了一下下载情况。发现来自 Amazon Linux 的下载量增长最多。 考虑到这个下载量和操作系统一般是商业公司。

背景：我有一个 API 项目 tzf-server，想利用 proto 文件生成 openapi.yaml 配合 Swagger 使用， 并且有与其一致的 HTTP API 供调用。很遗憾的是 Go 生态中尚未有能和 Python 生态中的 FastAPI 接近的 API 框架来简化业务代码编写和文档生成工作。 特别是 Hertz 框架，提供了很多功能甚至通过扩展支持了参数校验功能，但是这些并不能直接输出成 openapi.yaml 文件。 gRPC-Gateway 是一个不错的选择，但是尚不支持 OpenAPI V3。 还有一个隐藏的原因是在用 buf 管理 proto，但是 hertz 的生成工具怎么和 buf 一块使用没有相关的文档。所以我决定自己写一个。

在 日本制铁豪赌,钢铁行业开启新全球竞争 这篇文章中读到了一句话：

另一方面，与欧洲企业之间被认为存在看不见的壁垒。这就是 1990 年代中期美国贸易代表办公室(USTR)指出的所谓的“东缅甸协定”,被认为从 1970 年代开始就存在以现在的缅甸为分界线分栖共存的密约。如今，随着日本制铁进入印度市场，这一壁垒已经开始倒塌。

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

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

TLDR

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

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

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

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