#4820 closed defect (invalid)
gdal-1.9.x ogr2ogr GeoJSON files 240% bigger than from gdal-1.8.1
Reported by: | geep999 | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | 1.9.1 |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
gdal-1.9.x ogr2ogr GeoJSON files 240% bigger than from gdal-1.8.1. Why? Because 1.9.x outputs the lat/lon to 15 decimal places. With 1.8.1 it was 6 decimal places. See evidence below...
Please either change it back to the way 1.8.1 behaved, or make precision a user defined parameter, with a default of 6.
Cheers, Peter Gardner
PS I've only just noticed - og2ogr created a 3rd coordinate parameter?
What is it - height? Where does it come from? It wasn't there with gdal-1.8.1.
I don't need it - so I'd like to be able to specify to omit it. GeoJSON files are big enough already.
ogr2ogr -s_srs EPSG:27700 -t_srs EPSG:4326 \ -overwrite -f "GeoJSON" my_tl.epsg4326.GeoJSON my_tl.shp 1.9.1 23653288 Sep 23 09:26 my_tl.epsg4326.GeoJSON 1.8.1 9563557 Sep 23 09:33 my_tl.epsg4326.GeoJSON ogr2ogr --version GDAL 1.9.1, released 2012/05/15 head my_tl.epsg4326.GeoJSON { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "Layer": "G8040201", "SubClasses": null, "ExtendedEn": null, "Linetype": null, "EntityHand": null, "Text": null }, "geometry": { "type": "LineString", "coordinates": [ [ 0.016822571113167, 51.756581870823098, 75.178323162719607 ], [ 0.017009195734472, 51.756542697227765, 75.178066025488079 ], [ 0.017311250986214, 51.756492549096642, 75.177661038003862 ], [ 0.017499877692527, 51.756498303109353, 75.17743944004178 ], [ 0.017616910969434, 51.756523271267284, 75.177320023067296 ], [ 0.017693311859813, 51.756611884907691, 75.177303144708276 ], [ 0.017639402075006, 51.756702736136873, 75.177444605156779 ], [ 0.017241199608667, 51.756871438941332, 75.178065156564116 ], [ 0.015988726095384, 51.75705480011942, 75.17972360458225 ], [ 0.015358046969589, 51.757209499712381, 75.18061133287847 ], [ 0.015242213516009, 51.757211486372768, 75.180752055719495 ], [ 0.015124779575305, 51.757177530169955, 75.180864346213639 ], [ 0.015048782784429, 51.757097900511816, 75.180888323113322 ], [ 0.015086618701847, 51.756971355972006, 75.180736042559147 ], [ 0.01520125116168, 51.756942412409735, 75.180573993362486 ], [ 0.016035834593721, 51.756811193006939, 75.179461314342916 ], [ 0.016822571113167, 51.756581870823098, 75.178323162719607 ] ] } } , ogr2ogr --version GDAL 1.8.1, released 2011/07/09 head my_tl.epsg4326.GeoJSON { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "Layer": "G8040201", "SubClasses": "", "ExtendedEn": "", "Linetype": "", "EntityHand": "", "Text": "" }, "geometry": { "type": "LineString", "coordinates": [ [ 0.016823, 51.756582 ], [ 0.017009, 51.756543 ], [ 0.017311, 51.756493 ], [ 0.017500, 51.756498 ], [ 0.017617, 51.756523 ], [ 0.017693, 51.756612 ], [ 0.017639, 51.756703 ], [ 0.017241, 51.756871 ], [ 0.015989, 51.757055 ], [ 0.015358, 51.757209 ], [ 0.015242, 51.757211 ], [ 0.015125, 51.757178 ], [ 0.015049, 51.757098 ], [ 0.015087, 51.756971 ], [ 0.015201, 51.756942 ], [ 0.016036, 51.756811 ], [ 0.016823, 51.756582 ] ] } }
Change History (4)
comment:1 by , 12 years ago
Description: | modified (diff) |
---|
comment:2 by , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:3 by , 12 years ago
Thanks for the quick response. I did not realize that my data was 3D - thought it was 2D. Your suggestions solve my immediate problem.
However - trying a variant of what you suggest I note two possible bugs: 1/ -nlt LINESTRING works fine when both input and output are both .shp ESRI Shapefiles and suppresses the height data. But when I tried it with input of .dxf and output of GeoJSON then I still get 3D data. Not sure if this is a bug or not.
2/ When converting -s_srs EPSG:27700 -t_srs EPSG:4326 then the z data is also converted. In my data the height is in meters - surely it should not be transformed? e.g. EPSG:27700 data "coordinates": [ [ 516589.0, 202473.0, 70.0 ] becomes EPSG:4326 "coordinates": [ [ -0.314002, 51.708839, 115.531493 ]
Cheers, Peter Gardner
comment:4 by , 12 years ago
1/ : -nlt LINESTRING will only suppress the 3D component if the output is shapefile. So if you have a DXF you must do something like :
ogr2ogr 2d.shp input.dxf -nlt LINESTRING ogr2ogr 2d.geojson 2d.shp
2/ : When Z are converted from a SRS to another one, they are supposed to be ellipsoidal height, so when the ellipsoids are different, they are transformed. I'm not sure (and actually don't believe) if it is possible to have it untouched by the SRS transformation.
The doc of the GeoJSON driver at http://www.gdal.org/ogr/drv_geojson.html mentions a COORDINATE_PRECISION layer creation option. So to get the same precision as in GDAL 1.8 (but you will have potentially precision loss), you need to add -lco COORDINATE_PRECISION=6 on the ogr2ogr command line.
As far as the 3d value in coordinate tuples, it is the Z coordinate. So it means that your source file has such a Z value (you can check it by display ogrinfo -al my_tl.shp) and now the GeoJSON output takes it well into account when it is present.
One way to discard it if you are not interested is to do a preprocessing step :
ogr2ogr my_tl_2D.shp my_tl.shp -nlt LINESTRING