[gdal-dev] Number accuracy in convertion shp to geojson

[Even Rouault]

Le lundi 19 mai 2014 22:16:16, Jukka Rahkonen a écrit :
> Hi,
> 
> I have shapefile like this:
> >ogrinfo geojsontest.shp -al|more
> 
> INFO: Open of `geojsontest.shp'
>       using driver `ESRI Shapefile' successful.
> 
> Layer name: geojsontest
> Geometry: Point
> Feature Count: 5
> Extent: (5.000000, -40.000000) - (30.000000, -15.000000)
> Layer SRS WKT:
> (unknown)
> id: Real (11.0)
> attr: Real (11.0)
> OGRFeature(geojsontest):0
>   id (Real) = 12
>   attr (Real) = 3
>   POINT (5 -25)
> 
> I converted the shapefile into geojson with command:
> >ogr2ogr -f "GeoJSON"  geojsontest.json -s_srs EPSG:4326 -t_srs EPSG:3857
> 
> -lco coordinate_precision=0 geojsontest.shp
> 
> As a result I get
> { "type": "Feature", "properties": { "id": 12.000000, "attr": 3.000000 },
> "geometry": { "type": "Point", "coordinates": [ 556597, -2875745 ] } },
> 
> Why so many decimals in "id" and "attr"? Doesn't definition (11.0) in dbf
> file mean that it has max 11 numbers and 0 decimals, thus it is an integer?

Yes, but with 11 figures, you can have an integer that is more than a signed 32 
bit integer, hence the choice of the shapefile driver to expose those fields as 
real to avoid integer overflow.

> 
> Data comes from OpenJUMP and the developer writes:
> 
> "Basic data types of dBase III format are :
> C (Character) 	All OEM code page characters.
> D (Date) 	Numbers and a character to separate month, day, and year 
(stored
> internally as 8 digits in YYYYMMDD format).
> N (Numeric) 	- . 0 1 2 3 4 5 6 7 8 9
> L (Logical) 	? Y y N n T t F f (? when not initialized).
> M (Memo) 	All OEM code page characters (stored internally as 10 digits
> representing a .DBT block number).
> 
> AFAIK, OpenJUMP uses only C, D and N
> 
> For integers, it exports a numeric of length 11 with 0 decimals
> For doubles, it exports a numeric of length 33 with 16 decimals
> While reading a dbf, OpenJUMP reads column with 0 decimal as integers and
> columns with 1 decimal or more as double"
> 
> Is there something wrong with the dbf created by OpenJUMP or is the OGR
> geojson driver doing wrong when it writes out decimal numbers?

The GeoJSON driver doesn't honour field width and precision when writing.

> 
> -Jukka Rahkonen-
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html