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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
