Catching bad geometries at ingestion is only half the problem. The other half is knowing when your transformations corrupt them.
I wrote previously about silent errors in geospatial pipelines - geometries that pass validation but produce wrong results. Those errors typically happen at the boundary of your system, when you’re loading data from external sources. You can catch most of them with better validation: check winding order, enforce CRS consistency, flag suspicious areas.
But what about errors that happen inside your pipeline? When your own transformations introduce corruption?
A few months after we fixed our winding order issues, we had a different problem. A coordinate transformation was working perfectly in testing. The geometry stayed valid. The pipeline ran clean. But three weeks into production, a client noticed their farm boundaries had shifted a few meters east. The centroid had drifted during the CRS conversion, and nothing in our monitoring caught it.
The transformation was technically correct. PostGIS didn’t error. But the output didn’t match reality. And by the time we noticed, we had processed hundreds of thousands of polygons with the same subtle shift.
This is the challenge with geometric transformations. They always change your data. That’s their purpose. The question is whether that change is acceptable or corrupted.
From validation to observation
At ingestion, you’re asking: “Is this data correct?” During processing, you’re asking: “Did my transformation break it?”
These are different questions. The first is about the quality of external data. The second is about the behavior of your own code. And the second question is harder to answer because legitimate transformations and corrupting transformations often look identical at the code level.
When you simplify a high-resolution polygon, it will have fewer vertices. That’s expected. When you transform coordinates between systems, there will be small distortions. That’s expected. When you clip a dataset against another boundary, the area will change. That’s expected.
At scale, you cannot manually inspect every geometry to verify the changes are reasonable. You need automated checks that alert you when the data drifts beyond acceptable bounds.
This is what I mean by spatial observability. In standard backend systems, we monitor latency and error rates. In geospatial pipelines, we also need to monitor geometric properties before and after each transformation. Not to catch invalid geometries, we already handled those at ingestion, but to catch when valid operations produce unreasonable results.
What to measure
After running these systems for a few years, I’ve found three metrics catch most spatial corruption during processing.
Area conservation is the most critical. Total area should remain relatively stable across transformations. If you’re clipping a dataset and the resulting area is zero or significantly higher than the input, something is wrong. This catches CRS mismatches that made it past validation, invalid geometry operations, and logic errors in spatial joins.
Centroid displacement catches coordinate problems that area checks miss. When you transform from a local system to WGS84, the shape might distort slightly, but its center should not jump 50 meters. This is what we should have been monitoring when our farm boundaries drifted. The transformation was valid. The geometry was valid. But the result was wrong.
Vertex density flags processing failures. A sudden spike in vertex count usually means you’ve created thousands of sliver artifacts in a union operation. A sudden drop means your simplification went too far or you’ve lost geometry parts. Either way, you want to know before the data moves downstream.
None of these checks are complex. The implementation is straightforward SQL. The hard part is building them into your pipeline rather than running them manually after something breaks.
Making it automatic
The goal is to move these checks into your orchestration logic. Whether you’re using Airflow, Dagster, or something custom, the system should flag suspicious features automatically.
In production, I run an audit after every major processing step:
WITH metrics AS (
SELECT
p.id,
ST_Area(p.geom) as processed_area,
ST_Area(i.geom) as input_area,
ST_Centroid(p.geom) as processed_centroid,
ST_Centroid(i.geom) as input_centroid
FROM processed_table p
JOIN input_table i ON p.id = i.id
WHERE
p.geom IS NOT NULL
AND i.geom IS NOT NULL
)
SELECT
id,
ABS(processed_area - input_area) / NULLIF(input_area, 0) as area_delta,
ST_Distance(processed_centroid, input_centroid) as centroid_shift
FROM metrics
WHERE
ABS(processed_area - input_area) / NULLIF(input_area, 0) > 0.05
OR ST_Distance(processed_centroid, input_centroid) > 10;
When this query returns rows, the pipeline doesn’t stop. But it triggers an alert with a targeted list of geometries to inspect. This is far more useful than discovering a problem weeks later when a client asks why their boundaries look wrong.
The thresholds depend on your use case. For agricultural parcels, a 5% area drift and 2-meter centroid shift are reasonable bounds. For cadastral data, you’d tighten them. For generalized map displays, you might loosen them. The point is to define what “acceptable change” means for your domain and enforce it automatically.
Why this matters more than you’d think
Validation catches bad inputs. Observability catches bad transformations. Both are necessary, but they solve different problems.
The most expensive part of a geospatial project is not the compute time or the storage. It’s rebuilding stakeholder trust after delivering a bad report. By the time a client notices a shifted boundary or discovers their area calculations are wrong, the damage is done. You’ve already sent multiple reports with corrupted data. You’ve already made decisions based on those numbers. Now you’re explaining why the system let it through.
Validation tells you if data is syntactically correct at ingestion. Observability tells you if your transformations are producing results that match reality. You need both.
The engineers who build the most resilient geospatial systems are not the ones who write the most sophisticated geometry algorithms. They’re the ones who assume transformations will drift and build systems that make that drift visible before it causes damage.
Once you start looking for drift inside the system, you begin to notice it elsewhere too. Not just in geometry, but in everything that stays healthy, correct, and quietly expensive while doing almost no work.
If you’ve worked with large spatial datasets, you know the feeling of finding a critical error weeks after it was introduced. It changes how you think about data quality. You stop treating transformations as deterministic operations and start treating them as processes that need monitoring.