On Mon, Dec 04, 2006 at 01:40:24PM +0000, [EMAIL PROTECTED] wrote: > > On Mon, Dec 04, 2006 at 01:52:33PM +0100, [EMAIL PROTECTED] 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); Homme _______________________________________________ geos-devel mailing list geos-devel@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
