[geos-devel] Dimension of EMPTY geoms

hrz at geodata.soton.ac.uk hrz at geodata.soton.ac.uk
Mon Dec 4 09:03:49 EST 2006

On Mon, Dec 04, 2006 at 01:40:24PM +0000, hrz at geodata.soton.ac.uk wrote:
> On Mon, Dec 04, 2006 at 01:52:33PM +0100, strk at refractions.net wrote:
> > See bug http://postgis.refractions.net/bugs/bug.php?op=show&bugid=135&pos=5
> For the context, these questions came up whilst developing a Python
> interface to GEOS.
> > Questions are:
> > 
> > 1) Should EMPTY geometries of *any* kind return 0 from getDimension() ?
> Nothing serious; I just expected empty geometries to be
> dimensionless! At least there should be some consistency between
> GEOMETRYCOLLECTIONs and typed geometries?
> > 2) Should CAPI's GEOSCoordSeq_create() raise an error if requested
> >    to create anything but a 3d geom ? (the only one supported)
> I suppose the root of this question was that I expected geometries
> (and CoordSequences) with only x and y coordinates to have a dimension
> of 2. If I obtain the CoordSequence from a geometry where hasZ() returns
> false, it has a dimension of 3 and (on my machine) the 3rd ordinate (z
> value) has a value of 1.7e-308. I know that this is an inordinately
> small value (excuse the pun!), but it is a value
> nonetheless. Currently, because I can't check the dimensions as to
> whether or not I should return this value, users end up with a z value
> that wasn't initially specified when iterating over CoordSequences.
> Some searching led me to the post at
> <http://lists.refractions.net/pipermail/geos-devel/2003-August/000515.html>
> and the fact that GEOS treats 1.7e-308 as NaN. Being able to check for
> this from the CAPI (perhaps exposing the ISNAN macro in
> source/headers/geos/platform.h) would enable me to work around the
> dimensions issue.

Another alternative might be to provide something along the lines of:

extern char GEOS_DLL GEOSCoordSeq_hasZ(const GEOSCoordSequence* s);


More information about the geos-devel mailing list