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

[Even Rouault]

Le vendredi 29 janvier 2016 10:52:48, Jukka Rahkonen a écrit :
> Ari Jolma <ari.jolma <at> gmail.com> writes:
> > 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.
> 
> I wonder what should happen when GDAL creates new vertices. It does not
> seem to be clear even with XYZ as can be seen from this example:
> 
> Take LINESTRING ( 184 389 0, 858 346 100 )
> Run ogr2ogr with -segmentize 1
> 
> Result: The first vertex of the new linesting has Z=0, all the other
> vertices have Z=100.

Digging into history, the original behaviour was setting Z=0 for all 
interpolated points. I modified it 
inhttps://trac.osgeo.org/gdal/changeset/26458 with the following comment : 
"don't set 0 as z for interpolated points, but the z from the previous point 
(not sure why we don't do interpolation)"

As it didn't seem to match the behaviour you noticed (the Z being the one of 
the next point in that case), I investigated a bit and the method was changed 
when support of curve geometries have been added. So as to be sure that 
linearized lines create the same intermediate points if the same curve is 
followed in a direction or the reverse direction (to avoid gaps), the line may 
be temporarily reversed during the segmentation process, so that the x of the 
first point is < the one of the last point (or if x are equal, that the y of 
the first point is < the one of the last point). So the z is taken from the 
value of the prev or next point depending on the cases.

> 
> With XYZ data users might be happy if Z value gets interpolated just like X
> and Y  but for measurements it could be not desired at all.

No strong opinion or this.

> Does M dimension
> support anything like NoData?

We could potentially put a not-a-number IEEE754 value (but it should be 
verified if it is legal in WKT output). I think it is quite common to get 
shapefiles/filegdbs with M values set to not-a-number

> 
> There must be also other cases when GDAL can create unexpected M values but
> probably we can only warn users about that in the documentation.
> 
> -Jukka Rahkonen-
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com