第03章 存储、计算与几何投影的底线
本章导读
这一层最不性感，但错误最贵。本章接在第02章的数据层之后，对应原报告 3.3 节与 3.4 节：前者把存储与计算分成事务型、分析型、实时型三条路线，并交代湖仓带来的版本化能力；后者处理投影、拓扑、精度与高程基准四条正确性底线。两者合读的理由是，选型错通常只是慢或贵，正确性错则是结论整体作废，而且往往到交付后才被发现。要带走的判断是：存储按数据量与时效分界，几何按“度量与展示分开”的原则设防，任何一层都不该用一套参数覆盖所有场景。
学习目标
读完本章，你应当能够：
- 按 3.3 节为三类需求（高并发事务更新、十亿级全表空间聚合、分钟级轨迹更新）各选一条存储与计算路线；
- 说出 PostGIS 3.6.0 的适用边界与三处破坏性变更，写出一次升级前的回归清单；
- 解释 H3/S2 网格编码为什么能把“附近查询”变成键值问题，并说明它的精度与边界代价；
- 用 3.4 节识别四类几何与投影错误，指出各自最可能在哪个环节暴露；
- 为一份跨市汇交数据写出坐标、投影带、高程基准的声明清单，标出缺失项的后果；
- 说明湖仓的时间旅行为什么把“数据版本”从应用层补丁变成存储层能力，并列出它对审计的作用。
3.3 存储与计算：三条路线的分工
3.3.1 事务型：PostGIS 仍是基准
PostGIS 3.6.0 于 2025 年 9 月发布，要求 PostgreSQL 12—18beta3，推荐搭配 GEOS 3.14；完整功能需要 SFCGAL 2.2.0+〔来源：postgis.net 发布公告，2025-09〕。它的价值不在“能存几何”，而在二十年积累的空间谓词、索引（GiST/SP-GiST/BRIN）、拓扑与栅格能力，以及“事务一致性 + 空间查询”的组合——这是分析型引擎难以替代的。
适用边界：并发写入、事务更新、权限与审计要求高的场景（如不动产、管线、权属）首选 PostGIS；单表十亿级以上的全表空间聚合，它会成为瓶颈。
升级要小心（容易被忽略的运维风险）：3.6.0 引入了几处破坏性变更——ST_TileEnvelope 会把信封裁剪到瓦片平面范围、geometry_columns 视图移除约束检查、TIN 与 PolyhedralSurface 的 ST_NumGeometries 语义改为按整体计（需改用 ST_NumPatches），拓扑模块的大量函数签名也变了。3.6.1／3.6.2 还要求拓扑库升级后执行修复脚本处理损坏的 TopoGeometry 列。实践建议：升级前先在副本上跑一遍全量回归，尤其是依赖瓦片生成与拓扑的数据管线〔来源：PostGIS 发布说明，2025-09〕。
3.3.2 分析型：单机列式与分布式并存
2025 年最值得注意的变化是单机分析引擎的能力跃升。DuckDB 的 spatial 扩展让“读 Shapefile/GeoPackage/GeoParquet → 空间连接 → 导出”在笔记本上完成，且性能经常优于配置不当的 Spark 集群。Apache Sedona 在 2025 年做了两件对症的事：推出 SedonaDB（单机空间分析引擎），以及 SpatialBench（可复现的空间 SQL 性能基准）〔来源：Apache Sedona 2025 Year in Review，2026-01-11〕。基准的出现比任何单点性能数字都重要——它让“哪个引擎更快”从厂商话术变成可验证问题。
分布式侧，Sedona 覆盖 Spark/Flink/Snowflake，2025 年发布 1.7.1、1.7.2、1.8.0、1.8.1 四个版本，后续推进到 1.9 系列（补齐 Spark 4.x 与 Geography 类型支持），并在 2025 年加入 GeoStats 模块（DBSCAN、LOF、Getis-Ord Gi/Gi* 热点分析）〔来源：Apache Sedona 2025 Year in Review，2026-01-11〕。这个细节值得展开：空间统计进入 SQL 引擎意味着“热点分析”从 Python 脚本变成可调度、可增量、可审计的数据管道步骤，这是分析工程化的关键一步。
3.3.3 实时型：流式空间处理
实时场景（车辆轨迹、物联感知、灾害预警）要求“秒级到达、秒级索引”。典型架构是消息队列 + 流处理（Flink）+ 空间索引（H3/S2 网格或内存 R-Tree）+ 时序库/宽表。这里的关键设计不是引擎，而是网格编码：用 H3 或 S2 把连续空间离散成单元格，把“附近查询”变成“单元格集合 join”，从而把空间问题降维成普通键值问题。代价是精度损失与边界效应，需要按业务容忍度选择分辨率。
3.3.4 湖仓：空间数据的版本化
Iceberg/Delta/Hudi 提供 ACID、时间旅行与模式演进，把“数据版本”变成存储层能力而非应用层补丁。对 GIS 分析的意义在于可复现：任何一次分析结果都能追溯到“当时读的是哪个快照”。这在合规审计与模型回溯场景中价值极高，也应成为 2026 年后新建数据平台的设计默认。
3.4 几何与投影：正确性的底线
这一层最不性感，但错误最贵。四个常见陷阱：
投影选错。 用 Web Mercator（EPSG:3857）计算面积，在高纬度会严重高估；中国的法定坐标系是 CGCS2000，业务中还会遇到 GCJ-02（互联网地图加密偏移）与 BD-09。跨坐标系直接混合计算是错误源头。原则：度量计算用等积/等距投影或椭球面算法，展示用 Web Mercator，绝不混用。
拓扑无效。 自相交、重复点、悬挂边会让空间谓词返回意外结果，且不同引擎对无效几何的容忍度不同。生产管线应在入库前做 ST_MakeValid 类修复并记录修复日志，而不是等到分析结果异常再排查。
精度幻觉。 双精度在 ECEF 坐标（量级 6.4×10⁶ 米）下的有效小数位有限，渲染时需要在局部 ENU 坐标系中做“高精度相对定位 + 低精度绝对定位”的分离，否则会出现顶点抖动。这是三维项目的经典坑。
基准面不一致。 高程有 1985 国家高程基准、大地高、正高之分，混用会导致米级到十米级误差。分析涉及淹没、坡度、通视时，必须显式声明高程基准。
本章小结
- PostGIS 3.6.0（2025 年 9 月发布）仍是事务型空间数据的基准实现，价值在二十年积累的空间谓词、索引与“事务一致性 + 空间查询”；单表十亿级以上的全表空间聚合会成为瓶颈。
- 升级 3.6 要按破坏性变更对待：ST_TileEnvelope 裁剪到瓦片平面范围、geometry_columns 移除约束检查、TIN 与 PolyhedralSurface 的 ST_NumGeometries 改为整体计数（需改用 ST_NumPatches），拓扑函数签名亦有变化。
- 单机分析引擎的能力被低估：DuckDB spatial 与 SedonaDB 让多数探索性分析在笔记本上完成；SpatialBench 这类可复现基准，比任何单点性能数字更有价值。
- 空间统计进入 SQL 引擎是分水岭——热点分析从脚本变成可调度、可增量、可审计的管道步骤，这是分析工程化的关键一步。
- 实时场景的关键设计不是引擎而是网格编码：H3/S2 把“附近查询”变成“单元格集合 join”，代价是精度损失与边界效应，分辨率要按业务容忍度选。
- 几何与投影必须分工：度量计算用等积/等距投影或椭球面算法，展示用 Web Mercator，绝不混用；Web Mercator 在高纬度会严重高估面积。
- 拓扑无效与基准面不一致是两类静默错误：前者让空间谓词返回意外结果，后者在淹没、坡度、通视分析中造成米级到十米级误差。
思考与练习
- 取一份你单位现有数据，列出坐标系、投影带、高程基准三项声明，标出缺失项并说明补不齐的后果。
- 测一次：用 Web Mercator 与所在纬度合适的等积投影分别计算同一区域面积，记录差异并决定上报口径。
- 辨析：有人说“数据量大就上 Spark”。用 3.3.2 节判断这句话在什么条件下成立、什么条件下是浪费。
- 应用：为“车辆轨迹实时监控 + 早晚高峰热点统计”给出存储、计算、网格编码三层方案，并说明分辨率怎么定。
- 写一份 PostGIS 3.6 升级前的回归清单，至少覆盖瓦片生成与拓扑两条管线，说明每条怎么验。
- 你的三维项目出现顶点抖动。按 3.4 节的精度幻觉解释成因，并给出至少一种缓解做法。