Auditing Reprojection Accuracy Loss

Part of: CRS and Datum Transformation Provenance

Every reprojection costs something. The question a published dataset eventually attracts is not whether accuracy was lost but how much, and answering it requires having recorded the per-step contributions while they were still knowable. This how-to turns the accuracy figures that PROJ already reports into an auditable accumulation, so that a product’s stated positional accuracy is derived rather than asserted.

The distinction matters because accuracy claims get published. A dataset advertised as survey-grade after passing through a metre-accuracy datum transformation and a half-metre generalisation is misdescribed, and the misdescription is discovered by whoever builds on it.

Prerequisites

  • Per-step records carrying operation_accuracy_m, from Recording PROJ Pipeline Strings in Lineage.
  • A derivation edge table permitting ancestry traversal, per PostGIS Lineage Schema Design.
  • A recorded accuracy for original sources — survey specification, sensor characteristics, or a supplier’s stated figure.
  • Agreement on a combination rule, documented before any figure is published.

Where the Loss Comes From

Not every step in a chain degrades position, and knowing which do is what keeps the accumulation honest rather than pessimistic.

Which steps actually cost accuracy Datum transformation and generalisation degrade position; projection change within a datum and format conversion do not. STEP TYPE DEGRADES? WHY Datum transformation yes the operation has a stated accuracy Generalisation / simplify yes tolerance IS the displacement bound Projection change, same datum no mathematically exact, to float precision Format conversion usually no unless coordinate precision is truncated

The third row is the one that surprises people and is worth being clear about. Converting between two projections of the same datum is a closed-form calculation with no empirical component — the accuracy cost is the floating-point representation error, which is orders of magnitude below anything that matters for spatial data. Treating every reprojection as lossy inflates the accumulated figure and produces published accuracies that are needlessly pessimistic, which has its own cost in how the data gets used.

The second row is the one most often omitted. Simplification tolerance is chosen for cartographic reasons and is rarely thought of as an accuracy decision, but a Douglas–Peucker tolerance of half a metre is a guarantee that no vertex moved more than half a metre — which is exactly a positional accuracy statement, and usually the largest term in the whole chain.

The fourth row carries a caveat worth checking rather than assuming. Some format conversions do truncate coordinate precision — a text format written with fixed decimal places, a binary format with single-precision coordinates — and where that happens the truncation is a real displacement. Recording the coordinate precision of each output, and comparing it against the input, catches the case.

Choosing and Documenting a Combination Rule

Once per-step contributions exist, they have to be combined, and the choice of rule is a decision to make deliberately and record rather than to leave implicit in code.

Simple addition is conservative and defensible. It assumes the worst case — that every error contributes in the same direction — and produces an upper bound that will never be exceeded. For compliance purposes an upper bound is often exactly what is wanted, because a claim that will never be wrong is easier to defend than a tighter figure that occasionally is.

Root-sum-square is more realistic and requires an assumption. Combining independent errors in quadrature is standard practice and gives a figure closer to what would actually be measured, but it assumes the error sources are independent — which is reasonable for a survey error and a datum transformation error, and much less reasonable for two datum transformations sharing a grid.

Whichever you choose, state it on the record and apply it consistently. A published accuracy figure with no stated combination rule is uninterpretable, and two datasets whose figures were computed differently cannot be compared. Recording the rule alongside the result costs one field and makes the number mean something.

Dominant-term reporting is a third option worth knowing. Where one contribution exceeds the others by an order of magnitude — a half-metre generalisation on top of centimetre survey and datum errors — the combined figure is essentially the dominant term regardless of rule, and reporting it as such is both honest and easier to explain. Note the dominant step explicitly, since that is the one to change if a more accurate product is wanted.

Implementation Sketch

The computation is an ancestry traversal that collects contributions and applies the rule.

Walk the derivation chain upstream from the product, gathering every step’s accuracy contribution and the source’s stated accuracy at the terminals. Steps that do not degrade contribute zero and should be recorded as such rather than omitted — an explicit zero means “this step was assessed and costs nothing”, while a missing value means “nobody knows”, and the two must not be conflated in the arithmetic.

Handle multiple ancestry paths by taking the worst. A product derived from several sources has several chains, and its accuracy is bounded by the least accurate contributing path rather than by an average. Averaging paths produces a figure that no part of the data actually satisfies.

Return the contributing steps alongside the figure, not just the number. The list of terms is what makes the result auditable and what tells a steward where to intervene, and it is free — the traversal already collected it.

