We've written before that a forest-cover signal is a signal, not a verdict — that detection and interpretation are two different steps, and collapsing them is where automated systems get dangerous. That was an argument. This is a measurement.
We picked a coordinate inside what field verification confirms is real, continuous forest, queried it against JRC's GFC2020 V4 — one of the two major satellite-derived forest layers used across the EUDR compliance industry — and found that two adjacent 10-metre pixels, sitting in the middle of that forest, are classified as non-forest. Not at the edge. Not near a plantation. In the middle.
How we found it
We didn't go looking for an error. We were checking something else — whether JRC's GFC2020 forest-cover layer agrees with its companion product, GFT2020, which classifies forest by type (natural, primary, planted). Before trusting either dataset, we field-verified a set of coordinates by hand: comparing 2007, 2020 and current satellite imagery in Google Earth Pro, coordinate by coordinate, to confirm what was actually on the ground.
One location, in the eastern half of a cluster we were checking, showed dense, irregular, multi-height canopy in 2007 — the visual signature of natural forest, not plantation. The same location showed the same canopy structure in 2020, and again today. No plantation rows ever appeared. No clearing. Nothing changed.
We also checked a second location, roughly 1.6 km away, that we could independently confirm had been continuous forest for the same period, to use as a control. Querying GFC2020 V4 at that control point returned the correct value: forest. So the dataset works — it can tell forest from non-forest when the answer is unambiguous elsewhere nearby.
At our actual study location, it didn't. GFC2020 V4 returned non-forest.
Pinning it down to the pixel
A single wrong query result could be a coordinate-rounding mistake, a coastline-style edge artefact, or noise. So we ran a transect: a line of sample points spaced roughly 5 metres apart, walking away from the first "wrong" point toward the control point, recording both the raw classification value and the exact pixel row and column it fell in.
| Distance along transect | Pixel (col, row) | GFC2020 V4 value |
|---|---|---|
| 0 – 14 m | (115, 47) | 0 — non-forest |
| 19 m | (116, 48) | 0 — non-forest |
| 24 m onward | (117, 49) and beyond | 1 — forest |
Two pixels. Not a blur, not a gradient, not a scatter of noisy values back and forth — one clean, single step from wrong to right. Everything on either side of those two pixels, including our control point 1.6 km away, classifies correctly.
You cannot see this by eye
We tried. We zoomed in on this exact location as far as Google Earth Pro's imagery will resolve — down to a roughly 12-metre field of view, close to the size of the pixels themselves.
At that range, the source imagery simply runs out of resolution — both frames dissolve into a soft blur, with no usable detail in either direction. There is no visual seam to find. The error exists only in the classified data, not in anything a human reviewer, however careful, could ever have caught by looking at a picture.
How common is this?
One confirmed error tells you an error is possible. It doesn't tell you how often it happens. So we measured that separately, and honestly, that measurement doesn't answer the question you'd want it to.
Using PostGIS, we grouped the raw classified pixels in two separate ~207 km² sample areas into connected regions of matching value, then counted how many of those regions were three pixels (≤243 m²) or smaller — small enough to be the kind of isolated anomaly we'd just field-verified, rather than a real, mapped feature like a genuine forest edge or a small clearing.
| Sample area | Total regions | ≤3-pixel regions | Share |
|---|---|---|---|
| Area 1 (~207 km²) | 242 | 121 | 50.0% |
| Area 2 (~207 km², non-adjacent) | 1,017 | 296 | 29.1% |
Between roughly 29% and 50% of the classified regions in our two sample areas were three pixels or smaller. That is not a precise error rate — it's a measure of how much fine-grained speckle exists in the classification generally, and it varies a lot by landscape. We field-verified exactly one of these small regions as a genuine misclassification. We have not verified the rest, and we're not claiming they all are.
That distinction matters, and we want to be precise about it rather than let a good number do more work than it's earned. A small, isolated region in this data could be a real, small feature on the ground — a narrow gap in the canopy, a single fallen tree, a few metres of natural forest edge that just happens to fall inside one pixel. Or it could be exactly what we found: a flat-out wrong classification sitting in the middle of unbroken forest. Without field verification, you cannot tell the two apart from the raw data alone. What we can say is that this kind of small, isolated disagreement is not rare — it shows up in roughly a third to a half of all classified regions in the areas we checked — and that at least one of them, checked by hand against thirteen years of imagery, was unambiguously wrong.
Worth noting: JRC's own technical report on GFC2020 V4's methodology and accuracy hasn't been published yet — it's expected in December 2026, and the "known issues" list for this version is still empty on JRC's site. Everything we found here is an independent field check of a dataset that hasn't had its own official accuracy assessment yet.
What this means, practically
This is why we keep separating detection from interpretation. A binary forest/non-forest classification, run at 10-metre resolution across an entire country, is going to contain small, isolated errors — not occasionally, but structurally, as a normal feature of the method. That's not a flaw specific to GFC2020 V4; it's what happens when you force a continuous, messy, real landscape into a grid of independent yes/no decisions. Any dataset built this way will have some number of pixels like the two we found: technically wrong, invisible to a human reviewer, and indistinguishable from a correct pixel unless someone goes and checks the ground.
For anyone using a satellite forest layer as an EUDR risk signal — including us — the practical conclusion isn't "don't trust the data." It's "don't trust a single pixel." A flagged coordinate that sits alone, surrounded by pixels that disagree with it, deserves a different level of scrutiny than a flagged region that's large, contiguous, and consistent across independent products. One is a pattern. The other might just be two pixels, wrong, exactly like the two we found.
We don't build risk models on a single pixel, and this is a concrete reason why. A supplier's plot getting flagged because of exactly this kind of isolated, one-off classification anomaly — not a real land-use change, just structural noise in a 10-metre grid — is the scenario our two-axis discipline exists to prevent. Geometry is a fact we can adjudicate. A satellite forest signal is not, and this is what that looks like up close: two real pixels, verifiably wrong, inside forest that never moved.
Metoda: terensko preverjanje z Google Earth Pro (2007 / 2020 / danes), poizvedbe PostGIS ST_Value in ST_WorldToRasterCoord za piksel-natančno lokacijo napake, ST_DumpAsPolygons za štetje povezanih regij pri kvantifikaciji. Vir podatkov: JRC GFC2020 V4 (Global Forest Cover), forobs.jrc.ec.europa.eu/GFC. Tehnično poročilo o metodologiji in natančnosti za V4 še ni objavljeno (pričakovano december 2026).
← Back to Blog