Geometry becomes invalid after a simple shift (black magic)

[tobiasreber]

Marcel Clausen and me found out, that one of our geometries became invalid after a simple shift (ST_Translate(the_geom, 2000000, 1000000)::geometry).

Here the valid geometry:

select st_isvalidreason(st_geometryfromtext('SRID=21781;MULTIPOLYGON(((669054 215766.1, 669054.8 215766.9, 669095.2 215807.2, 669064 215776.1, 669054 215766.1)))'));

Here the invalid geometry (after a simple shift):

select st_isvalidreason(st_geometryfromtext('SRID=2056;MULTIPOLYGON(((2669054 1215766.1, 2669054.8 1215766.9, 2669095.2 1215807.2, 2669064 1215776.1, 2669054 1215766.1)))'));

Can someone tell me why the geometry became invalid after the shift?

Here our installation: "POSTGIS="2.1.4 r12966" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.1, released 2013/08/26" LIBXML="2.9.1" LIBJSON="UNKNOWN" TOPOLOGY RASTER"

[robe]

Okay even in 2.4.0 becomes invalid:

select st_isvalidreason(ST_Translate(st_geometryfromtext('SRID=21781;MULTIPOLYGON(((669054 215766.1, 669054.8 215766.9, 669095.2 215807.2, 669064 215776.1, 669054 215766.1)))'),  2000000, 1000000)); 

outputs:

Self-intersection[2669054 1215766.1]

[pramsey]

Your "valid" polygon is very very very nearly invalid to start with (see the attached image). It almost has a couple self intersections. When you translate the geometry, you are not doing it in the real number space (contrary to your intuition) you're doing it within the grid of representable numbers provided by IEEE floating point representation. As a result, in addition to your large global shift, you'll see the relative position of the points will shift, very very slightly. Since your geometry is already just a hair away from being invalid, those small IEEE representation shifts are enough to flip if into an invalid state. You might want to just remove all "polygons" that have basically zero area before processing.

[komzpa]

We're even exploiting this fact to have more resolution for spatial computation, by shifting the geometry to the beginning of coordinate grid:

​https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Difference.sql#L18

In some edge-cases this helps to get a valid geometry when subtracting two very similar ones.

[dbaston]

As far as the "very very very nearly invalid" piece, a good way to quantify this is ST_MinimumClearance.

SELECT ST_MinimumClearance('MULTIPOLYGON(((669054 215766.1, 669054.8 215766.9, 669095.2 215807.2, 669064 215776.1, 669054 215766.1)))');
 st_minimumclearance 
---------------------
  4.115903174892e-11

So your input can tolerate only 4e-11 distance units of perturbation before becoming invalid.

[tobiasreber]

Thanks a lot for your promt and informative answers !!!

Besides: this geometry makes no sense in the real world - espescially when the geometry represents habitation zones ;-) GIGO or How to build a house on a hair.

BR Toby

[robe]

In 15490:

Back port all changes since Jan 2016.
References #3768 OSS Fuzz fixes
Correction of strk's email
formatting cleanup by strk
and adjustments to logic for readability by strk