3D operations (Re: [geos-devel] C API coordinate sequence dimensions)

Obe, Regina robe.dnd at cityofboston.gov
Tue Jan 13 13:17:26 EST 2009 

I think there has been discussion of documenting GEOS.  At least C++-Doc (J Doc kind of autogenerate thingy to start with).

Yes Smurfs are good.  I'm greatful for all their work just like I'm very thankful when my old pet cat leaves a dead rat head beside his bowl.  It is a little unexpected but nevertheless appreciated. It is just in need of a little polishing :).



-----Original Message-----
From: geos-devel-bounces at lists.osgeo.org on behalf of Sean Gillies
Sent: Tue 1/13/2009 1:08 PM
To: GEOS Development List
Subject: 3D operations (Re: [geos-devel] C API coordinate sequence dimensions)
 
"Smurf code"? Smurfs are good, if I remember my Saturday morning  
cartoons :)

It would probably take me much longer to grep and read through the  
code base to find which functions are 3D and document them in the wiki  
than it would take the authors ... can I do anything to entice them to  
document the 3D functions?

Sean

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

> I looked at the GEOS code a while back and compared to JTS and
> was shocked that I saw GEOS z (as I call it smurf code and did not see
> this smurf code in JTS).
>
> This was when I was testing the PostGIS functions for 3D support  
> assuming all GEOS functions should be 2D and to my shock they seemed  
> to do something with Z.
>
> I'm pretty sure at the very least that ST_ConvexHull, ST_Union Z  
> support
> is coming straight from GEOS.  Haven't verified ST_Difference.
>
>
> -----Original Message-----
> From: geos-devel-bounces at lists.osgeo.org on behalf of Sean Gillies
> Sent: Mon 1/12/2009 2:37 PM
> To: GEOS Development List
> Subject: Re: [geos-devel] C API coordinate sequence dimensions
>
> 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
>
> _______________________________________________
> 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

_______________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20090113/48ffb23f/attachment-0001.html

More information about the geos-devel mailing list