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

[Even Rouault]

> > 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