Opened 18 years ago
Last modified 17 years ago
#1323 closed defect (fixed)
XYZM data cannot be read from wkb
Reported by: | Owned by: | Mateusz Łoskot | |
---|---|---|---|
Priority: | highest | Milestone: | |
Component: | OGR_SF | Version: | unspecified |
Severity: | blocker | Keywords: | |
Cc: | ari.jolma@… |
Description (last modified by )
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.
Attachments (1)
Change History (6)
comment:2 by , 17 years ago
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.
comment:3 by , 17 years ago
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.
comment:5 by , 17 years ago
Description: | modified (diff) |
---|
Note:
See TracTickets
for help on using tickets.