MultiLineString OGRGeometry dimensions change on transform

[Charlie DeTar]

After calling "transform" on a 2D MultiLinestring OGRGeometry object, wkt returned by the OGRGeometry object is 3D.

Comments the definition of OGRGeometry.transform in django/contrib/gis/gdal/geometries indicate that this may be a result of a GDAL bug (​http://trac.osgeo.org/gdal/changeset/17792 ) present in GDAL versions prior to 1.7. The transform function has a workaround that resets the OGRGeometry object's dimension property, but the resulting object still returns 3D wkt.

Attached is a failing test case.

[Charlie DeTar]

Failing test case for OGRGeometry.transform changing WKT dimensions from 2D to 3D

[Charlie DeTar]

A little more info: after transformation, OGRGeometry objects return 3D WKT for LineString and MultiLineString types, including LineString's inside of GeometryCollection's.

GEOSGeometry objects return 2D WKT, even if they are 3D.

In order to transform a geometry and then get properly dimensioned WKT, it is thus necessary to first convert to a GEOSGeometry if the geometry is 2D, or to convert to an OGRGeometry otherwise. Neither class will handle all cases.

[jbronn]

The coord_dim property is what you're looking for, as it's what specifies the coordinate dimension. dimension on the other hand calls ​OGR_G_GetDimension, which returns 0 for points, 1 for lines, and 2 for surfaces. I guess it considers MultiLineStrings 'surfaces', but you should take that up w/the GDAL developers, as it's returning the right result from GDAL.

[Charlie DeTar]

Replying to jbronn:

Apologies if there was confusion: the reported dimension (e.g. coord_dim) is not the problem this bug report is about. The problem this bug report is about is the returned WKT string.

If I create a 2D OGRGeometry object, e.g. OGRGeometry("MULTILINESTRING ((0 0,1 1,2 2))"), and then call transform, the object will subsequently return 3D WKT (e.g. MULTILINESTRING ((0 0 0,1 1 0,2 2 0))) strings when I call wkt.

This is a problem because postgis will refuse to accept wrongly-dimensioned WKT for updates and inserts, even if the third dimension is zero. Thus, if I attempt to transform a geometry, I can't subsequently write it to the database without modification. This may still be an upstream problem, and if so, I'll happily post it there, but it has a real downstream effect right now.

I'll attach an updated patch that uses the "coord_dim" property instead of the "dimension" property.

[Charlie DeTar]

correcting dimension property to coord_dim

[jbronn]

Replying to yourcelf:

Apologies if there was confusion: the reported dimension (e.g. coord_dim) is not the problem this bug report is about. The problem this bug report is about is the returned WKT string.

Thanks for clarifying yourcelf, I see exactly what you're talking about now. This doesn't occur on 1.7, but I'm seeing it on 1.5 (and, I'm also assuming 1.6). Thus, this smells to me still like a manifestation of the original bug I found in OGR -- even though I'm changing the coordinate dimension back to what it should be, it's coordinates still have Z values set internally (to 0.0, instead of NULL) after the transform, and the WKT serialization code may be "dumb" and look to see if it's NULL rather than verifying w/the coordinate dimension.

I'll see if I can find a workaround again inside GeoDjango, but there may be nothing I can do, as the solution would be to fix the WKT serialization code in 1.5.X and 1.6.X branches of GDAL. Unfortunately, I may have to close as invalid if that's the case.

[jbronn]

Extended GDAL bug workaround to geometry collections.

[jbronn]

(In [12878]) Fixed #12312 -- Set the coordinate dimension on each component of geometry collections after transform (refines GDAL bug workaround introduced in r11628). Thanks, yourcelf for bug report.

[jbronn]

(In [12879]) [1.1.X] Fixed #12312 -- Set the coordinate dimension on each component of geometry collections after transform (refines GDAL bug workaround introduced in r11629). Thanks, yourcelf for bug report.

Backport of r12878 from trunk.

[jbronn]

(In [12883]) Added another GDAL bug workaround for retrieving the correct coordinate dimension on geometry collections. Refs #12312.

[jbronn]

(In [12884]) [1.1.X] Added another GDAL bug workaround for retrieving the correct coordinate dimension on geometry collections. Refs #12312.

Backport of r12883 from trunk.