[geos-devel] Is empty LinearRing closed?

[Martin Davis]

> In my opinion this test is necessary to be checked 
> explicitly. LinearRing is of type of LineString, so it is 
> possible to pass LinearRing where LineString is expected, and 
> the other way. So, checking "static state" of those two types 
> may result in wrong asnwer.

No, the point is that if the LinearRing is valid, isClosed always returns the correct answer.  It doesn't matter where this method is evaluated.

> The IsEmpty function checks emptiness of geometry and returns 
> TRUE if the geometry is empty or FALSE if the geometry is not empty.

This *IS* the way it is implemented in JTS/GEOS.

> So, I understand this behaviour as very dynamic. LineString X 
> can become a LinearRing and vice versa.

Well, a LineString can't just change type into a LinearRing.  But if you're saying that a LineString might be closed, yes I agree and JTS/GEOS will return the right answer in this case (for a LineString, isClosed checks the endpoints are equal).

Anyway, this isn't a big deal IMHO - I'd be perfectly happy changing the LinearRing method so it just uses the LIneString implementation.


Martin Davis, Senior Technical Architect
Vivid Solutions Inc.      www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046


> -----Original Message-----
> From: geos-devel-bounces at geos.refractions.net 
> [mailto:geos-devel-bounces at geos.refractions.net] On Behalf Of 
> Mateusz Loskot
> Sent: March 30, 2006 2:35 PM
> To: GEOS Development List
> Subject: Re: [geos-devel] Is empty LinearRing closed?
> 
> 
> Martin Davis wrote:
> > But the definition of LinearRing is that the start point equals the 
> > end point.   This makes the test unnecessary for a valid LinearRing.
> >  However, maybe it's more general to use the explicit test.
> 
> In my opinion this test is necessary to be checked 
> explicitly. LinearRing is of type of LineString, so it is 
> possible to pass LinearRing where LineString is expected, and 
> the other way. So, checking "static state" of those two types 
> may result in wrong asnwer.
> 
> Empty LineString in OGR is created explicitly as empty set of 
> points + collection (array) of points is UNDEFINED:
> 
> /**
>  * Create an empty line string.
>  */
> OGRLineString::OGRLineString()
> {
>     nPointCount = 0;
>     paoPoints = NULL;
>     padfZ = NULL;
> }
> 
> > As for an empty LinearRing, well, I don't know of any 
> semantics which  
> > covers this.
> 
> I think its simple to understand but quit difficult to 
> implement this semantic properly. Here is my understanding of 
> the emptiness (according to MySQL, ArcSDE impl. and OGC 
> Simple Feature Spec.):
> 
> 1. Empty geometries contain no coordinates. IOW, geometry is 
> empty if it does not have any coordinates.
> 
> 2. Following properties of empty geometry are not defined as 
> well: exterior, interior, and boundary. According to ArcSDE, 
> an empty geometry has a NULL envelope, boundary, interior, 
> and exterior.
> 
> 3. Empty geometry is always simple.
> 
> 4. I like the idea of MySQL Spatial Ext. that empty geometry 
> has dimension set to -1 (undefined).
> 
> 5. Empty surface geometry has area equal to 0, empty curves( 
> linestrings and multilinestrings) have a 0 length.
> 
> NOW THE MOST IMPORTANT:
> The IsEmpty function checks emptiness of geometry and returns 
> TRUE if the geometry is empty or FALSE if the geometry is not empty.
> 
> That clearly means it's *incorrect* to set that some type 
> *always* returns true or false. This behaviour is dynamic, 
> depending on current state of geometry (if it contains empty 
> set of points or not).
> 
> Please, not that some of types of OGC Geometries has a 
> logical meaning and they are not required to be represented 
> as accurate instance of such type.
> 
> I mean, ArcSDE does not use LinearRing at all, but only 
> LineString type
> (exteriorRing() returns instance of LineString but not 
> LinearRing). Second, the LineString becomes LinearRing as OGC 
> Simple Feaure Spec. says:
> 
> "A LinearRing is a LineString that is both closed and simple."
> 
> So, I understand this behaviour as very dynamic. LineString X 
> can become a LinearRing and vice versa.
> 
> 
> > This might be an angels-on-the-head-of-a-pin kind of thing.  If you
> > don't like the JTS semantics for your particular use-case, 
> you should
> >  just implement your own test.
> 
> The semantic is clearly explained in OGC Spec. but it's 
> implemented incorrectly.
> 
> Cheers
> -- 
> Mateusz Łoskot
> http://mateusz.loskot.net 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net 
> http://geos.refractions.net/mailman/listinfo/geos-devel
>