Geometry Boost List: [ggl] is_simple is_valid

Subject: [ggl] is_simple is_valid
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-10-05 04:49:47

Hi Mateusz,

Mateusz Loskot wrote:
> Barend Gehrels wrote:
>   
>> Hi,
>>
>> I'm looking at self-intersections to implement the function is_simple
>> (based on blocks we already have). But I'm what confused about the name.
>>
>> According to OGC:  IsSimple  (): Integer Returns 1 (TRUE) if this
>> geometric object has no anomalous geometric points, such as self
>> intersection or self tangency. The description of each instantiable
>> geometric class will include the specific conditions that cause an
>> instance of that class to be classified  as not simple.
>>
>> JTS says: Valid polygonal geometries are simple by definition, so
>> isSimple trivially returns true. 
>> (http://www.vividsolutions.com/JTS/javadoc/com/vividsolutions/jts/geom/Geometry.html#isSimple())
>>     
>
> Yes, but the result is not well defined for invalid geometries, so
> isSimple may result true for non-simple && invalid geometry.
>
> Here is two points exaplnation provided by Martin - JTS guru
> (http://postgis.refractions.net/pipermail/postgis-users/2004-April/004507.html):
>   
Thanks for the link. Martin explains: /"It states that Polygons are 
always simple geometries (sec. 2.1.10)."/ and indeed I now find the 
statement /polygons are simple geometric objects/. Seems to me 
contratictory, but OK.

However, is_valid is NOT an OGC method as far as I can see in the older 
and newer specs.

> "You should ensure all your geometries are valid before using analytic
> functions"
>
> The implication is:
>
> if (is_valid(geometry) && is_simple(geometry))
> {
>    ... assumed simple
> }
>
>   
>> The PostGIS implementation give TRUE back to all self-intersecting
>> polygons that I try.
>>     
>
> Can you give WKT of simple example of such polygon?
>   
select IsSimple(GeomFromText('POLYGON((1 2,1 1,2 1,2 2.25,3 2.25,3 0,0 
0,0 3,3 3,2.75 2,1 2))')) -> true
select IsSimple(GeomFromText('LINESTRING(1 2,1 1,2 1,2 2.25,3 2.25,3 0,0 
0,0 3,3 3,2.75 2,1 2)')) -> false
select IsValid(GeomFromText('POLYGON((1 2,1 1,2 1,2 2.25,3 2.25,3 0,0 
0,0 3,3 3,2.75 2,1 2))')) -> false
select IsValid(GeomFromText('LINESTRING(1 2,1 1,2 1,2 2.25,3 2.25,3 0,0 
0,0 3,3 3,2.75 2,1 2)')) -> true

This behaviour sounds completely illogical to me:
*- a self-intersecting linestring is valid but not simple
- a self-intersecting polygon is simple but not valid
*
Anyway, this is probably not the right platform to discuss that. The OGC 
spec indeed states that a simple linestring may not self-intersect... 
There will probably a reason for it.

But the message here is: do we want that GGL follows this behaviour?

We could make only one function: is_valid, which returns as above, so 
always true for linestrings (because there is no harm if they 
self-intersect) and false for self-intersecting polygons.

Or maybe better, but less conformant: intersects(geometry) -> true for 
both linestring and polygon. This is an OGC method but specified for two 
geometries (intersects(a,b)) but we of course might make an overload for 
one, meaning self-intersecting, and one for a container of geometries, 
meaning that at least one pair of the container intersects.

Actually this is much better because is_valid has also other purposes 
(e.g. nonclosed polygons)
> For example, not closed polygon is invalid.
>   
Actually those are not accepted by SQLServer and postgis, so the 
function isvalid cannot be called... So exception for both...

> What version of PostGIS do you use?
>   
"PostgreSQL 8.3.6, compiled by Visual C++ build 1400"

>   
>> The function isvalid returns false for self-intersecting polygons.
>>     
>
> Have you compared your geometries with simple vs valid explained here?
>
> http://postgis.org/documentation/manual-1.4/ch04.html#OGC_Validity
>   
No, thanks for the link. It indeed reasons the same. So the behaviour is 
conform the documentation.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091005/65c0f278/attachment.html