[gdal-dev] Call for discussion about RFC 61: Support for measures in geometries

[Even Rouault]

Le dimanche 31 janvier 2016 09:58:31, Ari Jolma a écrit :
> This seems to be a pretty big thing to add but doable.
> 
> So, one more thing to discuss before going to vote later is the target
> milestone. Maybe add it to 2.1 as "an experimental feature" and aim for
> 2.2 as a more production ready? This of course assuming that I can get
> it implemented before 2.1. By "implemented" I mean generic support + one
> or two drivers (shape, pg) & passing current tests + basic set of new
> tests.

We have until end of march for the feature feeze of GDAL 2.1, so that lets 
some time. I could also potentially help if you need, for example during the 
OSGeo code sprint end of this month (for example on the spatialite M support, 
that is needed for SQLite dialect support or adding tests in Python test 
suite).
If we have core support (C++ changes, C API, WKB/WKT importer/exporters) + 
shape + pg working, that's enough I think to advertize as non-experimental.
GPKG support should also not require a lot of work (likely just advertizing 
the M capability) as it relies on WKB.

> 
> I've also edited the RFC draft according to what I've found / thought
> while developing. I'd be happy to get feedback about the proposed
> additions to the APIs.

Looks good to me.

I'm not completely sure about the opportunity to have #define wkbPointZ 
wkbPoint25D alias. Or at least it would deserve an explicit Doxygen comment to 
warn that it is an alias to the value used in the old 2.5D 99-402 extension, 
and not the value of the ISO SQL/MM Part 3 as one could expect from the name.
The situation is a bit messy. I thought about using ISO values for the 
existing 3D geometry types when implementing curve support in 2.0 but finally 
decided it wasn't worth the breakage.

> 
> What I right now have is a working WKT and WKB API for point geometries.
> Next I plan to test constructing and modifying geometries with
> get/set/add methods and then move to building the support into shape
> driver, while also adding more geometries to the WKT, WKB tests.
> 
> Best,
> 
> Ari
> 
> 28.01.2016, 16:09, Ari Jolma kirjoitti:
> > Folks, especially the PSC,
> > 
> > I'd like to call for discussion about RFC 61: Adding support for
> > measures in geometries.
> > 
> > Measures (M) are a sort of fourth coordinate for points in geometries.
> > A typical use of measures is for distance from origin in line strings
> > that represent roads but they can be used for other things as well.
> > 
> > Measures are a part of the simple features model and they are
> > supported by many vector data formats.
> > 
> > Since measures are a rather fundamental element, adding them will
> > require quite many changes into the basic building blocks of the GDAL
> > API. Most importantly, the 'int nCoordDimension' property of
> > OGRGeometry is proposed to be replaced by 'int flags', which will have
> > bit flags denoting whether the geometry is empty and has Z or M
> > coordinates.
> > 
> > No backwards incompatible changes (syntactic nor semantic) will be
> > done but the methods getCoordinateDimension and setCoordinateDimension
> > will be deprecated since they do not take into account M coordinate.
> > 
> > The RFC is as usual in the wiki:
> > 
> > https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries
> > 
> > There are a couple of decisions to be made (if the overall decision is
> > positive).
> > 
> > Should the set3D(b3D) method (and also for example AddGeometry method)
> > of GeometryCollection force all child geometries to be 3D (or 2D and
> > remove possible Z values)? Maybe just unsetting the flag when
> > downgrading is enough?
> > 
> > Should storing data, with measures, into a format, which does not
> > support measures, remove M values from the data? This would be similar
> > to the current behavior with curved geometries and formats which do
> > not support them.
> > 
> > Some smaller issues are mentioned/hinted to in the draft RFC.
> > 
> > I have set up a github repository for the work at
> > 
> > https://github.com/ajolma/GDAL-XYZM
> > 
> > It has an associated travis builder - which however seems to have some
> > problems right now. I have committed the API changes from the draft
> > RFC and it compiles but there is a lot to do with actually
> > implementing the support.
> > 
> > Best regards,
> > 
> > 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