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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Geospatial professional services
http://even.rouault.free.fr/services.html
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
