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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
