Opened 14 years ago

Closed 14 years ago

#652 closed defect (invalid)

ST_IsValid and adjacent polygons

Reported by: gaosgeo Owned by: pramsey
Priority: medium Milestone: PostGIS 1.5.3
Component: postgis Version: 1.5.X
Keywords: ST_IsValid, Self-Intersections Cc: gaosgeo

Description

Hi,

It seems that ST_IsValid (and thus ST_IsValidReason) throws errors inconsequently. See following examples (both 2D and 3D):

A) 2D: These two polygons are adjacent in (0 1) and (1 1)

SELECT ST_isvalidreason(ST_GeomFromEWKT('MULTIPOLYGON( ((0 0, 1 0, 1 1, 0 1, 0 0)), ((0 1, 1 1, 1 2, 0 2, 0 1)))'));

=⇒ Self-intersection[0 1]

Shifting one vertex to (0 0.9), no other error is thrown. What about Self-Intersection in (1 1) then?.

SELECT ST_IsValidReason(ST_GeomFromEWKT('MULTIPOLYGON( ((0 0, 1 0, 1 1, 0 0.9, 0 0)), ((0 1, 1 1, 1 2, 0 2, 0 1)))'));

=⇒ Valid Geometry

B) 3D: Same errors with same polygons, but lying at different z-values.

SELECT ST_isvalidreason(ST_Geometryfromtext('MULTIPOLYGON( ((0 0 0, 1 0 0, 1 1 0, 0 1 0, 0 0 0)), ((0 1 1, 1 1 1, 1 2 1, 0 2 1, 0 1 1)))'));

=⇒ Self-intersection[0 1 0.5]

Any hints?

I'm using:

  • POSTGIS="1.5.2" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.6.1, 21 August 2008" LIBXML="2.7.6" USE_STATS
  • PostgreSQL 8.4.4, compiled by Visual C++ build 1400, 32-bit on Windows 7 64-bit

I attach a short file with the given examples. Thank you and best Regards,

ga

Attachments (1)

ST_IsValid_Tests.sql (1.1 KB ) - added by gaosgeo 14 years ago.

Download all attachments as: .zip

Change History (4)

by gaosgeo, 14 years ago

Attachment: ST_IsValid_Tests.sql added

comment:1 by gaosgeo, 14 years ago

Cc: gaosgeo added

comment:2 by kneufeld, 14 years ago

What you are seeing is actually expected results.

According to the OGC specifications, a multipolygon is considered valid if all its elements are valid and the interiors of no two elements intersect. Additionally, the boundaries of any two elements *may* touch, but only at a finite number of points (ie. a line). Granted, the ST_IsValidReason could have been more clear by indicating a self-intersection along the LINESTRING(0 1, 1 1), instead of only presenting a point along that line.

http://postgis.refractions.net/docs/ch04.html#OGC_Validity or refer to the actual SFSS. (I should probably add a new diagram (p) showing a valid mpg that touches at a point)

As for your second example, ST_Valid does not take the 3rd (or 4th) dimension into account. For the most part, calculations in PostGIS are done in 2D. Some functions will recognize the 3rd dimension, like ST_Length3D, others may extrapolate the value, but most will not use it, including indexes. PostGIS should really be thought of as 2.5D where the 3rd/4th dimensions are really place holders for extra values. See the support matrix: http://postgis.refractions.net/docs/ch08.html#PostGIS_TypeFunctionMatrix

comment:3 by strk, 14 years ago

Resolution: invalid
Status: newclosed

I confirm it is expected behavior.

The validity report always reports a single point. Anyrate the report comes from GEOS so if you want to suggest improvements in it such improvement should be suggested on the GEOS trac (or even better, JTS, where it all comes from)

Note: See TracTickets for help on using tickets.