[geos-devel] C API coordinate sequence dimensions

[Obe, Regina]

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