<div dir="ltr"><div><div><div>Ari, Even,<br><br></div> one potential solution where M data are present but not supported by the Geometry type would be to add M as a user defined attribute, as is done for Z values in some drivers / packages. This preserves both the geometry integrity and the data. Should the user wish to 'upgrade' the dataset to a full xyzm structure at some future date, this is then their explicit decision and can take proper account of format capabilities, etc. <br><br> There may need to be a debate about what the replacement M attribute be called, of course!<br><br></div>Best wishes,<br><br></div>Peter<br><br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 January 2016 at 08:23, Ari Jolma <span dir="ltr"><<a href="mailto:ari.jolma@gmail.com" target="_blank">ari.jolma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">28.01.2016, 00:05, Even Rouault kirjoitti:<br>
<br>
Thanks for the pointer to the geometry codes in SF Common Architecture, somehow I overlooked it.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br>
</blockquote>
<br></span>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Ari</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">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></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">----------------------------------------------------------------------------------------------------------------<br>Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit (PRDU),<br> University of York<br><br>Snail mail: PRDU, Derwent College, University of York,<br> Heslington, York YO10 5DD<br>This message has the status of a private and personal communication<br>----------------------------------------------------------------------------------------------------------------</div>
</div>