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

[Ari Jolma]

29.01.2016, 11:04, Even Rouault kirjoitti:
>>> I had let an inline comment in the RFC regarding that. My opinion is that
>>> child geometries should be affected to avoid building geometries that are
>>> odd, and perhaps non conformant (should be checked but I'd be surprised
>>> it is legal to have the container and the containee with different
>>> coordinate dimensions. At least it cause problems in practice). On
>>> WKB/WKT import, we are curently lax, which is OK, and we accept mixed
>>> coordinate dimensions, but we upgrade the whole geometry to full XYZ as
>>> soon as the container or a containee is XYZ. On export (actually, when
>>> building OGRGeometry instances), we should be more strict.
>> The flags should be the definitive indicators but I was entertaining the
>> idea that maybe XYZ data could be put into a collection without
>> physically removing the Z so it would be available later if it is needed
>> for some reason. Maybe that kind of behavior should not be
>> there/advertised and users should be given simple rules when Z or M
>> can't be expected to exist any more.
> Would your idea would be to strip off the Z/M component when adding a XYZ/M
> geometry to a XY GeometryCollection ?
> The current strategy if you add a XYZ geometry to a XY GeometryCollection with
> already members, is to add Z=0 to those existing members.

Well, that's the question: how to manage data vs coordinate dimension.

If the above is the current strategy, then it should be extended to M. I 
guess there isn't so much an issue since the current strategy with Z is 
extendable to M usually. I'm just not well aware of the current strategy 
until I get to that part of the code.

Ari

>