EU Deforestation Regulation · geolocation data

An EUDR GeoJSON file is the geolocation part of a due diligence statement: the plots of land where the wood, coffee, cocoa, rubber, soy, palm oil or cattle came from, as points and polygons that the EU Information System (TRACES) can read. Suppliers rarely send that. They send Excel sheets with swapped columns, GPS readings in degrees-minutes-seconds, UTM coordinates from a surveyor, polygons that are not closed. I turn those lists into a clean EUDR GeoJSON file, check it against the EU’s published file rules and the geolocation definition in the Regulation, and send you a written list of everything I had to change or could not confirm.

This page is for you if one of these describes your situation:

• You export wood, furniture, paper, rubber, coffee, cocoa, soy, palm-oil products or cattle products from Türkiye, and your EU customer asks for “the geolocation of the plots” or “an EUDR GeoJSON”.
• You are an EU importer buying from Turkish suppliers, and the coordinate lists you receive do not load in TRACES, or load and land in the sea.
• You hold a spreadsheet from a forestry office, cooperative or surveyor and do not know whether it is in the right coordinate system.
• TRACES rejected your upload with an error about geometry, and nobody can tell you which plot is the problem.

Open your GeoJSON file in a plain text editor (Notepad, TextEdit) and look at the first coordinate pair.

• The first number must be the longitude, the second the latitude. For a plot in Türkiye, the first number lies roughly between 26 and 45, the second between 36 and 42. If they are the other way round, the plot is in the wrong country.
• Numbers like 641073.0, 4383673.6 are metres in a projected system (UTM), not degrees. The file must be converted.
• Count the digits after the decimal point: the Regulation asks for at least six.
• In each polygon, the last coordinate pair must repeat the first.
• Search for "Area": the value must be a number without quotes and with a decimal point, e.g. "Area": 2.5, not "Area": "2,5".

Passing these five checks does not make the file valid. Crossing edges, duplicate plots and the datum of the original survey are not visible this way.

Read on for the technical detail. Below: what the EU file rules require, a measured worked example with a deliberately messy supplier list, downloadable files and reports, and the current application dates. To skip ahead, send one supplier list and I will tell you what is wrong with it.

An EUDR geolocation file is a GeoJSON FeatureCollection in WGS 84 with one point or polygon per plot of land, using at least six decimal places. Plots of more than four hectares (for commodities other than cattle) must be polygons. The rest is file hygiene that the EU system checks strictly.

Regulation (EU) 2023/1115 defines geolocation as the location of a plot “described by means of latitude and longitude coordinates corresponding to at least one latitude and one longitude point and using at least six decimal digits; for plots of land of more than four hectares used for the production of the relevant commodities other than cattle, this shall be provided using polygons with sufficient latitude and longitude points to describe the perimeter of each plot of land” (consolidated text, EUR-Lex).

The Commission publishes the technical rules in the EUDR GeoJSON File Description (the page I used says “Updated 17 August 2026”). The points that matter in practice:

• Coordinates in WGS 84 (EPSG:4326), decimal degrees, in the order longitude, latitude. Other coordinate systems must be converted first.
• Accepted geometries: Point, MultiPoint, Polygon, MultiPolygon. LineString is rejected.
• A polygon has at least four coordinate pairs and is closed. Polygons with holes and shapes with crossing lines “are not supported and will not be processed”.
• The system truncates to six decimals. Sending more is useless and can produce invalid shapes when two vertices become identical.
• Optional properties with exact spelling: ProducerName, ProducerCountry (ISO two-letter code, e.g. TR), ProductionPlace (recommended), Area (hectares, as a number). A point without Area is treated as 4 ha.
• File size limit: 25 MB per due diligence statement, all GeoJSON files together.

Almost never in the shape of the plot. It breaks in the handover: a column labelled “Enlem” (latitude) holding longitudes, a GPS device set to degrees-minutes-seconds, a surveyor’s file in UTM zone 35 or 36, a spreadsheet that saves 39,580430 with a decimal comma, a boundary typed with two corners in the wrong order. Each of these produces a file that looks fine in Excel and fails, or worse, passes and points to the wrong place.