The worst path bounds the product A product derived from two chains inherits the accuracy of the worse chain, not the average of the two. survey source ± 0.02 m datum shift + 0.05 m → 0.07 m digitised source ± 2.0 m datum shift + 0.05 m → 2.05 m merged product ± 2.05 m — not ± 1.06 m Averaging the two paths would describe an accuracy that no feature in the product actually has.

Publishing the Figure

A computed accuracy is only useful once it reaches whoever consumes the data, and how it is stated determines whether it helps or misleads.

Three ways to publish the same figure A bare number, a bound with its combination rule, and a bound with the contributing terms enumerated. "Positional accuracy: 2.05 m" Uninterpretable — is that a bound, an RMSE, a specification? Computed how? "Upper bound 2.05 m, linear sum of per-step contributions" Defensible — a reader knows what the number claims and how it was reached "Upper bound 2.05 m — dominated by digitised source (2.0 m); datum shift 0.05 m; no generalisation applied" Auditable — and it tells the reader exactly what to improve first

The third form costs nothing extra because the traversal already produced the terms, and it changes what a consumer can do with the figure. Knowing the bound is dominated by a digitised source tells them that a more accurate product requires re-surveying rather than better processing, which is a conclusion no bare number supports.

State the unknown case as unknown rather than omitting the field. A dataset whose chain contains an unmeasured step has an accuracy that cannot be bounded, and publishing no figure at all invites a reader to assume the best. “Not determinable — one contributing step has no recorded accuracy” is a useful statement and an accurate one.

Verification

Test the accumulation against a hand-computed case before trusting it. Construct a fixture chain with known contributions, compute the expected figure by hand under the chosen rule, and assert the code agrees. That catches sign errors, unit confusion and the common mistake of treating a missing contribution as zero.

Test the missing-value path explicitly. A chain containing a step whose accuracy is unknown should produce an unknown result rather than a number, because silently dropping an unknown term produces a figure that is confidently too good. This is the single most important assertion on this page: an accuracy figure that quietly ignores what it does not know is worse than no figure.

Test the multi-path case with deliberately asymmetric branches, as in the diagram, and assert the worse path wins. Averaging is the natural thing to write and the wrong answer, so the test earns its place.

Making It a Standing Check Rather Than an Exercise

Computing an accuracy bound once, for a report, is worth doing. Computing it continuously is what turns it into a control, and the difference in effort is small once the traversal exists.

Run the accumulation nightly over every published product and store the result as a quality metric, using the pattern in Data Quality Metrics as Lineage Evidence. That gives a trend rather than a snapshot, and a trend is what surfaces the case that matters: a product whose accuracy bound worsened because an upstream step changed. Nobody looks for that; a stored series makes it visible.

Alert on two conditions specifically. First, any published product whose bound became unknown — that means a step lost its accuracy field, usually because instrumentation regressed. Second, any product whose bound exceeds the accuracy claimed in its published metadata, which is a live misstatement rather than a future risk.

The second alert is the one that justifies the whole exercise to a compliance audience. A catalogue record advertising sub-metre accuracy for a product whose computed bound is two metres is a defect with a clear owner and a clear fix, and it is entirely undetectable without this machinery. Most organisations discover such mismatches when an external user complains, which is considerably later and more expensive.

Keep the computed figure separate from the published claim rather than overwriting it. The claim is what was asserted at publication; the computed bound is what the lineage supports now. Storing both makes the discrepancy expressible, and a system that silently updates the claim to match the computation has removed the very signal that was worth having.

Gotchas & edge cases

  • PROJ reports -1 for unknown accuracy. Treated as a number it becomes a negative contribution that improves the total. Map it to null at capture time, and let null propagate to an unknown result.
  • Units are not always metres. An operation on a geographic CRS may report accuracy in degrees. Normalise at capture, and record the original unit so a conversion error is detectable later.
  • Raster accuracy has a floor at the cell size. No amount of transformation precision makes a 30-metre grid more accurate than its resolution, so the accumulated figure should be reported against that floor rather than below it.
  • Generalisation tolerance is a bound, not a typical value. Most vertices move far less than the tolerance. Reporting it as the contribution is conservative and correct for an upper bound; describing it as the expected displacement is not.
  • Stated source accuracy is often a specification, not a measurement. A survey specified to a tolerance may perform better or worse. Record which it is, since a chain built entirely on specifications gives a figure about the design rather than about the data.