Opened 8 years ago

Closed 8 years ago

#4396 closed defect (fixed)

OGR 1.8 and earlier truncates geometry precision

Reported by: athyder Owned by: warmerdam
Priority: normal Milestone: 1.9.0
Component: OGR_SF Version: 1.8.1
Severity: normal Keywords: geojson
Cc:

Description

I've attached a shapefile with a valid geometry. When converted to GeoJson? using ogr2ogr, we are left with an invalid geometry.

This same shapefile, when converted to GML and other formats using ogr2ogr does result in a valid geometry.

Attachments (1)

Archive.zip (4.3 KB) - added by athyder 8 years ago.
Shape, geojson, and gml example files.

Download all attachments as: .zip

Change History (6)

Changed 8 years ago by athyder

Attachment: Archive.zip added

Shape, geojson, and gml example files.

comment:1 Changed 8 years ago by warmerdam

Component: defaultOGR_SF
Keywords: ogr2ogr removed

I think you will need to explain why you think the geojson geometry is bad. I notice it is parsed successfully by OGR (trunk).

comment:2 Changed 8 years ago by athyder

I used ogrinfo on all three of the included files. Then I copy and pasted the the WKTgeometry into a postgres terminal. I checked geometry validity with PostGIS.

Is there a way to check validity with gdal?

good_geometry.shp:

select st_isvalid(st_geomfromtext('MULTIPOLYGON (((-87.897199765836902 43.035956858592499,-87.898664 43.02891,-87.898658143229 43.028909940936202,-87.898684 43.028813,-87.897862 43.02513,-87.902784 43.025014,-87.907584 43.030013,-87.910884 43.031613,-87.910162 43.034764,-87.910284 43.034613,-87.910484 43.038513,-87.913684 43.042713,-87.913784 43.045613,-87.913369 43.046639,-87.910769 43.047462,-87.909156 43.048222,-87.896649 43.048012,-87.893967 43.047045,-87.895646 43.04466,-87.896972 43.043482,-87.898494 43.040313,-87.898118 43.03958,-87.898118 43.039083,-87.899086 43.036751,-87.898763 43.036463,-87.898752 43.035753,-87.897283 43.035557,-87.897199765836902 43.035956858592499)),((-87.912885 43.052513,-87.909228 43.052472,-87.907639 43.05162,-87.913184 43.047313,-87.913369 43.046639,-87.915985 43.046513,-87.912985 43.049713,-87.912885 43.052513)))'));

st_isvalid


t

(1 row)

good_geometry.gml:

select st_isvalid(st_geomfromtext('MULTIPOLYGON (((-87.897199765836902 43.035956858592499,-87.898664 43.02891,-87.898658143229 43.028909940936202,-87.898684 43.028813,-87.897862 43.02513,-87.902784 43.025014,-87.907584 43.030013,-87.910884 43.031613,-87.910162 43.034764,-87.910284 43.034613,-87.910484 43.038513,-87.913684 43.042713,-87.913784 43.045613,-87.913369 43.046639,-87.910769 43.047462,-87.909156 43.048222,-87.896649 43.048012,-87.893967 43.047045,-87.895646 43.04466,-87.896972 43.043482,-87.898494 43.040313,-87.898118 43.03958,-87.898118 43.039083,-87.899086 43.036751,-87.898763 43.036463,-87.898752 43.035753,-87.897283 43.035557,-87.897199765836902 43.035956858592499)),((-87.912885 43.052513,-87.909228 43.052472,-87.907639 43.05162,-87.913184 43.047313,-87.913369 43.046639,-87.915985 43.046513,-87.912985 43.049713,-87.912885 43.052513)))'));

st_isvalid


t

(1 row)

bad_geometry.json: select st_isvalid(st_geomfromtext('MULTIPOLYGON (((-87.8972 43.035957,-87.898664 43.02891,-87.898658 43.02891,-87.898684 43.028813,-87.897862 43.02513,-87.902784 43.025014,-87.907584 43.030013,-87.910884 43.031613,-87.910162 43.034764,-87.910284 43.034613,-87.910484 43.038513,-87.913684 43.042713,-87.913784 43.045613,-87.913369 43.046639,-87.910769 43.047462,-87.909156 43.048222,-87.896649 43.048012,-87.893967 43.047045,-87.895646 43.04466,-87.896972 43.043482,-87.898494 43.040313,-87.898118 43.03958,-87.898118 43.039083,-87.899086 43.036751,-87.898763 43.036463,-87.898752 43.035753,-87.897283 43.035557,-87.8972 43.035957)),((-87.912885 43.052513,-87.909228 43.052472,-87.907639 43.05162,-87.913184 43.047313,-87.913369 43.046639,-87.915985 43.046513,-87.912985 43.049713,-87.912885 43.052513)))')); NOTICE: Self-intersection at or near point -87.8973 43.0356

st_isvalid


f

(1 row)

comment:3 Changed 8 years ago by warmerdam

It seems clear that the precision is being truncated in the geojson. I would presume that is leading to some sort of geometric degeneracy. I see that GDAL/OGR trunk (but likely not 1.8.x) has COORDINATE_PRECISION layer creation option and defaults to 15 decimal places. So you might want to upgrade to trunk and try with that.

comment:4 Changed 8 years ago by athyder

I rebuilt GDAL from trunk and am now getting perfectly valid GeoJson? with full geometric precision. Thank you for your successful suggestions.

As long as the GeoJson? precision truncation is left to 15 decimal places, this issue will be solved in the next release.

comment:5 Changed 8 years ago by warmerdam

Milestone: 1.9.0
Resolution: fixed
Status: newclosed
Summary: ogr2ogr creating invalid geojson geometriesOGR 1.8 and earlier truncates geometry precision
Note: See TracTickets for help on using tickets.