坐标转换升级最容易出现一种假象：同一对坐标系还能返回数值，于是团队以为升级安全。PROJ 9.9.0 于 2026 年 9 月 15 日发布，更新至 EPSG v13.102，新增 proj_crs_is_dynamic()，并让 cs2cs 在动态源或目标 CRS 缺少历元时告警；同时加入 TIN GeoPackage 的 tinshift、EPSG:32600/32700 横轴墨卡托分带网格和多项操作优化。这些变更覆盖了库数据、操作挑选与命令行提示，不能用一组坐标的数值相等替代升级验收。
可核查事实
- PROJ 9.9.0 的发布说明将数据库更新至 EPSG v13.102。
tinshift新增对 TIN GeoPackage 文件的支持。- 该版本实现 Transverse Mercator Zoned Grid System，并列出 EPSG:32600 和 EPSG:32700。
- C API 新增
proj_crs_is_dynamic()。 cs2cs会在源或目标 CRS 是动态坐标系但未提供历元时给出告警。createOperations()调整了 datum ensemble 与另一地理坐标基准之间的操作选择。- 迭代 Aitoff 反算被替换为闭式解。
projinfo --crs-extent-use none的行为获得修复。
核心机制
PROJ 的结果不是单纯的投影公式输出。数据库版本决定可识别的 CRS 和坐标操作；动态 CRS 还需要观测历元来确定时间相关转换的语义；操作工厂则在多个候选路径中选择可执行路径。9.9.0 的告警并不自动补全历元，它只是把过去可能静默发生的语义缺失暴露出来。因此验收的目标应是确认输入 CRS、历元、候选操作与输出精度的组合，而不是只确认程序未报错。
技术路径
先冻结一批有代表性的 GIS 样本：静态二维 CRS、带高程的复合 CRS、动态 CRS，以及须使用网格或本地 datum 的项目数据。记录升级前后 projinfo 的候选操作、使用的网格、精度说明和输出坐标。对动态样本分别带入业务历元和省略历元运行，前者检查结果和选择路径，后者必须将 cs2cs 告警视为待修复输入。再把 TIN GeoPackage 与新分带网格作为独立案例，确认数据格式、区域范围和 EPSG 编号都符合工程设定。
GIS 场景
地籍、工程测量和时序形变项目经常把不同年份采集的位置叠加到一个 GIS 图层中。此时“坐标系名称匹配”并不足够：动态参考框架的历元缺失可能改变转换解释。地图服务团队还应把 API 调用、批处理脚本和桌面 GIS 导出分别回归，因为它们传递历元、网格文件和 PROJ 数据目录的方式可能不同。对于新分带或 TIN 改正模型，先把 AOI 限制在官方操作适用范围内，再扩展至生产数据。
检查清单
- 是否锁定 PROJ 版本与 EPSG 数据库版本？
- 是否列出每个关键 CRS 对的候选操作、网格与适用范围？
- 动态 CRS 是否显式传入业务观测历元？
- 是否将
cs2cs的缺历元告警纳入构建或批处理日志检查？ - 是否分别验证二维、三维、高程和本地改正样本？
- 是否用独立 GIS 读取器抽查输出坐标、轴顺序和单位？
风险边界
EPSG 数据库更新和操作选择优化可能使同一输入选择不同的合法路径；这不必然是回归，但必须由项目的精度、区域和历元要求判断。proj_crs_is_dynamic() 只能识别动态性，不能推断数据采集时间。TIN GeoPackage、新分带网格或闭式反算的加入也不等于所有下游桌面软件和服务已随之支持，生产升级仍需以目标链路的真实样本验收。
结论
将 PROJ 9.9.0 视为一次坐标操作链路升级：先固定数据库和输入历元，再审阅候选路径与告警，最后用目标 GIS 客户端复查输出，才能把版本更新转化为可追溯的空间数据结果。