I finally have the (existing) autotests passing with the new API -
basically just replacing the nCoordDimension property of OGRGeometry
with flags (for Z and M) - and a rather large set of tests for
import/export WKT and WKB with M passing.
https://travis-ci.org/ajolma/GDAL-XYZM/builds/106725974
Maybe we should move to a vote on the RFC?
Ari
01.02.2016, 17:17, Even Rouault kirjoitti:
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
