<div dir="ltr"><div><div><div><div>Ari,<br><br></div> I do not think that Z and M can ever be truly synonymous: whilst z is partially defined in terms of, for example, a datum, there is no equivalent for M. Also, by convention, X, Y and Z frequently employ the same units; there is no equivalent convention for M (as yet). <br><br></div><div> There may be a philosophical case for using M for altitude measurements instead of Z where X and Y use spherical or other non-linear units.<br></div><div><br></div> Currently, there are a number of disparate uses of the M value, for example, in terms of variations in feature width, cant, segment length, etc. I have (once) seen M used for an integer code to report variations in surface texture. I do not know how many specialised uses there may be.<br><br></div>Best wishes,<br><br></div>Peter<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 January 2016 at 10:55, 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">Folks,<br>
<br>
I'd like to try to implement the XYZM support since I have some free time.<br>
<br>
Before making a RFC, there are some thoughts/questions/ideas:<br>
<br>
* I made a fork for this work at <a href="https://github.com/ajolma/GDAL-XYZM" rel="noreferrer" target="_blank">https://github.com/ajolma/GDAL-XYZM</a> so I can more easily use travis.<br>
<br>
* I think this is mainly changes in the geometry API and generic methods.<br>
<br>
Are there other drivers than shape, which are affected? Currently shape driver creates XYZ data from XYM data, that would change, which may break some code.<br>
<br>
* Currently XYM or XYZM data seems to be accepted (by WKT and WKB importers for example) but not stored in generic objects.<br>
<br>
* The closeness of XYZ and XYM might need some thought:<br>
<br>
For example C++ API for making a adding a XYZ and XYM point to a curve would be the same. Currently the method calls Make3D() if the curve is 2D, which is not ok for XYM data.<br>
<br>
Tickets related to this are<br>
<br>
<a href="https://trac.osgeo.org/gdal/ticket/6063" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/6063</a><br>
<a href="https://trac.osgeo.org/gdal/ticket/6331" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/6331</a><br>
<br>
Are there other things I should know?<br>
<br>
The target would be 2.1 I guess.<br>
<br>
Ari<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></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>