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 -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
