<div dir="ltr">+1</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 7:17 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
During <a href="https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries</a><br>
discussion, we introduced wkbCurveM/Z/ZM and wkbSurfaceM/Z/ZM as #define and<br>
not in OGRwkbGeometryType enumeration. This was to be consistent with how<br>
wkbCurve and wkbSurface were themselves introduced in GDAL 2.0 together with<br>
<a href="https://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries</a> (actually those 2<br>
#define were implementation details not advertized in RFC 49 itself). The<br>
rationale for keeping them out of the enumeration was that those types were<br>
abstract.<br>
<br>
But when revisiting a bit the GeoPackage driver, I see that the GeoPackage<br>
spec can advertize layers of type Curve or Surface, so it would be more<br>
convenient/clean to have them as regular values in the OGRwkbGeometryType<br>
enumeration so they can been more easily dealt with by OGRFromOGCGeomType(),<br>
OGRToOGCGeomType(), etc...  I'm not aware of other drivers that would make use<br>
of such types, but at least ogr2ogr scenarios would be lossless on such GPKG<br>
files.<br>
<br>
The argument of abstract vs concrete types is a bit weak, since<br>
OGRwkbGeometryType has already values such as wkbNone or wkbUnknown.<br>
<br>
And as RFC 61 has added a number of new constants for M and ZM support, adding<br>
those related to wkbCurveXXX and wkbSurfaceXXXX shouldn't hurt much, as user<br>
code will have to be upgraded anyway.<br>
<br>
I've created <a href="https://trac.osgeo.org/gdal/ticket/6401" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/6401</a> with the proposed (quite<br>
straightforward) patch implementing the change. Let me know if you see issues<br>
with that.<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>