Java GIS 服务升级时，接口测试全绿并不能保证三维几何能渲染、PMTiles 缩放层正确、坐标转换走到预期操作。
GeoTools 35.1 于 2026 年 8 月 21 日发布，修复了 N 大于 2 的几何渲染、PMTiles 读取过深缩放层、逆向坐标操作、GML 3.2 几何类型、ImageMosaic 内存缓存、GeoParquet 主键识别与范围查询等问题，也加入 GeoParquet/DuckDB 的 S3 endpoint 和资源限制配置。它们跨越绘制、瓦片、坐标转换、数据源和查询优化，不能用一次 WMS 出图替代整体回归。
可核查事实
- GeoTools 35.1 于 2026 年 8 月 21 日发布。
- 发布说明修复了 N 大于 2 的几何（例如 MultiLineStringZM）在存储未遵守
FEATURE_2D提示时可能渲染失败的问题。 - PMTiles 读取被修复，避免取到比屏幕显示更深一级的缩放层。
PropertyCoordinateOperationFactory修复了逆向处理以及未使用 EPSG 预定义操作的问题。- GML 3.2 的几何类型不匹配问题获得修复。
- ImageMosaic 允许在内存中缓存小图像。
- GeoParquet/DuckDB 新增 S3 endpoint 与资源限制配置；无 id 列时可选择不做主键识别。
- DGGS feature collection 在 bbox 与属性同时筛选时可能漏返回要素的问题获得修复。
Resample2D与部分矢量重投影路径改为使用全部参考权威机构。
核心机制
渲染、查询和转换在 Java GIS 栈中常共享同一份数据，却遵循不同正确性标准。N 维几何的渲染要决定是否按二维绘制以及如何处理额外维度；PMTiles 的层级选择决定屏幕显示是否取到合适分辨率；坐标操作工厂决定逆向转换和 EPSG 操作能否被正确选中。GeoParquet/DuckDB 的 endpoint、资源限制与主键策略影响远程扫描和表结构推断；DGGS 的 bbox 加属性过滤则关系到结果是否完整。应把它们作为不同契约而不是单一“地图能显示”的结果。
技术路径
准备一组包含 Z/M 的线面、一个带多缩放级别的 PMTiles、需要正反向转换的 CRS 对、一个 GML 3.2 交换文件，以及有 id、无 id、空范围和复合筛选的 GeoParquet 表。
分别记录渲染后的几何、缩放级别和像素尺寸；对 PMTiles 在边界缩放级别抓取图块并比较屏幕尺度；对每个 CRS 对保存 EPSG 操作、正反向输出和误差阈值；对 GeoParquet 在受控 S3 endpoint、并发和资源限制下执行查询，并核对 bbox 与属性并用的返回行。最后把 ImageMosaic 小图缓存作为性能观察项，确认缓存不会改变像元值或 NoData 语义。
GIS 场景
地下管网、轨迹和测量成果常含 Z 或 M 值，地图服务必须保证二维展示稳定而不丢失业务维度。在线底图服务用 PMTiles 降低存储和传输成本，但过深层级会造成清晰度与负载异常。数据湖团队则可能经由 GeoParquet/DuckDB 访问对象存储；若 endpoint、资源限制或主键推断变化，查询计划和服务稳定性都会受到影响。跨标准交换和重投影项目还需要把 GML 与 EPSG 操作单列验收。
检查清单
- 是否用 Z/M 几何验证渲染、不渲染和导出的维度语义？
- 是否在相邻缩放层比较 PMTiles 实际请求和视觉清晰度？
- 是否保存正向与逆向 CRS 操作、EPSG 编号和允许误差？
- 是否对 GML 3.2 几何交换做读写回归？
- 是否以 bbox、属性及其组合检查 GeoParquet/DGGS 的结果完整性？
- 是否在目标 S3 endpoint 和资源限制下重跑 DuckDB/GeoParquet 查询？
风险边界
35.1 的修复不保证所有上游数据存储都会正确提供 FEATURE_2D、维度、坐标系或 PMTiles 元数据。内存缓存优化也不等同于任意工作负载的性能承诺。对象存储 endpoint 与资源限制必须按实际安全策略配置，坐标转换仍应依据项目区域、基准和精度要求选择操作。
结论
分别回归三维几何、瓦片层级、坐标操作和远程列式数据查询，才能把 GeoTools 35.1 的维护更新转化为 Java GIS 服务可验证的稳定性。