[gdal-dev] Support for measures

[Even Rouault]

Le jeudi 28 janvier 2016 09:58:06, Peter Halls a écrit :
> Ari, Even,
> 
>       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.
> 
>        There may need to be a debate about what the replacement M attribute
> be called, of course!

Peter,

This could only easily be done for a point geometry. For other geometries, it 
means storing several values per feature. Storing the source WKT would be an 
easy solution.

Something you could do with something like (provided the OGR<-->SQLite bridge, 
actually OGR<-->Spatialite blobs, is updated to support M)

ogr2ogr [....] poly.shp  -dialect sqlite \
            -sql "select *, st_astext(geometry) as wkt from poly"

Even

> 
> Best wishes,
> 
> Peter
> 
> On 28 January 2016 at 08:23, Ari Jolma <ari.jolma at gmail.com> wrote:
> > 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
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com