[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