Validity¶

A valid geometry is essential for polygons since they define bounded areas and require a consistent structure. Lines and points, on the other hand, are simple contructs and cannot be invalid.

The following validity rules have been adopted by the OGC SFSQL standard, and as such are implemented by PostGIS:

• Polygon rings must close
• Rings that define holes should be inside rings that define exterior boundaries
• Rings must not self-intersect—they may neither touch nor cross one another
• Rings must not touch other rings except at a point

These rules are important because algorithms for geometry calculations depend on a consistent structure in the input geometries. Although it is possible to build algorithms that have no structural prerequisites, a structure-free approach often results in slow processing times since the first step is to analyze the inputs and impose a structure.

To illustrate why structure matters, the following output represents an invalid polygon.

POLYGON((0 0, 0 1, 2 1, 2 2, 1 2, 1 0, 0 0));

The reason it is invalid is highlighted in the following diagram:

Figure-eight polygon

Although the display routine appears to render the polygon as a single area, the outer ring is a figure-eight, with a self-intersection in the middle. This results in two one-unit squares and a total area that is the sum of the two squares.

Applying the ST_Area function confirms the polygon’s invalid status.

SELECT ST_Area(ST_GeometryFromText('POLYGON((0 0, 0 1, 1 1, 2 1, 2 2, 1 2, 1 1, 1 0, 0 0))'));

 st_area
---------
       0

The algorithm that calculates area assumes that rings do not self-intersect. A valid ring will always have the area that is bounded (the interior) on one side of the bounding line. It doesn’t matter which side, just as long as it is on one side.

However, in the figure-eight example the bounded area is to the right of the line for one square and to the left for the other. This results in the area calculated for each square being canceled out; one is reported as 1, the other as -1, so a total “zero area” is returned.

SELECT ST_IsValid(ST_GeometryFromText('POLYGON((0 0, 0 1, 1 1, 2 1, 2 2, 1 2, 1 1, 1 0, 0 0))'));

f

SELECT ST_IsValidReason(ST_GeometryFromText('POLYGON((0 0, 0 1, 1 1, 2 1, 2 2, 1 2, 1 1, 1 0, 0 0))'));

Self-intersection[1 1]

SELECT name, boroname, ST_IsValidReason(the_geom)
FROM nyc_neighborhoods
WHERE NOT ST_IsValid(the_geom);

          name           |   boroname    |                     st_isvalidreason
-------------------------+---------------+------------------------------------------------------
 Howard Beach            | Queens        | Self-intersection[597264.083368305 4499924.54228856]
 Corona                  | Queens        | Self-intersection[595483.058764138 4513817.95350787]
 Steinway                | Queens        | Self-intersection[593545.572199759 4514735.20870587]
 Red Hook                | Brooklyn      | Self-intersection[584306.820375986 4502360.51774956]

Repairing invalidity¶

Most common invalidities can be repaired using the ST_MakeValid(geometry) function. For example, running ST_MakeValid(geometry) on the figure-eight polygon:

SELECT ST_AsText(
         ST_MakeValid(
           ST_GeometryFromText(
             'POLYGON((0 0, 0 1, 1 1, 2 1, 2 2, 1 2, 1 1, 1 0, 0 0))'
           )
         )
       );

MULTIPOLYGON(((0 0,0 1,1 1,1 0,0 0)),((1 1,1 2,2 2,2 1,1 1)))

The repair routine correctly reformats the figure-eight as a multi-polygon with a polygon for each lobe of the figure-eight.

The function ST_MakeValid(geometry) is not a cleaning routine as such, but it is a very strict validity repairer. The following polygon is an ordinary square, but with one unit “hair” (a zero width corridor) extruding from it.

POLYGON((0 0, 0 1, 1 1, 1 2, 1 1, 1 0, 0 0))

However, the repair routine returns all the components of the input. It doesn’t delete geometry, just rearranges it into valid representations:

SELECT ST_AsText(ST_MakeValid('POLYGON((0 0, 0 1, 1 1, 1 2, 1 1, 1 0, 0 0))'));

                               st_astext
----------------------------------------------------------------------
GEOMETRYCOLLECTION(POLYGON((0 0,0 1,1 1,1 0,0 0)),LINESTRING(1 1,1 2))

The function ST_Buffer(geometry,radius) can also be used to clean invalid geometries by using a zero radius. For example:

SELECT ST_AsText(ST_Buffer('POLYGON((0 0, 0 1, 1 1, 1 2, 1 1, 1 0, 0 0))'::geometry, 0));

           st_astext
------------------------------
POLYGON((0 0,0 1,1 1,1 0,0 0))

Note

The buffer function is not guaranteed to repair all geometries and it does not work on as many input cases as the ST_MakeValid function.

The “banana polygon” (or “inverted shell”) is a single ring that encloses an area but bends around to touch itself, leaving a “hole” which is not actually a hole.

POLYGON((0 0, 2 0, 1 1, 2 2, 3 1, 2 0, 4 0, 4 4, 0 4, 0 0))

Running ST_MakeValid(geometry) on the polygon returns a valid OGC polygon, consisting of an outer and inner ring that touch at one point.

SELECT ST_AsText(
         ST_MakeValid(
           ST_GeometryFromText('POLYGON((0 0, 2 0, 1 1, 2 2, 3 1, 2 0, 4 0, 4 4, 0 4, 0 0))')
         )
       );

POLYGON((2 0,0 0,0 4,4 4,4 0,2 0),(2 0,3 1,2 2,1 1,2 0))

Note

The “banana polygon” is an example where the OGC topology model for valid geometry and the model adopted by Esri differ. The Esri model considers rings that touch to be invalid, and prefers the “banana” form for this type of shape. The OGC model is the reverse.