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

[Even Rouault]

Le jeudi 28 janvier 2016 15:09:06, Ari Jolma a écrit :
> Folks, especially the PSC,
> 
> I'd like to call for discussion about RFC 61: Adding support for
> measures in geometries.

Thanks for leading the effort.

> 
> Measures (M) are a sort of fourth coordinate for points in geometries. A
> typical use of measures is for distance from origin in line strings that
> represent roads but they can be used for other things as well.
> 
> Measures are a part of the simple features model and they are supported
> by many vector data formats.
> 
> Since measures are a rather fundamental element, adding them will
> require quite many changes into the basic building blocks of the GDAL
> API. Most importantly, the 'int nCoordDimension' property of OGRGeometry
> is proposed to be replaced by 'int flags', which will have bit flags
> denoting whether the geometry is empty and has Z or M coordinates.
> 
> No backwards incompatible changes (syntactic nor semantic) will be done
> but the methods getCoordinateDimension and setCoordinateDimension will
> be deprecated since they do not take into account M coordinate.
> 
> The RFC is as usual in the wiki:
> 
> https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries

"Currently hacks such as nCoordDimension == -2 are used to denote empty 
geometries" --> to be pedantic, this is only true for point. Other geometry 
types don't need that since they are containers/vectors and if the 
container/vector size is 0, it means empty.

I suppose you intend upgrading the WKT&WKB importer&exporter ?

I think that beyond retrofitting drivers to avoid using 
setCoordinateDimension(), it would be good to have at least one driver 
implementing M reading/writing to validate that the RFC is operational : 
shapefile ?

> 
> There are a couple of decisions to be made (if the overall decision is
> positive).
> 
> Should the set3D(b3D) method (and also for example AddGeometry method)
> of GeometryCollection force all child geometries to be 3D (or 2D and
> remove possible Z values)? Maybe just unsetting the flag when
> downgrading is enough?

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.

> 
> 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.
> 
> Some smaller issues are mentioned/hinted to in the draft RFC.

I'd like to see mentionned what we do when GEOS operations are involved. And I 
think the answer is "strip off the M coordinate"

Similarly when installing a spatial filter. The current generic implementation 
(and probably most specialized implementations, the one in PostgreSQL driver 
for example) are 2D only. So a M component from a XYM / XYZM filter geometry 
would be ignored similarly to a Z component.

We have currently OGRGeometry and OGRLayer::GetExtent() & GetExtent3D() 
methods, and OGREnvelope / OGREnvelope3D classes. Should we have something for 
M ? I don't think it is really needed (or make sense at all, depending on what 
is encoded in the M coordinate). Shapefiles store however the min/max M value 
in its header

> 
> I have set up a github repository for the work at
> 
> https://github.com/ajolma/GDAL-XYZM
> 
> It has an associated travis builder - which however seems to have some
> problems right now. I have committed the API changes from the draft RFC
> and it compiles but there is a lot to do with actually implementing the
> support.

It does not have problem from what I can see. Just that the error log is a bit 
hard to decypher because of parallel compilation and thus errors are not 
necessarily reported at the bottom. If you look for "error: ", you will see:

ogrgeometry.cpp:838:47: error: unused parameter 'nNewDimension'

      [-Werror,-Wunused-parameter]

void OGRGeometry::setCoordinateDimension( int nNewDimension )

                                              ^

When you compile locally, you can use 'make USER_DEFS="-Werror"' to catch most 
of these (other errors may still be reported by other compilers used in the 
other Travis configs after it has been committed to SVN)

Even

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