Geometry Validator

How the Geometry Validator works, and what it assumes

A geometry is valid when it obeys the OGC Simple Features rules that PostGIS enforces: polygon rings are closed and do not cross themselves or each other, holes lie inside their shell without cutting its interior into pieces, holes touch the shell only at single points, the polygons of a MultiPolygon do not overlap, and every line and ring has enough distinct positions. The check is JSTS's IsValidOp, the counterpart of the GEOS routine behind ST_IsValid.

Each invalid geometry is reported the way ST_IsValidReason reports it, such as Self-intersection[8 2], with the location marked by a cross on the plot and a plain explanation of what the error means and how to fix it. Like ST_IsValidReason, the check stops at the first problem in each geometry; a FeatureCollection is checked feature by feature, so one bad feature among thousands is easy to find.

Some things are legal but worth knowing, and are reported as notes rather than errors: a line that crosses itself (valid, but not simple), positions repeated one after another, and polygon rings wound against the RFC 7946 convention. GeoJSON that breaks the format's own structural rules is reported with the path to each problem. Nothing is repaired automatically, because a repair decides what the shape should have been; PostGIS's ST_MakeValid is the tool for that once you know what is wrong.

Where this comes up in GIS work

• Finding out why PostGIS raised a TopologyException, or why an overlay or area calculation failed.
• Checking digitised or imported boundaries before loading them into a spatial database.
• Locating the one bad feature in a large FeatureCollection.
• Spotting lines that cross themselves before using them in routing.

A worked example

The example FeatureCollection holds three plots, two of them broken:

features[0].geometry (Plot 1): Valid Geometry
features[1].geometry (Plot 2 (bow-tie)): Self-intersection[8 2]
features[2].geometry (Plot 3 (hole outside)): Hole lies outside shell[5 7]

The second plot's outline crosses itself at (8, 2), and the third has a hole drawn beside the polygon rather than inside it. Other errors read the same way: a hole inside another hole gives Holes are nested, a MultiPolygon whose parts overlap gives Self-intersection at the first crossing, and a ring pinched at one vertex gives Ring Self-intersection. A hole that touches its shell at a single vertex is valid.

Using the Geometry Validator

1. Paste WKT, EWKT or GeoJSON, open a file, or select Load example. A FeatureCollection is checked feature by feature.
2. Select Validate geometry, or press Ctrl + Enter (Cmd + Enter on a Mac).
3. Read the verdict, then the problems listed for each invalid geometry.
4. Find each problem on the plot, where its location is marked with a cross.
5. Copy or download the text report, which lists every geometry with its ST_IsValidReason.

When the output looks wrong

Self-intersection with a location

Two edges of the polygon cross at that location, usually because two vertices are in the wrong order and the outline folds over itself like a bow-tie. Reorder them, or split the shape into two polygons. In PostGIS, ST_MakeValid performs that split for you.

Hole lies outside shell

An inner ring is not inside the outer ring of its polygon. Often the hole belongs to a different polygon, or it is really a separate island that should be its own polygon in a MultiPolygon.

The GeoJSON structure is invalid

The file breaks a structural rule of RFC 7946, such as a ring that is not closed or a position with a missing value, so its geometry cannot be built at all. Each structural error is listed with its path; the GeoJSON Formatter gives the same checks with formatting.

The geometry is valid but the line crosses itself

A self-crossing line is valid, just not simple. It is reported as a warning because it breaks routing and length-based analysis even though ST_IsValid is true.

Questions about the Geometry Validator