[gdal-dev] RFC 61: Call for vote on adoption

[Even Rouault]

Le lundi 08 février 2016 08:17:28, vous avez écrit :
> 06.02.2016, 18:00, Sean Gillies kirjoitti:
> > Can you explain more in detail about the backwards incompatibilities
> > and how to soften them? What's going to break and what are the
> > specific options?
> 
> Hi Sean,
> 
> In the C++ and C API there are no backwards incompatibilities but the
> get/setCoordinateDimension() methods become deprecated since XYM and XYZ
> have the same dimension.  Is3D(), IsMeasured(), set3D(), and
> setMeasured() should be used instead.
> 
> I don't know about the other drivers but Shapefile driver currently
> reads XYM geometries as XYZ and that will be changed so that XYM are
> read as XYM. I think that is the only incompatibility. A new open option
> MEASURE_AS_Z=YES/NO (or something) can be defined for backwards
> compatibility. 

I don't think there's a strong need for such an option without confirmation 
from users. The XYM support as XYZ was really a hack (people had no way to 
know if the XYZ was XYM or XYZ, unless they read the .shp/.shx themselves). 
And it is not clear how that would work in update scenarios (currently the M/Z 
is discarded on update :  https://trac.osgeo.org/gdal/ticket/6331 )

Pirmin: as I see from https://trac.osgeo.org/gdal/ticket/2374 you were the one 
to contribute the patch, what is your opinion on this ?

> Similar option can be defined for other drivers if they
> have the same feature.

I believe all other drivers currently discard the M values

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