[geos-devel] C API coordinate sequence dimensions

Paul Ramsey pramsey at cleverelephant.ca
Mon Jan 12 13:40:09 EST 2009


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



More information about the geos-devel mailing list