I am using ogr2ogr to convert the data from PostgreSQL to GeoJSON. PostgreSQL contains field named shape.area, type numeric, which stores values up to 17 decimal places, like 0.15627328781960101.

The conversion to the GeoJSON is successful, but the decimal digits for shape.area field are rounded to 6 decimal places producing the value 0.156273.

The coordinate values are displayed with 15 decimal places and that is good.

I am using this command for the conversion:

ogr2ogr -f "GeoJSON" "D:\test.geojson" PG:"host=localhost user=postgres dbname=xx active_schema=xx  password=xx port=5432" "table"

I did try this conversion with GDAL 2.0.2 on CentOS and 1.11.3 on Win and the rounding is the same. The conversion to shapefile preserves the precision so this must have to do something specifically with the conversion to GeoJSON.

Am I missing some configuration switch? Is there a way to preserve the precision while exporting numeric values to GeoJSON format?


There is a configuration switch for this in GDAL 2.1 onwards: http://www.gdal.org/drv_geojson.html

It defaults to 16 decimal places. So upgrading to GDAL 2.1 should solve your issue. If not you can try a higher number of decimal for floating point numbers:

  • Thanks, I have seen that. Do you know any solution for the versions<2.1? Apr 28 '16 at 11:23
  • I think that SIGNIFICANT_FIGURES was introduced for making it possible to truncate decimals and make GeoJSON smaller. I would make some more tests with demo data but before suggesting anything, which GDAL version do you have?
    – user30184
    Apr 28 '16 at 11:32
  • You could try converting the column in the database to character varying before export. Apr 28 '16 at 11:39
  • @user30184 As I stated in the initial question, I tried this with two GDAL versions, 2.02 and 1.11.3. Apr 28 '16 at 11:40
  • @Vesanto If I convert the data to text, then the field in the GeoJSOn would be enclosed in quotes, since it would represent text. Apr 28 '16 at 11:43

I made a test with OSGeo4W version of GDAL

gdalinfo --version
GDAL 2.0.2, released 2016/01/26

I created a test point in OpenJUMP JML format with one decimal attribute.

<?xml version='1.0' encoding='UTF-8'?>
<JCSDataFile xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" >
          <valueElement elementName="property" attributeName="name" attributeValue="number"/>
          <valueLocation position="body"/>

                  <gml:coordinates>420.0,340.0 </gml:coordinates>
          <property name="number">1.00000000001</property>


Copy-paste and save on your disk and you can play with the same data.

Conversion into GeoJSON

ogr2ogr -f geojson precision.json precision.jml

Check the result

"type": "FeatureCollection",

"features": [
{ "type": "Feature", "properties": { "number": 1.000000 }, "geometry": { "type": "Point", "coordinates": [ 420.0, 340.0 ] } }

Truncation confirmed.

Also confirmed that GDAL 2.1-dev creates correct result without any extra parameters simply with ogr2ogr -f geojson prec2.json precision.jml.

"type": "FeatureCollection",
"features": [
{ "type": "Feature", "properties": { "number": 1.00000000001 }, "geometry": { "type": "Point", "coordinates": [ 420.0, 340.0 ] } }
  • As stated above, I don't have a problem with the coordinate precision, I get 15 decimal places, which is sufficient. But the numeric attribute field is rounded to 6 decimal places. This actually sounds so simple, but I can't think of a reason for cutting the decimal precision on a numeric field. And it doesn't happen when converting to shapefile. Apr 28 '16 at 11:46
  • Exactly, I apologize. I confirmed your issue and edited the answer accordingly.
    – user30184
    Apr 28 '16 at 11:52
  • No, there are no large numbers, just a very high precision on decimal part. Exactly my point! Apr 28 '16 at 11:53
  • You may try to report the bug in gdal-dev list and ask to get the fix backported. However, GDAL 2.1.0 will be released very soon because it seems to be accepted yesterday by the project steering committee.
    – user30184
    Apr 28 '16 at 12:04
  • Thanks for the advise and the test samples. I will create the GeoJSON myself in code from the database records. I was just wondering if I was missing something on the ogr2ogr conversion process since it didn't make sense to behave this way. Apr 28 '16 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.