Le jeudi 28 janvier 2016 09:23:47, Ari Jolma a écrit : > 28.01.2016, 00:05, Even Rouault kirjoitti: > > Thanks for the pointer to the geometry codes in SF Common Architecture, > somehow I overlooked it. > > > my point with adding the new capabilities was that drivers that > > wouldn't advertize the M capabilities would never see a M or ZM > > geometry / geometry type passed. See what the (non-virtual) methods > > OGRLayer::SetFeature(),CreateFeature() and GDALDataset::CreateLayer() > > do for curve geometries. Similar things could be done for M. > > Hm. For example shape driver raises an error if the geometry type is not > supported. I don't know what scenario would lead to that. > > Assume that the user has data in GDAL with measures. She decides to save > that using a driver, which does not support measures. The impact is that > the measures are stripped out, which is ok if the data is discarded > immediately after that but not if she wants to still do something with > the measures. I'm not sure if documenting the side-effect is enough. > However, the convert to non linear geometries is already there and this > would follow that pattern. I guess this is a part of the bigger > discussion whether we consider GDAL as a data storage for interactive > tools for example or as a data processing library.
I agree with you that it can discussed where the choice to convert data with loss must be done. I don't think this was raised during RFC 49 discussion. In the case of curve->geometry conversion, someone who cares about potential loss can query the driver capabilities : if they don't advertize curve support, then he knows that lossy conversion will occur. > > Ari -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
