[geos-devel]createEmptyGeometry()
Martin Davis
mbdavis at VividSolutions.com
Thu Mar 30 18:08:30 EST 2006
I thought about this, but on the principal of Occam's Razor decided just to use an empty GC. This has the advantage that there are fewer cases to handle for both developers and clients.
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 Charlie Savage
Sent: March 30, 2006 2:33 PM
To: GEOS Development List
Subject: Re: [geos-devel]createEmptyGeometry() createsinstance ofGeometryCollection
Would it make sense to have a separate EmptyGeometryClass specifically for this purpose?
Charlie
Martin Davis wrote:
This isn't a question of what Geometry.isEmpty() returns. In fact, isEmpty behaves exactly the way you mention - it checks whether there are any points in the Geometry, and returns false if not.
The issue is: what should a method return when it needs to return an empty geometry, but there is no guide about what type of geometry to return? For instance, if you run line.intersect(polygon), and they don't actually intersect, what should be returned? JTS adopts the convention that an empty GeometryCollection is returned. Otherwise, it would have to choose a particular type to return, and this might be misleading.
Actually reviewing this has exposed a minor but probably bad design decision in JTS: empty buffers currently return an empty GC, whereas they should return an empty Polygon (to maintain the exit condition that buffer always returns a polygonal object).
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:05 PM
To: GEOS Development List
Subject: Re: [geos-devel] createEmptyGeometry()
createsinstance ofGeometryCollection
Martin Davis wrote:
Yes. The spec doesn't cover this, but I chose to use an empty
GeometryCollection as a "typeless" empty geometry, for
methods which
need to return one. The createEmptyGeometry method is just a
convenience method for this convention.
OK, I understant it.
Anyway, what else could that method return that would make sense
(given that it has no type information)?
It depends on the idea behind "empty geometry" or "null
geometry" [1]. As I know, OGC Simple Feature Spec. explains
that empty geometry represents empty point set (empty set of
coordinates). According to my understanding: Point is empty
if it contains "uninitialized" coordinates MultiPoint is
empty if it contains no points in its set. etc.
There is also a distinction between empty and null.
NULL means something undefined, uninitialized - something
unsafe. EMPTY means something well constructor but with empty
set of points. In some case, NULL object can be compared to
EMPTY object with true result.
So, I think isEmpty() function should check the state of the
coordinates set of Geometry return appropriate value (true/false).
[1] Saying "null geometry" I think about logical meaning but
not the physical representation of instance of geometry: null
reference/null pointer.
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
_______________________________________________
geos-devel mailing list
geos-devel at geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20060330/ee4365a8/attachment.html
More information about the geos-devel
mailing list