[gdal-dev] Support for measures

[Ari Jolma]

27.01.2016, 15:23, Even Rouault kirjoitti:
> Le mercredi 27 janvier 2016 14:01:42, Ari Jolma a écrit :
>> 27.01.2016, 14:34, Ari Jolma kirjoitti:
>>> 27.01.2016, 13:27, Even Rouault kirjoitti:
>>>> Le mercredi 27 janvier 2016 11:55:01, Ari Jolma a écrit :
>>>>> Folks,
>>>>>
>>>>> I'd like to try to implement the XYZM support since I have some free
>>>>> time.
>>>>>
>>>>> Before making a RFC, there are some thoughts/questions/ideas:
>>>>>
>>>>> * I made a fork for this work at https://github.com/ajolma/GDAL-XYZM so
>>>>> I can more easily use travis.
>>>>>
>>>>> * I think this is mainly changes in the geometry API and generic
>>>>> methods.
>>>>>
>>>>> Are there other drivers than shape, which are affected?
>>>> On top of my head: PostGIS, FileGDB, OpenFileGDB, GeoPackage,
>>>> Spatialite.
>>>> Probably other RDMBs too (Oracle, MSSQL, ... ?)
>>> I'm not so sure that it is so many. For example PostGIS driver is
>>> mostly moving WKB back and forth.
>> Well, it seems that they are affected. There is for example the
>> setCoordinateDimension() method, which is called by many drivers and
>> once measures are supported it becomes ambiguous since coordinate
>> dimension is 3 for both XYM and XYZ.
> I think we should perhaps keep setCoordinateDimension() with the current
> semantics for legacy reasons but not accept using 3 for XYM or extending it to
> 4 for XYZM

That's my thinking too. The semantics of the old API should be kept the 
same. I'm thinking that there should perhaps be a new method 
CoordinateDimension(), which would return the same as ST_NDims of 
PostGIS. Actually the name of the method is CoordinateDimension() 
(without get prefix) in simple feature access documents.

>
> The OGRGeometry class could have for example a setCoordinateInterpretation()
> with an enum XY, XYZ, XYM and XYZM. And a similar member variable to store it.

set3D(boolean is3D) and setMeasured(boolean isMeasured)? As each 
geometry could have boolean Is3D and IsMeasured properties, and the docs 
have Is3D and IsMeasured methods.

>
> ... or, as currently getGeometryType() dynamically builds the geometry type,
> perhaps have instead a wkbGeometryType member in OGRGeometry itself.
>
> And have a setGeometryType() to modify it, with restrictions on which kind of
> geometry type changes are allowed. You can't  do
> point.SetGeometryType(wkbLineString) )
>
> Actually instead of setGeometryType() , the way QGIS has done with its
> QgsAbstractGeometryV2 class, ie with explicit addZValues( double zInitValue ),
> addZValues( double zInitValue ), dropZValues(), dropMValues() could be a good
> inspiration.

I'll go through the API and prepare and post a proposal to discuss more.

Ari

>
>> Ari
>>
>>> Anyway, I'll look into the geometry API first.
>>>
>>> Ari