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

[Ari Jolma]

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.

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.

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
>