[gdal-dev] Support for measures

[Peter Halls]

Even,

     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.

Best wishes,

Peter

On 28 January 2016 at 09:04, Even Rouault <even.rouault at spatialys.com>
wrote:

> 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
>



-- 
----------------------------------------------------------------------------------------------------------------
Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit
(PRDU),
                      University of York

Snail mail: PRDU, Derwent College, University of York,
                Heslington, York YO10 5DD
This message has the status of a private and personal communication
----------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160128/4a777d68/attachment.html>