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

Jukka Rahkonen jukka.rahkonen at mmmtike.fi
Mon May 19 13:16:16 PDT 2014


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?

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?

-Jukka Rahkonen-




More information about the gdal-dev mailing list