[gdal-dev] Support for measures

[Ari Jolma]

27.01.2016, 18:26, Even Rouault kirjoitti:
> Le mercredi 27 janvier 2016 16:48:45, Ari Jolma a écrit :
>> The draft RFC is here
>>
>> https://trac.osgeo.org/gdal/wiki/rfc61

Changed to 
https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries

> My remarks:
>
> 1) #define OGR_G_xxxx
>
> --> should that be rather (since the intent seems to be bitwise combination):
> #define OGR_G_NOT_EMPTY 	0x1
> #define OGR_G_3D 			0x2
> #define OGR_G_MEASURED 	0x4
>
> and I'd say put it ogr_geometry.h only as it is an internal implementation
> detail.
>
> 2) new OGRGeometry methods. I think Kurt would prefer using straight C++ bool
> type, but it is true we have used OGRBoolean for all other methods. So no
> strong opinion on this.
>
> 3) "New OGRwkbGeometryType values are needed". I assume you will use the SFSQL
> 1.2 and ISO SQL/MM Part 3 way, ie. 2D type + 2000 for M and  2D type + 3000
> for ZM ? I'm also wondering if, as a provision, we shouldn't also add the Tin
> and PolyhedralSurface types for completness, even if unimplemented at that
> point. At least people would be warned that such beasts may appear at some
> point.
>
> 4) In the compatibility issues, we'd have to wonder if we need to make
> something special when a driver ICreateLayer() is called with a XYM/XYZM type
> and it is not ready for it. And same for ICreateFeature()/ISetFeature(). For
> curve geometries, I decided that curve aware drivers would expose a
> OLCCurveGeometries / ODsCCurveGeometries capability and that
> CreateLayer()/CreateFeature()/SetFeature() generic methods would convert types
> if needed before passing to the Ixxxx implementation method. Such technique
> could be reused here potentially.

These are now taken into account in the draft.

BTW, where can I find a comprehensive list of the wkb types? There is an 
old ISO SQL/MM Part 3 pdf in the web but it is old and seems to be 
incorrect too. libspatialite has a header file that has many but not all 
that ogr_core.h has.

Ari

>
>> 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