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

[Ari Jolma]

28.01.2016, 16:46, Even Rouault kirjoitti:
> "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.

Yes. Removing nCoordDimension and replacing it with the three flags 
(empty, Z, M) within an int is to keep the size of the geometry objects 
small, so it is not directly a consequence of having measures.

But in general I think it is a positive thing to have an explicit 
indicator of an empty geometry.

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

Sure. They are pretty central to the whole issue. I'll work on those 
since with them some tests can be set up.

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

To have shape and pg drivers to support M is or has been my concern for 
years.

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

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.

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

Thanks, these issues need to be added to the RFC. My opinion is probably 
the same as above. Simple rules, which tell when Z and/or M will be 
stripped of, are good.

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

Thanks.

I let this be a discussion item for some time now. There may still be 
other issues, which we have not thought about yet.

Ari

>
> Even
>