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)
Change History (4)
by , 14 years ago
Attachment: | ST_IsValid_Tests.sql added |
---|
comment:1 by , 14 years ago
Cc: | added |
---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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)
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