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