[gdal-dev] Support for measures

[Even Rouault]

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