XYZM data cannot be read from wkb

[ari.jolma@…]

importWkb methods corrupt XYZM data when importing it since the dimension is incorrectly set to 2.5D. The dimension could be checked in the methods by statement

int dimension = (nSize - 5) / (nNewNumPoints*8);

The vertex data can be correctly imported then in XYZM case using

for( i = 0; i < nPointCount; i++ ) {
      memcpy( paoPoints + i, pabyData + 9 + i*32, 16 );
      memcpy( padfZ + i, pabyData + 9 + 16 + i*32, 8 );
    }

which should be executed if dimension == 4

This is related to #1036 and should be fixed when it is fixed. The M data is discarded in both fixes, but support for it should be added to OGR. I'd be in fact interested in doing that.

[warmerdam]

Mateusz, 

Like Bug 1036 there is no big hurry, but we will hopefully address it before 
the next release.

[Mateusz Łoskot]

EWKB geometries test

[warmerdam]

I concur.  modify the postgis driver to reliably report an error for geometries
with "M" and don't make any changes to ogr core wkb processing.

At some point there will be an OGC specification for WKB with M and we will 
aim to support that in the core. 

[Mateusz Łoskot]

Applied fix to the PG driver that detects 4-dimensional variant of EWKB geometry. If XYZM geometry is detected, an error message is reported and NULL geometry is assigned to a feature.

Detailed changeset:
http://trac.osgeo.org/gdal/changeset/11041

This situation occurs if a user reads features from a custom query like

OGRPGDataSource::ExecuteSQL("SELECT wkb_geometry FROM mytable", NULL, NULL);


The problem does not occur if a layer is accessed using
OGRPGDataSource::GetLayerByname()

Then, geometry is read in EWKT form and parsed correctly without any errors
but M coordinate is omitted.

[Mateusz Łoskot]

I ported these fixes to the stable branch 1.4 (r11226).