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