Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#3768 closed defect (wontfix)

Geometry becomes invalid after a simple shift (black magic)

Reported by: tobiasreber Owned by: pramsey
Priority: medium Milestone: PostGIS 2.0.8
Component: postgis Version: 2.1.x
Keywords: invalid Geometry Cc:

Description

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"

Attachments (1)

screenshot_122.png (10.9 KB ) - added by pramsey 7 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 by robe, 7 years ago

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]

by pramsey, 7 years ago

Attachment: screenshot_122.png added

comment:2 by pramsey, 7 years ago

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.

comment:3 by pramsey, 7 years ago

Resolution: wontfix
Status: newclosed

comment:4 by komzpa, 7 years ago

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.

comment:5 by dbaston, 7 years ago

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.

comment:6 by tobiasreber, 7 years ago

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

comment:7 by robe, 7 years ago

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

Note: See TracTickets for help on using tickets.