Code

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12312 closed (fixed)

MultiLineString OGRGeometry dimensions change on transform

Reported by: yourcelf Owned by: jbronn
Component: GIS Version: master
Severity: Keywords: gdal OGRGeometry 3D
Cc: chazen@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Attachments (3)

12312_ogrgeometry_transform_wkt_3d.diff (1.4 KB) - added by yourcelf 4 years ago.
Failing test case for OGRGeometry.transform changing WKT dimensions from 2D to 3D
12312_ogrgeometry_transform_wkt_3d_v2.diff (1.4 KB) - added by yourcelf 4 years ago.
correcting dimension property to coord_dim
12312.diff (5.6 KB) - added by jbronn 4 years ago.
Extended GDAL bug workaround to geometry collections.

Download all attachments as: .zip

Change History (13)

Changed 4 years ago by yourcelf

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

comment:1 Changed 4 years ago by yourcelf

  • Cc chazen@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 4 years ago by jbronn

  • Owner changed from nobody to jbronn
  • Status changed from new to assigned

comment:3 Changed 4 years ago by russellm

  • Triage Stage changed from Unreviewed to Accepted

comment:4 follow-up: Changed 4 years ago by jbronn

  • Resolution set to invalid
  • Status changed from assigned to closed

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.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 4 years ago by yourcelf

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

Changed 4 years ago by yourcelf

correcting dimension property to coord_dim

comment:6 in reply to: ↑ 5 Changed 4 years ago by 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.

Changed 4 years ago by jbronn

Extended GDAL bug workaround to geometry collections.

comment:7 Changed 4 years ago by jbronn

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by jbronn

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

comment:10 Changed 4 years ago by 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.