<div dir="ltr"><div><div><div>Even,<br><br></div>     agreed.  I guess I have become rather too embedded in Oracle these days: any SQL method that supports blobs should provide the same.  The bigger issue would be for those methods that cannot support blobs, arrays, etc, where this wkt would be pretty much the only viable alternative.<br><br></div>Best wishes,<br><br></div>Peter<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 January 2016 at 09:04, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le jeudi 28 janvier 2016 09:58:06, Peter Halls a écrit :<br>
> Ari, Even,<br>
><br>
>       one potential solution where M data are present but not supported by<br>
> the Geometry type would be to add M as a user defined attribute, as is done<br>
> for Z values in some drivers / packages.  This preserves both the geometry<br>
> integrity and the data.  Should the user wish to 'upgrade' the dataset to a<br>
> full xyzm structure at some future date, this is then their explicit<br>
> 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<br>
> be called, of course!<br>
<br>
</span>Peter,<br>
<br>
This could only easily be done for a point geometry. For other geometries, it<br>
means storing several values per feature. Storing the source WKT would be an<br>
easy solution.<br>
<br>
Something you could do with something like (provided the OGR<-->SQLite bridge,<br>
actually OGR<-->Spatialite blobs, is updated to support M)<br>
<br>
ogr2ogr [....] poly.shp  -dialect sqlite \<br>
            -sql "select *, st_astext(geometry) as wkt from poly"<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Best wishes,<br>
><br>
> Peter<br>
><br>
> On 28 January 2016 at 08:23, Ari Jolma <<a href="mailto:ari.jolma@gmail.com">ari.jolma@gmail.com</a>> wrote:<br>
> > 28.01.2016, 00:05, Even Rouault kirjoitti:<br>
> ><br>
> > Thanks for the pointer to the geometry codes in SF Common Architecture,<br>
> > somehow I overlooked it.<br>
> ><br>
> > my point with adding the new capabilities was that drivers that wouldn't<br>
> ><br>
> >> advertize the M capabilities would never see a M or ZM geometry /<br>
> >> geometry type passed. See what the (non-virtual) methods<br>
> >> OGRLayer::SetFeature(),CreateFeature() and GDALDataset::CreateLayer() do<br>
> >> for curve geometries. Similar things could be done for M.<br>
> ><br>
> > Hm. For example shape driver raises an error if the geometry type is not<br>
> > 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<br>
> > that using a driver, which does not support measures. The impact is that<br>
> > the measures are stripped out, which is ok if the data is discarded<br>
> > immediately after that but not if she wants to still do something with<br>
> > the measures. I'm not sure if documenting the side-effect is enough.<br>
> > However, the convert to non linear geometries is already there and this<br>
> > would follow that pattern. I guess this is a part of the bigger<br>
> > discussion whether we consider GDAL as a data storage for interactive<br>
> > tools for example or as a data processing library.<br>
> ><br>
> > Ari<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > gdal-dev mailing list<br>
> > <a href="mailto:gdal-dev@lists.osgeo.org">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><br>
<br>
--<br>
</div></div><div class="HOEnZb"><div class="h5">Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</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>