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