上个月处理某行政区划专题图，入库脚本跑完，面积字段里跳出来十几个负数。第一反应是数据损坏，抓过原始GeoJSON仔细比对，坐标没丢、顶点没乱，问题出在“顶点顺序”和入库脚本的预期不一致。这个坑在接高德区划这类开放边界数据时出现的概率，比很多同学想的高得多。只要入库逻辑里缺少几何规范化步骤，哪怕是同一份数据，也可能一部分面积是正数、一部分是负数。这篇把这套问题的根源、检测方法、修复脚本和防再发措施完整记录下来，给后面处理区划数据入库、面积统计的同学当参考。
1. 问题现象与影响范围：负面积会拖垮整条业务链
1.1 负面积是怎么混进数据库的
先假设一个很常见的区划表结构：字段包含fid、name、geom、area_km2。数据源是高德开放平台下载的行政区划 GeoJSON，入库脚本拿到文件后，对每个 Polygon 的coordinates数组直接套用一段通用“经纬度面积算法”，算完把结果写入area_km2。这套流程对大多数区划都正常，偏偏对少量区划返回负数。
这里要明确一点：负值不是数据文件坏了。从原始 GeoJSON 里把坐标拉出来看，边界点一个不少，只是这些点的排列方向和入库脚本默认的方向相反。面积算法本身没问题，它对带符号的“绕行方向”很敏感。你把多边形顶点按逆时针走一圈和按顺时针走一圈，平面面积计算出来的数值绝对值相同，符号完全不同。这就是为什么同一套代码在同一批数据上，会出现“大部分正常、个别负值”的现象。
自研入库脚本大多没有“几何规范化”这一步。专业 GIS 工具在导入时会自动处理环方向，但很多轻量级入库程序只是简单读取 coordinates 数组，然后丢进面积函数。高德区划数据里恰好混有不同方向的环，负值就这样产生了。
1.2 一个负数对下游分析意味着什么
面积字段是所有地理统计的基础。面积一旦出现负值，下游做人口密度、人均设施、森林覆盖率这类计算时，负面积会把指标的分子分母关系彻底打乱。比如统计某片区域的总面积，原本该把各区加起来，结果一个负数直接把合计削掉一大块，最后的图表能明显看出数据不对，但又不知道是哪条记录惹的祸。
更隐蔽的问题是几何方向错误。很多空间操作，例如判断点是否落在面内、计算两个面的相交区域、输出 Web 地图时的渲染填充规则，都依赖环方向的正确性。负值只是表层信号，真实风险在于这些空间查询和渲染结果会连带出错。所以修复的目标不是把-152.36改成152.36这么简单，而是要让多边形整体恢复到规范方向。
1.3 最容易踩中的三种入库场景
根据我接触过的项目，负面积集中出现在三类场景里，整理成表格方便对照：
| 场景 | 典型表现 | 根因 |
|---|---|---|
| 自研脚本直接解析 GeoJSON | 个别要素面积报负 | 入库阶段没有做环方向规范化 |
| 多渠道数据混合导入 | 正负面积交替出现 | 不同来源数据的顶点方向约定不一致 |
| 老脚本升级后重新入库 | 历史正常的区域忽然变负 | 代码升级改变了面积算法，却没有同步做几何修复 |
这三种场景有个共同点：入库流程都默认“数据文件里的顶点顺序是统一的”。高德这类开放区划数据虽然有更新日志和规范说明，但真实文件里的环方向并不保证全球统一，尤其历史存量数据更是如此。拿一个固定方向的算法去算所有数据，负面积迟早会出现。
2. 为什么坐标顺序能决定面积正负：把鞋带公式讲透
2.1 多边形面积公式里的“符号”从哪来
多边形面积计算有个经典的鞋带公式，也叫高斯面积公式：
$$S = \frac{1}{2} \sum_{i=0}^{n-1}(x_i \cdot y_{i+1} - x_{i+1} \cdot y_i)$$
它把多边形每条边的坐标叉积累加起来再取一半。这里的关键在于“叉积”是有符号的。几何上，顶点沿逆时针方向绕行时，累加结果为正；沿顺时针方向绕行时，累加结果为负。同一个三角形，你按(0,0)->(1,0)->(0,1)的顺序排列，结果是正数；反过来排，结果是负数。
用生活里的例子理解：你围着同一块草地散步，顺时针绕一圈和逆时针绕一圈，路程一样，但“累计向左转的总量”和“累计向右转的总量”正好相反。鞋带公式里那个负号，本质就是在记录这种绕行方向差异。很多直接从坐标算面积的脚本没有对环方向做统一，于是正的负的全都有。
2.2 高德区划数据的顶点顺序现状
GeoJSON 的规范提到过外环建议使用逆时针方向，内环用顺时针方向，但现实中的存量数据远没这么干净。高德区划数据来源复杂，有的边界来自早期采集成果，有的是在制图软件里手动裁剪生成，还有的是后续人工编辑修补过的。这些过程都会影响环方向，最终产出的 GeoJSON 里，有的外环是逆时针，有的外环是顺时针。
更麻烦的是带洞的区划面。一个行政区划如果有飞地或者内部湖泊，它的几何对象是“外环 + 内环”的结构。外环方向和内环方向组合起来，对最终面积符号的影响并不直观。我整理了一个简化版本的方向组合表：
| 外环方向 | 内环方向 | 鞋带公式结果 | 说明 |
|---|---|---|---|
| 逆时针 | 顺时针 | 正 | 符合新版 GeoJSON 规范的写法 |
| 顺时针 | 逆时针 | 负 | 常见于历史数据，入库后容易报负 |
| 逆时针 | 逆时针 | 数值被抵消 | 内外环方向混排，面积可能偏小 |
| 顺时针 | 顺时针 | 数值被抵消 | 内外环方向混排，面积可能出现异常 |
实际修复时，只要把外环强制定为逆时针、内环强制定为顺时针，绝大多数符号问题就解决了。这里有个容易踩的细节：有些区划几何是 MultiPolygon，也就是由多个 Polygon 组成，每个 Polygon 都要单独处理，不能只取第一个 Polygon 的方向做全局判断。
2.3 方向问题与坐标系问题是两码事
负面积还有个很容易被混在一起的兄弟问题：坐标参考系。高德区划数据用的是经纬度坐标，也就是 EPSG:4326，单位是度。如果你直接把经纬度坐标丢进鞋带公式，算出来的结果单位是“度平方”，根本不能当面积用。就算方向完全正确，数字也是错的。
方向问题决定的是正负号，坐标系问题决定的是量纲。修复方向可以让-152.36变成152.36，但如果这个数本身是从经纬度直接算出来的，那152.36依然不是有效的平方公里数。正确做法是先统一坐标参考系，把几何转成投影坐标（比如 EPSG:3857 或当地等积投影），再计算面积；或者使用空间数据库里的geography类型接口，它能直接基于椭球体算真实距离和面积。修复面积前，先想清楚自己到底在修哪个层面的问题，这两个层面不能混为一谈。
3. 修复方案分层：入库前、入库中与查询层的取舍
3.1 入库前做几何规范化：最干净的解法
如果数据还没有落到正式业务表里，我强烈建议在入库前完成几何规范化。这个阶段改数据没有任何下游影响，成本最低。Python 生态里最顺手的是 Shapely，它提供了orient函数，可以统一多边形外环和内环方向。
下面这段代码可以直接嵌进入库脚本，也可以在解析 GeoJSON 后作为独立清洗步骤跑一遍：
import json from shapely.geometry import shape from shapely.ops import orient from shapely import make_valid def normalize_geometry(raw_geometry): geom = shape(raw_geometry) if not geom.is_valid: geom = make_valid(geom) if geom.geom_type in ("Polygon", "MultiPolygon"): # sign=1.0 表示外环逆时针、内环顺时针 return orient(geom, sign=1.0) return geom def process_geojson(geojson_path): with open(geojson_path, "r", encoding="utf-8") as f: data = json.load(f) for feature in data["features"]: feature["geometry"] = normalize_geometry(feature["geometry"]) return data这里要注意make_valid的返回值。如果原始几何存在自相交之类的结构问题，make_valid可能返回 MultiPolygon 甚至 GeometryCollection，类型不一定和原来一致。实际项目中我会在调用后打印geom.geom_type做一轮抽样确认，避免后续写入时字段类型对不上。orient操作不改变坐标值本身，只调整顶点排列顺序，所以理论上不会把边界“修坏”，但处理完还是要跑一遍is_valid校验。
3.2 入库后用 PostGIS 批量修复：存量数据救急
如果数据已经躺在库里，不方便重新导入，那就直接在数据库里修。PostGIS 提供了一组针对环方向的函数，典型链路是“先修复结构，再统一方向，最后重算面积”。
备份这步不能省。生产环境执行前，先用pg_dump单表备份：
pg_dump -t geo_district your_database > geo_district_backup.sql然后在一个事务里执行批量更新：
BEGIN; UPDATE geo_district SET geom = ST_ForcePolygonCCW( ST_Force2D( ST_MakeValid(geom) ) ) WHERE area_km2 < 0 OR ST_IsValid(geom) = false; UPDATE geo_district SET area_km2 = ROUND( ST_Area(ST_Transform(geom, 3857)) / 1000000, 4 ); COMMIT;ST_ForcePolygonCCW会把外环调整成逆时针方向，这个方向正好对应新版 GeoJSON 的约定。如果业务方用的底图系统偏好顺时针外环，那就换成ST_ForcePolygonCW，关键是全库统一。ST_MakeValid负责清理自相交等结构问题，ST_Force2D则是把可能携带的 Z 坐标去掉，避免三维坐标干扰二维面积计算。
3.3 查询层取绝对值：为什么我不推荐
见过不少人图省事，在查询语句里写ABS(ST_Area(geom))或者ABS(area_km2)，把负数转成正数就完事。这种方法在即时取数场景里能临时掩盖问题，但我从来不建议把它作为长期方案。
核心原因是方向问题会传导。ABS 只能改面积字段，几何对象本身的环方向还是错的。后续一旦有别的流程对这个 geom 做空间分析，比如判断点是否落入区划、计算缓冲区、做 Web 渲染填充，错误方向依然会引发各种奇怪结果。你只是把负面积藏起来了，本质的几何病灶没有清除。
更难受的是问题会延迟暴露。今天你用 ABS 糊住了报表，明天另一个团队直接读 geom 做分析，他们看到的还是带病几何，到时候排查成本会翻倍。我的原则是：查询层可以用 ABS 做临时急救，但必须同步安排数据层的真正修复，不能把急救措施当日常方案。
4. 实战记录：从定位负值到回归验证的完整过程
4.1 第一轮：把负面积和数据形态全部捞出来
先要确认负值的分布情况，不要凭感觉猜。最简单的 SQL 直接查面积小于零的记录：
SELECT fid, name, area_km2 FROM geo_district WHERE area_km2 < 0 ORDER BY area_km2;如果库里没有现成的面积字段，或者你想复核几何本身的健康程度，再跑一遍方向检测：
SELECT fid, name, ST_IsPolygonCW(geom) AS is_cw, ST_IsPolygonCCW(geom) AS is_ccw, ST_IsValid(geom) AS is_valid FROM geo_district WHERE area_km2 < 0;ST_IsPolygonCW和ST_IsPolygonCCW在 PostGIS 2.4 以上版本可用。如果你用的版本较老，也可以抽一条记录，用 Python 脚本按原始坐标算一遍带符号面积，逻辑不复杂：
def ring_signed_area(coords): area2 = 0.0 for i in range(len(coords) - 1): x1, y1 = coords[i] x2, y2 = coords[i + 1] area2 += x1 * y2 - x2 * y1 return area2 / 2.0把这几个值放到一起对比，很快就能判断负面积到底是“顶点方向反了”还是“几何结构错了”。我这次遇到的情况是方向反了占绝大多数，中间还夹着两个自相交要素，所以修复逻辑需要两条腿走路：先修结构，再修方向。
4.2 第二轮：备份后跑批量修复
备份命令前面已经给过，这里强调一下备份后的校验。备份文件生成后，我在本地临时库恢复了一次，确认文件可读且行数一致，才开始动正式库。别觉得这道工序多余，数据库操作最怕“以为备份了，真出问题时才发现备份没成功”。
正式修复使用上一节里的两个UPDATE语句，先跑第一个更新几何，再跑第二个重算面积。执行过程中我用WHERE area_km2 < 0 OR ST_IsValid(geom) = false锁定了目标记录，没有做全表无差别更新，这样能减少影响范围。
这一步要注意事务控制。我在语句外面包了BEGIN和COMMIT，如果执行到一半发现报错，直接回滚，不会留下半修复状态。对于几千条级别的区划数据，整个事务几秒钟完成；如果是几十万条级别的数据，建议拆成批次处理，避免长时间锁表。
4.3 第三轮：面积重算与结果对照
修复完成后，重新统计一下全局状态：
SELECT COUNT(*) FILTER (WHERE area_km2 < 0) AS negative_cnt, COUNT(*) AS total_cnt, ROUND(SUM(area_km2), 2) AS total_area_km2 FROM geo_district;正常情况下negative_cnt应该归零。接着抽查几条原本报负的区域，把修复前后的面积放在一起看：
| 记录 | 修复前面积(km²) | 修复后面积(km²) | 状态 |
|---|---|---|---|
| A区 | -152.36 | 152.36 | 方向已纠正 |
| B区 | -0.48 | 0.48 | 方向已纠正 |
| C区 | 120.15 | 118.62 | 结构修复，面积微调 |
前两条只是方向翻转，所以绝对值不变，这是最理想的情况。第三条本来存在自相交，ST_MakeValid把重叠部分拆分后，面积数值发生了微小变化，这也正常。修复自相交本来就会改变面积口径，需要对业务方说明这一点。
4.4 第四轮：把防再发机制写进入库流程
数据修完只是治标，如果入库流程不改造，下次导别的新数据还会复发。我在这次修复后做了一件事：把面积计算从业务代码里迁移到数据库生成列，并且新增一条巡检 SQL。
面积字段改为生成列，可以这样写：
ALTER TABLE geo_district DROP COLUMN area_km2; ALTER TABLE geo_district ADD COLUMN area_km2 double precision GENERATED ALWAYS AS ( ROUND(ST_Area(ST_Transform(geom, 3857)) / 1000000, 4) ) STORED;这里需要注意，生成列只能在固定的表达式上工作，如果geom还没定好 SRID，或者里面混有非 Polygon 类型，就会报错。所以入库时还是要先保证几何合法、方向统一，再交给数据库自动算面积。
巡检 SQL 则简单一些，每天跑一次，结果为空就代表正常：
SELECT fid, name, area_km2 FROM geo_district WHERE area_km2 < 0;我把这条命令挂进了定时任务，一旦出现负值就发告警，避免了下次再靠人工翻报表才发现问题。
5. 常见问题与避坑清单
5.1 修复后为什么又出现负值
如果修复完隔几天又冒出来负数，先别急着怀疑修复语句有问题。常见原因是 ETL 流程在修复语句之后又运行了一遍，把旧数据或者旧计算逻辑重新覆盖了geom或area_km2。我遇到过类似场景：上游每天增量同步一次区划表，同步脚本里自带一套面积计算，只覆盖部分字段，结果把刚修好的记录又打回原形。
排查思路很直接，看数据更新时间，再看 ETL 日志里最后一次更新该表的部分。如果确实是覆盖问题，就把修复逻辑挪到 ETL 的末尾，让它成为所有写操作完成之后的收尾步骤。
5.2 用 ST_MakeValid 修复自相交后，面怎么变多了
ST_MakeValid的做法是把自相交区域拆成多个合法面再重新组合，所以一个 Polygon 可能变成 MultiPolygon，如果分裂出的部分是碎片，结果甚至可能是 GeometryCollection。这在面积计算上通常没问题，但在 Web 渲染或某些业务系统里，GeometryCollection 并不是所有端都能直接支持。
遇到这种情况，一种处理方式是用ST_CollectionExtract只提取其中的多边形部分：
UPDATE geo_district SET geom = ST_CollectionExtract(ST_MakeValid(geom), 3) WHERE ST_GeometryType(geom) <> 'ST_Polygon';注意参数3表示只提取 Polygon 和 MultiPolygon。执行后面积之和会保持一致，只是几何结构变了。如果业务非常依赖原始边界形态，那就要在修复前评估清楚，别让自相交修复把“看起来更像原状”的边界拆成一堆碎块。
5.3 数据量大、更新慢怎么办
区划数据通常是几千条级别，一条事务跑完没什么压力。但如果处理的是乡镇级甚至村级边界，量级可能到几十万条，这时候盲目丢一个全表 UPDATE 就会锁表很久。我的建议是按主键分批跑，例如每批处理一万条，循环执行：
UPDATE geo_district SET geom = ST_ForcePolygonCCW(ST_Force2D(ST_MakeValid(geom))), area_km2 = ROUND(ST_Area(ST_Transform(geom, 3857)) / 1000000, 4) WHERE fid IN ( SELECT fid FROM geo_district WHERE area_km2 < 0 OR ST_IsValid(geom) = false ORDER BY fid LIMIT 10000 );分批执行时要注意观察事务耗时。如果原表有很多空间索引，大批量更新会让索引维护开销变得很高。更稳妥的做法是先把数据导入一张空表，处理好之后再通过表名切换上线，这样正式库的锁表时间只发生在最后切换的瞬间。
5.4 方向修复前先查 SRID
这条是我自己踩过的坑。曾经有一张表的部分几何是 EPSG:4326，部分是 EPSG:3857，混在一起。我直接跑了ST_ForcePolygonCCW，方向确实统一了，但坐标系不一致的问题依然存在，算出来的面积依旧完全不可信。方向修复和坐标参考系修复是两件事，但每次动手前都要先确认所有几何的 SRID。
检查方法很简单：
SELECT DISTINCT ST_SRID(geom) FROM geo_district;如果查出多个 SRID，就要先用ST_Transform统一目标坐标系，再跑方向修复。顺序不要搞反，理由是ST_ForcePolygonCCW只处理顶点顺序，不会根据坐标系来做任何坐标换算，方向对了不代表位置对了。
5.5 面积口径尽量在表注释里写清楚
高德区划数据的边界坐标带有自身坐标系体系，和通用的地理坐标系之间存在偏移。不同数据处理环节使用不同投影方法，最终算出来的平方公里数也会略有差异，这是正常的。但如果没有在表注释或数据字典里写清楚口径，后续业务方就会拿着两个略有差异的数字来质问数据库团队。
我会在修复完成后，给面积字段补一段注释，写明：面积基于哪版几何数据、统一到什么 SRID、采用投影坐标系算的，还是geography接口算的，四舍五入保留几位小数。下次无论是审计还是业务核对，都能按图索骥，省去大量扯皮时间。
这次修完负面积，我做的最有价值的动作是把面积计算从散落的业务代码里挪进了数据库生成列，并且每天加了一条巡检脚本，只要出现area_km2 < 0就发警告。这样下次再拿到外部区划数据，不用等到报表难看才被发现。如果你现在库里也有少量负面积，按上面流程走一遍就能解决；如果数据量很大，核心思路也一样，只是要分批执行和验证。最后再分享一个小细节：ST_ForcePolygonCCW只调整顶点顺序，不会修正坐标系。修复前一定要先确认所有几何的 SRID 一致，否则方向对了、位置歪了，面积还是一笔糊涂账。
