What is the difference between coordinate precision and accuracy?

Precision is how finely a coordinate is recorded — its number of decimal places or significant figures. Accuracy is how close it is to the true ground position. A coordinate can be highly precise (many decimals) yet inaccurate (in the wrong place), and the two are independent.

How many decimal places does a latitude/longitude need?

At the equator, 5 decimal degrees is about 1.1 m, 6 is about 0.11 m, and 7 is about 1.1 cm. For most mapping, 6 decimal places is plenty; recording 12 implies sub-micron precision no GNSS receiver delivers.

Why is storing many decimal places false precision?

Extra digits imply a measurement certainty the source never had. A handheld GPS good to a few metres stored at 8 decimal places (sub-millimetre) misleads any downstream user into trusting positions far beyond the data's real accuracy.

How do you check the real accuracy of a coordinate?

Compare measured points against independent control of higher accuracy (survey monuments, high-grade GNSS) and compute an error statistic such as RMSE or the data's stated CE90. Accuracy comes from the source and its datum, not from how many decimals you print.

Coordinate Precision vs Accuracy in GIS

The short answer

Precision is how finely a coordinate is recorded — the number of decimal places or significant figures. Accuracy is how close that coordinate is to the true position on the ground. They are independent: a point stored as 48.853491274 (eleven decimals, very precise) can still be 30 m from where it should be (inaccurate), and a point honestly rounded to 48.8535 can be dead on. Confusing the two is the root of a whole class of GIS errors, because software prints long, precise-looking numbers regardless of how accurate the underlying measurement actually was.

For most field and mapping work the practical guideline is: store about 6 decimal places of latitude/longitude (≈0.1 m), state the data's real accuracy separately in metadata, and never let decimal count masquerade as positional quality.

Defining the two cleanly

Borrow the classic target metaphor. Accuracy is whether your shots cluster around the bullseye (the true value). Precision is whether your shots cluster tightly together (repeatability), wherever they land. You can be:

Precise and accurate — tight cluster on the bullseye. The goal.
Precise but inaccurate — tight cluster, but offset from truth. The dangerous case, because the consistency looks trustworthy. A systematic datum error does exactly this.
Imprecise but roughly accurate — scattered around the bullseye, no single shot great but the average is right.
Neither — scattered and offset.

In coordinate data, precision is governed by how the number is stored and displayed (decimal places, field type). Accuracy is governed by how the number was measured — the receiver, the survey method, and crucially the datum and CRS.

How many decimals actually mean anything

Decimal degrees translate to ground distance, and the conversion makes false precision obvious. Near the equator, for longitude (latitude is similar everywhere):

Decimal places	Ground distance (≈, equator)
2	~1.1 km
3	~110 m
4	~11 m
5	~1.1 m
6	~0.11 m (11 cm)
7	~1.1 cm
8	~1.1 mm

(Longitude spacing shrinks toward the poles by a factor of cos(latitude), but the order of magnitude holds.) A consumer GNSS receiver is typically accurate to a few metres; an RTK survey reaches a few centimetres. So 6 decimal places already exceeds the accuracy of most field data, and storing 8–12 places records noise as if it were signal. Worse, those digits are often artefacts of a CRS transformation, not real measurements at all.

The trap: precision laundering through reprojection

Reprojection is where false precision is born. Transform a coordinate from WGS84 to UTM and back, and ST_Transform will happily return 48.85349127318472 — fifteen significant figures from an input that was good to maybe three. The transform is deterministic and reversible, so it generates digits; it does not generate accuracy. Software then displays all of them, and a downstream analyst, seeing eleven decimals, assumes millimetre-grade survey data.

-- The transform produces many digits; none add real accuracy
SELECT ST_AsText(ST_Transform(ST_SetSRID(ST_MakePoint(-1.234, 48.853), 4326), 32630));

The fix is not in the transform — it is in being explicit about the source accuracy and not over-storing. Round display values to the precision the data deserves, and keep the true accuracy in metadata.

Accuracy depends on datum, not decimals

A subtle, high-impact point: two coordinates with identical numbers can refer to different places if their datum differs. WGS84 and a national datum like NAD83 or ED50 can disagree by a metre to over a hundred metres depending on region. A point recorded as (48.853, -1.234) in ED50 plotted as if it were WGS84 lands in the wrong spot — a pure accuracy error with no loss of precision. This is why metadata must record the datum and EPSG code (e.g. EPSG:4326 vs EPSG:4258), not just "lat/long." Many "the data is in the wrong place" tickets are really undocumented-datum problems, not decimal problems.

A worked accuracy check

Suppose a field team delivers GPS points and you must state their accuracy honestly.

Identify independent control of higher accuracy — survey monuments, an RTK base, or a published high-grade dataset.

Reproject both sets into one projected, metric CRS so distances are in metres:

ALTER TABLE field_pts ALTER COLUMN geom
  TYPE geometry(Point, 32630) USING ST_Transform(geom, 32630);

Compute residuals — the distance from each field point to its matched control point with ST_Distance.
Summarise as RMSE — root mean square of those residuals. This is your horizontal accuracy figure, and it is what belongs in metadata (or report it as CE90 / horizontal accuracy to a standard such as the US NSSDA).
Set storage precision to match — if RMSE is 2 m, storing 6 decimal places (0.1 m) is fine for display but advertise the 2 m accuracy explicitly; never imply the data is better than 2 m.

Accuracy is a property you measure against truth; precision is a property you choose when storing. Keep them separate in both your head and your metadata.

Common mistakes and why they happen

Reading decimal count as quality. Long numbers look authoritative, and software prints them by default, so people equate digits with accuracy. They are unrelated.
Storing transform artefacts. Round-tripping through projections manufactures decimals; saving them propagates false precision through every downstream user.
Omitting the datum. "Lat/long" without an EPSG code is ambiguous; a datum mismatch is an accuracy error invisible to anyone checking only the numbers.
Ignoring vertical accuracy. Elevation accuracy (and the vertical datum — ellipsoidal vs orthometric height) is usually worse than horizontal and is routinely left undocumented.
Over-trimming precision. The opposite error: rounding to 3 decimals (110 m) throws away real accuracy that good data had. Match stored precision to measured accuracy, neither inflating nor discarding it.

Validation and QA

Before trusting a coordinate dataset, confirm the declared CRS and datum (EPSG code present, not assumed), check a few points against an independent reference to estimate RMSE, and inspect the stored precision — if every field has 12 decimals, suspect a reprojection artefact rather than survey-grade data. Record the measurement method, accuracy figure, datum, and date in metadata so the next user can weight the data correctly rather than inferring quality from decimal places.

Bathyl perspective

We keep precision and accuracy as two separate, explicitly stated properties of every coordinate deliverable: the stored precision matched to the data, and the measured accuracy (with datum and method) recorded in metadata. A coordinate that looks precise but carries no accuracy statement is a liability, because it invites the next analyst to trust it far beyond what the measurement supports. Making both visible is what lets someone downstream use the data correctly.

Coordinate Precision vs Coordinate Accuracy