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