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.
Ari
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
