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

[Kurt Schwehr]

+1

On Sun, Mar 6, 2016 at 7:17 AM, Even Rouault <even.rouault at spatialys.com>
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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160306/ac399df3/attachment.html>