GeoJSON Coordinate Precision: How Many Decimal Places Do You Really Need?

The default that nobody asked for

Open any GeoJSON file straight out of QGIS or ogr2ogr and the coordinates look like this:

"coordinates": [13.405257081985474, 52.51625359857423]

Fourteen decimal places. That is the default output of double-precision floats serialised to JSON. It is overkill — and not by a small margin.

What each decimal place actually buys

Near the equator, one degree of longitude is roughly 111,320 metres. Each additional decimal place divides that by ten:

Latitude is identical at the equator; longitude tightens as you head toward the poles (multiply by cos(latitude)).

The cost of unused precision

GeoJSON stores every coordinate as an ASCII decimal in a JSON array. A 14-digit number takes about 16 bytes; a 6-digit number takes about 8. For a polygon layer with 1 million vertices, that is 16 MB vs 8 MB, halved with no observable change on a map.

For a feature collection delivered over the wire, this matters. Gzip recovers some of the redundancy, but not all of it — the entropy of 52.51625359857423 is higher than 52.516254.

What precision is actually justified

The GPS chip in a modern phone is accurate to 3–5 metres in open sky and 10+ metres in urban canyons. Aerial photogrammetry hits 10–30 cm. Survey-grade RTK GNSS reaches 1–2 cm. No civilian sensor produces meaningfully better than 1 cm of horizontal accuracy.

Storing coordinates at 8 decimal places (~1 mm) is asserting a precision your sensors don't have. The extra digits are noise dressed up as data.

Recommendations

For each use case:

• Web maps (Leaflet, Mapbox, MapLibre): 5 decimal places (~1 m). Indistinguishable from higher precision at any zoom level below z18, and noticeably smaller files.
• Mobile field collection: 6 decimal places (~10 cm). Accommodates fix improvements over time without padding noise.
• Survey / cadastral / engineering: 7–8 decimal places. Only domain where the extra digits represent real measurement.
• Public dataset publishing: 6 decimal places. Strikes the balance between "honest about precision" and "file size matters."

How to reduce precision

The simplest route is GDAL:

ogr2ogr -f GeoJSON -lco COORDINATE_PRECISION=6 out.geojson in.geojson

The COORDINATE_PRECISION layer creation option truncates every coordinate to the specified number of decimal places on write.

In Python with Fiona:

import fiona
with fiona.open("in.geojson") as src:
    with fiona.open("out.geojson", "w", driver="GeoJSON",
                    schema=src.schema, crs=src.crs,
                    PRECISION=6) as dst:
        dst.writerecords(src)

In Node.js with turf:

import { truncate } from "@turf/turf";
const out = truncate(input, { precision: 6, coordinates: 2 });

A note on TopoJSON

TopoJSON encodes coordinates as integer offsets from a quantisation grid, which makes precision a knob expressed differently (the quantization parameter). For most web use cases, quantization: 1e5 is the equivalent of 5 decimal places in GeoJSON.

The bottom line

Coordinate precision is a thoughtful default, not a passive one. Pick the lowest precision that preserves your sensor's actual accuracy. Anything beyond that is paying transit cost for digits nobody can use.