[geos-devel] C API coordinate sequence dimensions

[Sean Gillies]

Thanks, Regina, that hints that the supporting GEOS C API functions  
might be considering z, but then again, the 3D might be implemented in  
the PostGIS lib.

On Jan 12, 2009, at 12:18 PM, Obe, Regina wrote:

> A lot of these are catalogued here
>
> http://postgis.refractions.net/documentation/manual-svn/ch08.html#id2671967
>
> and
>  ST_Union and I just discovered even ST_BuildArea.
>
> ST_ConvexHull (but that in my opinion gives goofy results).
>
>
> Though still debating how to describe that their results are  
> debateable.
>
> Also ST_BuildArea seems to hmm do a 2D and then tack on the Z so I  
> guess I should add that to the list.  Simon tested this out when he  
> was doing this write up and to my shock it sort of preserved 3D  
> though I would say incorrectly.  Any rate I don't think he has that  
> here, but still an interesting read
>
> http://www.spatialdbadvisor.com/postgis_tips_tricks
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: geos-devel-bounces at lists.osgeo.org on behalf of Sean Gillies
> Sent: Mon 1/12/2009 2:00 PM
> To: GEOS Development List
> Subject: Re: [geos-devel] C API coordinate sequence dimensions
>
> Ah, I didn't know this. Which ones?
>
> On Jan 12, 2009, at 11:40 AM, Paul Ramsey wrote:
>
> > Not all operations are 2D, just 99% of them. Some of the overlay ops
> > try to compute "correct" derived Z-values.
> >
> > P
> >
> > On Jan 12, 2009, at 10:04 AM, Sean Gillies wrote:
> >
> >> So, the dimension argument in GEOSCoordSeq_create is ignored unless
> >> the active sequence implementation takes dimensions other than 3?
> >>
> >> Why is GEOS's default sequence 3D when all operations are 2D?
> >>
> >> Sean
> >>
> >> On Jan 12, 2009, at 10:56 AM, Martin Davis wrote:
> >>
> >>> Actually JTS implements this correctly.  The return value from
> >>> getDimension is computed by the implementation of
> >>> CoordinateSequence.  In the case of DefaultCoordinateSequence
> >>> (which by the way is deprecated and replaced by
> >>> CoordinateArraySequence) the value is alway 3, since the
> >>> Coordinate representation used by these sequences always allows
> >>> for 3 ordinates.
> >>>
> >>> In the case of PackedCoordinateSequence the dimension can be
> >>> selected on creation, and this is the value that is returned by
> >>> getDimension.
> >>>
> >>> Sanak wrote:
> >>>> Hi list,
> >>>>
> >>>> I don't know that this is a known bug, but
> >>>> CoordinateArraySequence.getDimension() method always return 3.
> >>>>
> >>>> [trunk/source/headers/geos/geom/CoordinateArraySequence.h - line
> >>>> 88]
> >>>> size_t getDimension() const { return 3; }
> >>>>
> >>>>
> >>>> JTS(JTS Topology Suite) seems to be also the same.
> >>>>
> >>>> [jts/src/com/vividsolutions/jts/geom/
> >>>> DefaultCoordinateSequence.java - line 95]
> >>>> public int getDimension() { return 3; }
> >>>>
> >>>> I don't know that this is a specification or not...
> >>>>
> >>>> Regards,
> >>>>
> >>>> Sanak.
> >>>>
> >>>> 2009/1/12 Sean Gillies <sgillies at frii.com
> >>>> <mailto:sgillies at frii.com>>
> >>>>
> >>>>  I'm finding that GEOSCoordSeq_getDimensions returns 3 no matter
> >>>> what
> >>>>
> >>>>   # Accessing libgeos_c via Python ctypes
> >>>>   >>> s = lgeos.GEOSCoordSeq_create(2, 2)
> >>>>   >>> ndim = c_int()
> >>>>   >>> lgeos.GEOSCoordSeq_getDimensions(s, byref(ndim))
> >>>>   1
> >>>>   >>> ndim
> >>>>   c_long(3)
> >>>>
> >>>>  Is this a known bug? Looks like we're only testing creation of  
> 3D
> >>>>  coordinate sequences in
> >>>>
> >>>>  http://trac.osgeo.org/geos/browser/trunk/tests/unit/capi/GEOSCoordSeqTest.cpp
> >>>>
> >>>>  --
> >>>>  Sean Gillies
> >>>>  http://sgillies.net
> >>>>
> >>>>  _______________________________________________
> >>>>  geos-devel mailing list
> >>>>  geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>
> >>>>  http://lists.osgeo.org/mailman/listinfo/geos-devel
> >>>>
> >>>>
> >>>>  
> ------------------------------------------------------------------------
> >>>>
> >>>> _______________________________________________
> >>>> geos-devel mailing list
> >>>> geos-devel at lists.osgeo.org
> >>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
> >>>
> >>> --
> >>> Martin Davis
> >>> Senior Technical Architect
> >>> Refractions Research, Inc.
> >>> (250) 383-3022
> >>>
> >>> _______________________________________________
> >>> geos-devel mailing list
> >>> geos-devel at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/geos-devel
> >>
> >>
> >>
> >> --
> >> Sean Gillies
> >> sean.gillies at gmail.com
> >> http://sgillies.net
> >>
> >> _______________________________________________
> >> geos-devel mailing list
> >> geos-devel at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/geos-devel
> >
> >
> > --
> > Paul Ramsey
> > pramsey at cleverelephant.ca
> > +1 250 885 0632
> >
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/geos-devel
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
>
>
>
>
> The substance of this message, including any attachments, may be  
> confidential, legally privileged and/or exempt from disclosure  
> pursuant to Massachusetts law. It is intended solely for the  
> addressee. If you received this in error, please contact the sender  
> and delete the material from any computer.
>
>
>
> Help make the earth a greener place. If at all possible resist  
> printing this email and join us in saving paper.
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel