[gdal-dev] Support for measures

[Ari Jolma]

The draft RFC is here

https://trac.osgeo.org/gdal/wiki/rfc61

Ari

27.01.2016, 15:52, Even Rouault kirjoitti:
> Le mercredi 27 janvier 2016 14:38:05, Ari Jolma a écrit :
>> 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.
> We should probably remove all its internal uses, and just have it used by
> OGR_G_SetCoordinateDimension(). And figure out what the behaviour should be
> when called on a XYM or XYZM geometry.
>
>> 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.
> Sounds reasonable.
>
>>> 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.
> I think that if possible we should try to minimize the number of attributes in
> the base OGRGeometry class so that sizeof(OGRPoint) remains small. Having the
> geometry type stored would capture both the Is3D and IsMeasure. And  int
> nCoordDimension could then potentially be removed, except that we have hacks
> currently in OGRPoint : -2 = point 2D empty and -3 = point 3D empty.
> Actually, I'm thinking we don't need that hack and that checking if isnan(x)
> && isnan(y) could be sufficient to model a POINT EMPTY (this is what we do in
> OGRPoint::importFromWkb() to support the GeoPackage / PostGIS 2.2 way of
> representing a POINT EMPTY) and avoid storing an explicit (and hacked)
> nCoordDimension.
>
>>> ... 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