PostGIS ST_MakeValid 修复无效几何：类型变化、精度网格与入库校验
地块边界入库后，明明在桌面端看着闭合，PostGIS 的 ST_Intersection 却报 TopologyException；有人马上用 ST_Buffer(geom, 0)，有人直接删掉报错要素。两种做法都可能让错误暂时消失，却把多部件、孔洞或面积变化藏进后续分析。本文把无效几何的定位、修复和入库验收拆开，让修复结果可解释。
PostGIS ST_MakeValid 修复无效几何：先把问题拆成可验证的环节
GIS 工具往往能在几秒内给出一个结果，但“工具成功运行”并不等于结果可用。处理前先固定 数据版本、CRS、几何类型、字段语义和容差/尺度；处理后再核对数量、范围、面积或统计量。把这两组检查写进流程，问题才不会在交付阶段才暴露。
无效不等于“画得不好”
自相交、重复顶点、孔洞落在外壳外、相邻环方向异常，都会违反 Simple Features 的几何规则。它们在渲染时未必明显，却会影响叠加、面积和空间索引。先用 ST_IsValidReason 记录原因，而不是只看 ST_IsValid 的真假。
ST_MakeValid 可能改变几何类型
修复 bow-tie 自交多边形时，结果可能变为 MultiPolygon；退化边界甚至可能产生 GeometryCollection。下游字段要求 polygon 时，必须显式用 ST_CollectionExtract 取面，并再次验证，而不能假定输出类型不变。
精度网格应先于大规模叠加
来源不同的边界常有微小坐标噪声。ST_ReducePrecision 可以按业务精度收敛顶点，减少细缝和碎片；但网格大小必须小于成果允许误差，不能为了消除报错而粗暴取整。
可执行实操流程
- 建立隔离表并保留原始 geom、来源批次和要素 ID；先统计 ST_IsValid 为 false 的数量。
- 对异常行查询 ST_IsValidReason(geom)，按自相交、孔洞、退化面分组；随机在地图中查看每类样本。
- 对需要修复的数据先在小样本运行 ST_MakeValid；如业务只接受面，使用 ST_CollectionExtract(…, 3) 并转换为 MultiPolygon。
- 分别比较修复前后 ST_Area、ST_NPoints 和要素数；面积突变的记录进入人工复核清单。
- 通过后再写入正式表，并建立 GiST 索引；将修复 SQL、参数、源数据批次写入处理日志。
SELECT id, ST_IsValidReason(geom) AS reason
FROM parcels WHERE NOT ST_IsValid(geom);
UPDATE parcels_fix
SET geom = ST_Multi(ST_CollectionExtract(ST_MakeValid(geom), 3));项目避坑与质量检查
项目中最危险的是把修复结果直接覆盖原字段，事后无法解释一块地为何由一个面变成两个面。应始终保留 source_geom，并把修复类型、面积差和人工判定写成属性。若面积差超过地籍或规划业务允许阈值，宁可退回源数据，也不要自动通过。
| 检查项 | 合格信号 | 异常时优先排查 |
|---|---|---|
| 输入一致性 | 范围、CRS、字段含义可解释 | 数据源、坐标定义、空值 |
| 处理结果 | 数量与关键统计量符合预期 | 参数、分组条件、单位 |
| 空间抽检 | 边界与典型位置无明显异常 | 容差、精度、几何有效性 |
建议把“处理前后要比什么”写入项目 README。 这比保存一串截图更能让同事复跑，也能在数据更新时迅速判断差异究竟来自源数据还是算法。
FAQ
ST_MakeValid 后为什么变成 MultiPolygon？
自交环在拓扑上可能代表多个合法面，修复后拆成多部件是正常结果；应确认业务模型是否允许多部件。
能否一律使用 ST_Buffer(geom,0)？
不建议。它是旧式技巧，可能吞掉细节且难解释；优先使用 ST_MakeValid 并做类型和面积复核。
修复前是否需要 ST_ReducePrecision？
仅在已定义数据精度时使用。先试验网格大小并比较面积、顶点数，不能用它替代源数据质量治理。
总结
处理无效几何的关键不是“让 SQL 不报错”，而是识别失效原因、接受可能的类型变化，并为每一处修复留下可追溯证据。真正可靠的 GIS 成果不是某一次按钮点击后的图层，而是一套知道输入边界、参数理由和复核证据的可复现流程。