+1 On Sun, Mar 6, 2016 at 7:17 AM, Even Rouault <[email protected]> wrote:
> 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 -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
