Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#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 geep999)

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 geep999, 12 years ago

Description: modified (diff)

comment:2 by Even Rouault, 12 years ago

Resolution: invalid
Status: newclosed

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

comment:3 by geep999, 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 Even Rouault, 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.

Note: See TracTickets for help on using tickets.