Older Turkish survey data is often in the ED50 datum rather than WGS 84. The numbers look the same; the position does not. No file validator can see which datum a surveyor used. The worked example below measures how large that difference is for one plot.

Here is a measured worked example on fictional data, not a client job. I built a supplier list for nine timber plots with the errors I expect in real lists, converted it the quick way, validated it, corrected it, and validated it again.

The supplier “Örnek Orman Ürünleri A.Ş.”, the plot IDs and every coordinate are invented. They were generated by a script for this example and are placed near Dursunbey (Balıkesir), a real forestry area, but they are not real parcels. Every file says “FICTIONAL EXAMPLE”. The rules come from the EU GeoJSON File Description (updated 17 August 2026) and Art. 2(28) of the Regulation. The validator and the fix script are my own Python code (shapely 2.1.2, pyproj 3.7.2 with PROJ 9.5.1) and are included in the download.

The supplier list: 47 coordinate rows for 9 plots, semicolon-separated, decimal commas. Built-in problems: P01 latitude and longitude swapped, P02 in degrees-minutes-seconds, P03 in UTM metres, P04 unclosed, P05 a “bow-tie” (two corners swapped), P06 a 9 ha plot given as one point, P07 a point with one decimal, a duplicate of P04, and P09 with ten decimals where two corners merge at six.

The quick conversion produced a 2,844-byte GeoJSON with 9 features. My validator’s verdict: FAIL — 45 errors, 14 warnings, 2 notes.

The swapped plot P01 is a valid polygon in the wrong place: it computes to 11.5666 ha at latitude 28.6° instead of 10.1771 ha where it belongs. Part of the decimal-place errors come from the quick conversion itself, which drops trailing zeros (39.580430 becomes 39.58043).

The fix script wrote 21 entries to a change log. In summary: P01 swap detected and corrected; P02 converted from DMS; P03 converted from UTM zone 35N (EPSG:32635) to WGS 84; all rings closed and oriented counter-clockwise; P05 corners re-ordered; the duplicate removed; the merged vertex in P09 removed; P06 and P07 replaced by the (equally fictional) re-survey the supplier returned; every coordinate written with exactly six decimals; correct property names and numeric areas. Seven entries are marked “supplier must confirm”: the UTM datum, the P05 corner order, and the declared areas of P02, P04 (and its duplicate), P05 and P09, which differ from the measured boundary by more than 10 %.

The corrected file has 8 features (7 polygons, 1 point) and 3,105 bytes. Verdict: PASS — 0 errors, 0 warnings. The GeoJSON library’s own check and the shapely geometry check also report all 8 geometries valid.

Areas are computed in a Lambert azimuthal equal-area projection centred on each plot and cross-checked with the geodesic area on the WGS 84 ellipsoid; both agree to four decimals. IoU (intersection over union) compares each corrected polygon with the invented “true” shape; 1 would be identical. P02 is lowest because the supplier’s GPS gave seconds to one decimal. A rule self-test with deliberately broken files (line instead of polygon, hole, clockwise ring, straight line, three-point ring) triggered the expected rule in 5 of 5 cases.

A clean report says the file follows the published rules. It says nothing about whether the coordinates describe the right land.

The ZIP contains the fictional supplier list and re-survey, the naive and corrected GeoJSON files, the validator, the conversion and fix scripts, the change log, both validator reports (text and JSON) and a machine-readable summary of all measured numbers.

You can open both GeoJSON files in any GIS program (QGIS, for example) or in a text editor. Run the validator yourself with python3 eudr-geojson-validator.py yourfile.geojson.

You receive a GeoJSON file that passes the published EU file rules, the report that shows it, and a plain list of what still needs your supplier.

• One EUDR-ready GeoJSON FeatureCollection per statement or per supplier, as you prefer, with ProductionPlace, ProducerName, ProducerCountry and numeric Area.
• The validator report for every file, before and after.
• A change log per plot: what was converted, corrected, removed or replaced.
• A table of measured areas and vertex counts, with the plots where declared and measured area differ.
• A list of open questions for the supplier (datum, boundary, re-survey of points over 4 ha), written so you can forward it.
• On request, a map of all plots for your own check before upload.

