Opened 12 years ago
Closed 12 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)
Change History (6)
by , 12 years ago
Attachment: | Archive.zip added |
---|
comment:1 by , 12 years ago
Component: | default → OGR_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 by , 12 years ago
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 by , 12 years ago
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 by , 12 years ago
comment:5 by , 12 years ago
Milestone: | → 1.9.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Summary: | ogr2ogr creating invalid geojson geometries → OGR 1.8 and earlier truncates geometry precision |
Shape, geojson, and gml example files.