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

[Ari Jolma]

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
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev