File teardown: the Commission's own example files

File teardown takes a real geolocation file apart: what the Information System would do with it, what the checker finds, and what to learn from it. The first file had to be the one everybody copies: the examples in the specification itself.

The specification has three: a single Feature in its definitions, and two complete files in its examples section, one of each variant (GeoJSON File Description, Examples).

1. The single Feature: an error in the example

The definitions illustrate a Feature like this (GeoJSON File Description, Definitions):

{ "type": "Feature", "geometry": { "type": "Point", "coordinates": [[-105.029865, 40.622831]] } }

A Point has one position, [lon, lat]. This one has a list of positions: an extra pair of brackets. Version 1.5 of the same specification lists exactly this as an error: "The coordinates for points should be array and not array of arrays" (GeoJSON File Description v1.5, §6.14). In version 1.5 the example was also missing its final closing brace (GeoJSON File Description v1.5, §3); the current online version has the brace back, but not the fix to the brackets.

The checker reports Point coordinates are wrapped in an extra pair of brackets (STRU-005) and offers to unwrap it. Anyone who built a file by copying this example, and a surprising number did, has the same problem.

2. The Type I example: two farms, no problems

Two polygons in Brazil, FAZENDA TABOAO I and II, with ProductionPlace, Area and ProducerCountry. The checker finds nothing wrong. Three things are still worth noticing.

It looks less precise than it is. Of the file's 174 coordinates, 18 have fewer than six decimals, -49.00683, -22.73526. They are not rounded: JSON drops trailing zeros, so -49.006830 is written -49.00683. A checker that counted decimals per coordinate would warn about the Commission's own file. Ours judges each plot by its most precise coordinate, which is how we caught the problem in the first place; see why six decimals is harder than it looks.

The declared areas are a little larger than the shapes. 23.72 ha declared against 23.61 ha measured on the WGS 84 ellipsoid, and 2.39 against 2.38, about half a percent. Well within any sensible tolerance, and a useful reminder that "the area" depends on how it was measured.

It uses polygons for both, though the second is under four hectares and could have been a point (Regulation (EU) 2023/1115, Art. 2(28)). That is allowed, and better evidence.

3. The Type II example: grouped by a property it does not have

Four "Cocoa Farm" polygons in Angola and Cameroon. The specification says a Type II file "contains multiple producers grouped by the "ProducerName" and "ProducerCountry"" (GeoJSON File Description, File Variants Description, Type II), but none of the four features has a ProducerName. ProducerName is optional, so the file is valid; it just does not show the grouping it is there to illustrate.

The farms are also very large for cocoa: 6,904 to 20,687 hectares measured. With the commodity set to cocoa, the checker's own plausibility check, our rule, not the Information System's, flags all four This plot is an unusual size for the commodity (PLAUS-003). Illustrative examples are allowed to be illustrative. Real files with numbers like these usually have an Area in square metres.

What to take away

• Do not copy the single-Feature example. Use [lon, lat] for a Point.
• Trailing zeros are not lost precision; missing digits are.
• Give your Type II file a ProducerName on every feature, even though it is optional: it is what the grouping is for.