[gdal-dev] Proposed change regarding wkbCurve, wkbSurface and their M/Z/ZM variants

[Even Rouault]

Hi,

During https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries 
discussion, we introduced wkbCurveM/Z/ZM and wkbSurfaceM/Z/ZM as #define and 
not in OGRwkbGeometryType enumeration. This was to be consistent with how 
wkbCurve and wkbSurface were themselves introduced in GDAL 2.0 together with 
https://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries (actually those 2 
#define were implementation details not advertized in RFC 49 itself). The 
rationale for keeping them out of the enumeration was that those types were 
abstract.

But when revisiting a bit the GeoPackage driver, I see that the GeoPackage 
spec can advertize layers of type Curve or Surface, so it would be more 
convenient/clean to have them as regular values in the OGRwkbGeometryType 
enumeration so they can been more easily dealt with by OGRFromOGCGeomType(), 
OGRToOGCGeomType(), etc...  I'm not aware of other drivers that would make use 
of such types, but at least ogr2ogr scenarios would be lossless on such GPKG 
files.

The argument of abstract vs concrete types is a bit weak, since 
OGRwkbGeometryType has already values such as wkbNone or wkbUnknown.

And as RFC 61 has added a number of new constants for M and ZM support, adding 
those related to wkbCurveXXX and wkbSurfaceXXXX shouldn't hurt much, as user 
code will have to be upgraded anyway.

I've created https://trac.osgeo.org/gdal/ticket/6401 with the proposed (quite 
straightforward) patch implementing the change. Let me know if you see issues 
with that.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com