You send one real supplier list first; the price is fixed before any work starts.

1. Send one supplier list. The spreadsheet, KML or GeoJSON as you received it, plus the commodity. I tell you what is wrong with it and what only the supplier can answer.
2. You receive a scope and a fixed price for the set of lists, before anything starts.
3. I do the work. You receive preview files marked as drafts, with the validator report and the change log, to check or to load in the TRACES acceptance (test) environment.
4. Your approval releases the final files, the reports and the question list for your suppliers.

I price each job after I have seen the material. Twenty clean GPS points from one cooperative are a different job from four hundred polygons in three coordinate systems with duplicates across suppliers. You get a fixed price for the set before any work starts — no hourly meter.

The EUDR applies from 30 December 2026 for large and medium operators, and from 30 June 2027 for most micro and small operators. Geolocation is required in every due diligence statement. Whether and how the rules apply to your company is a question for your legal adviser; this page covers the file.

• Application dates. The European Commission lists: large and medium operators 30 December 2026; micro and small operators 30 June 2027; micro and small operators already covered by the EU Timber Regulation 30 December 2026. The dates were set by the amending Regulation (EU) 2025/2650. Checked on 28 September 2026 — the dates have been moved twice before, so check again before you rely on them.
• Product scope changed in 2026. According to the Commission’s announcement of 13 July 2026, the Delegated Act on product scope removes, among others, cattle hides, skins and leather, articles of vulcanised rubber and re-treaded tyres, and adds soluble coffee, certain palm-oil derivatives and frozen cattle tongues; newly added products are covered from 30 December 2027. Whether your HS code is in scope is for your customs broker or adviser to confirm.
• The Information System is open. The Commission reports that it reopened at the end of June 2026 with simplified declarations for micro and small primary operators. Bulk geolocation upload uses the GeoJSON format described above.
• For Turkish exporters. The legal obligation falls on the operator placing the product on the EU market, usually your EU customer. But the geolocation has to come from you, and customers are asking for it now, before their first statements are due.

The operator that places the product on the EU market or exports it from the EU submits the statement, which for goods from Türkiye is usually the EU importer. As a Turkish supplier you provide the information they need, above all the geolocation of the plots. Whether your company is an operator in a particular setup is a question for your legal adviser.

Under Art. 2(28), plots of more than four hectares need a polygon, except for cattle. Plots of four hectares or less may be given as a single point with six decimals. A point without an Area value is treated by the system as 4 ha.

Yes. Both are converted to WGS 84 decimal degrees, as in plots P02 and P03 of the worked example. For UTM I need the zone and the datum; if the datum is unknown, I state it as an open question, because WGS 84 and ED50 differed by 191.6 m in the example.

No. The file only says where the plots are. Whether they were deforested after 31 December 2020 and whether production was legal is part of the operator’s due diligence and risk assessment, done with satellite data, documents and legal advice.

No. The due diligence statement is submitted by the operator or its authorised representative. I deliver the file and the report; you or your customer upload it. You can test the upload in the TRACES acceptance environment first.

No. My validator implements the rules the Commission publishes, in the version named in the report. The EU system can apply additional checks or change its rules. The report shows exactly what was checked.

For cattle, the four-hectare polygon rule of Art. 2(28) does not apply, so points with six decimals are enough. Leather is a separate question: the Commission announced in July 2026 that cattle hides, skins and leather are being removed from the product scope. Ask your customs broker whether your products are still covered.

• Multilingual PDF accessibility (PDF/UA)
• GS1 Digital Link QR codes
• ZUGFeRD and XRechnung e-invoices
• Accessible EPUB
• Accessible Word and PowerPoint
• Alt text writing
• C2PA Content Credentials

One list — the one that did not load, or the one you are about to send to your EU customer. You get back a straight account of what is wrong with it, and what only your supplier can answer.

Ali Karabüyük · Tekirdağ, Türkiye · working remotely with clients worldwide · document and image production since 2004, professional practice since 2008.