Reproject the shapefile to WGS84 (EPSG:4326) and export it as GeoJSON. One command does it:
ogr2ogr -f GeoJSON plots.geojson plots.shp -t_srs EPSG:4326 -lco RFC7946=YESThat gives you a valid GeoJSON file. It does not give you a file the EUDR Information System will work with, and the distance between those two things is where the afternoon goes.
Six things survive the conversion and still have to be dealt with: ring winding direction, interior rings (holes), multipart records, coordinate precision, attribute field names that got truncated on the way into the .dbf, and the choice between a point and a polygon for each plot. This walks through all of them.
The rules below come from Regulation (EU) 2023/1115 (EUDR), the European Commission’s EUDR GeoJSON File Description v1.5 (linked from the EUDR Information System page), the EUDR Operator API Reference v1.0 for API V3, and the GeoJSON standard, IETF RFC 7946.
What the EUDR asks of a location
Article 2(28) of Regulation (EU) 2023/1115 (EUDR) defines geolocation as “the geographical location of a plot of land 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”.
Two numbers do most of the work: six decimal digits and four hectares.
Article 9(1)(d) of the same Regulation adds the cattle carve-out. For products that contain or were made using cattle, the geolocation refers to “all the establishments where the cattle were kept”. For everything else in Annex I, it refers to the plots of land.
Doing the conversion
A shapefile is not one file. It is a set: .shp holds the geometry, .dbf holds the attribute table, and .prj holds the coordinate reference system. You need all three. A .shp on its own will convert, but it will arrive with no attributes and no idea where on Earth it is.
With ogr2ogr (part of GDAL, free, on every GIS machine):
ogr2ogr -f GeoJSON plots.geojson plots.shp \
-t_srs EPSG:4326 \
-lco RFC7946=YES \
-lco COORDINATE_PRECISION=6-t_srs EPSG:4326 reprojects to WGS84. RFC7946=YES asks the driver for RFC 7946-conformant output rather than the older GeoJSON 2008 flavour, which is what fixes winding direction for you. COORDINATE_PRECISION=6 writes six decimals.
With QGIS, if you’d rather see the plots as you go: open the .shp, right-click the layer → Export → Save Features As, choose GeoJSON, set CRS to EPSG:4326 — WGS 84, and under Layer Options set RFC7946 to YES and COORDINATE_PRECISION to 6.
What you should end up with is a GeoJSON FeatureCollection holding at least one feature, with one production place per feature — that is what the Commission’s file description asks for, and it maps cleanly onto one shapefile record per plot.
Either way, look at the result on a map before you do anything else. Half the problems in this article are visible in two seconds on a map and invisible in a text editor.
The coordinate reference system is where it usually goes wrong
Shapefiles are very often in a projected CRS — a UTM zone, a national grid, something in metres. Open one of those and you’ll see coordinates like 512340.71, 8721903.44. Those are metres from a projection origin, not degrees.
The EUDR file description asks for WGS84 (EPSG:4326) in decimal degrees: longitude between −180 and 180, latitude between −90 and 90. A projected file that skips the reprojection step produces coordinates far outside those ranges, which at least fails loudly.
The quieter failure is a missing or wrong .prj. With no .prj, ogr2ogr has nothing to reproject from, so -t_srs silently does nothing and your metres get written into the GeoJSON as if they were degrees. Check the .prj exists before you convert. If it doesn’t, find out which CRS the file was surveyed in and pass it explicitly with -s_srs.
And then there’s the order. GeoJSON writes a position as [longitude, latitude]. People say it the other way round, and spreadsheets store it the other way round. A swap often stays inside the valid ranges: a plot at 46.8 N, 7.2 E is in Switzerland, and the same pair written backwards lands at 7.2 N, 46.8 E in central Somalia. Both are legal coordinates. Only a map tells you which one you have.
The six things the conversion leaves behind
| What the shapefile does | What EUDR GeoJSON needs | What to do about it |
|---|---|---|
| Exterior rings run clockwise — the reverse of the GeoJSON convention | RFC 7946 §3.1.6 puts exterior rings counterclockwise and holes clockwise | RFC7946=YES handles it. Reversing vertex order moves no vertex, so the boundary is identical |
| A polygon can carry interior rings (a donut with a clearing in the middle) | One contiguous production area per polygon; interior rings are not accepted | Removing a hole changes the declared area, so decide this yourself rather than letting a tool do it |
| One record can hold several disconnected parts | Type II files accept Point, MultiPoint, Polygon and MultiPolygon |
Export multipart records as MultiPolygon. LineString is not in either accepted list |
| Coordinates come out at full float precision | At least six decimal digits (Art. 2(28)); API V3 truncates to six under business rule GEO-CORD-10 | Truncate to six yourself and re-check the geometry, because truncation can merge nearby vertices |
.dbf attribute field names are truncated to 10 characters |
Type II files need ProducerCountry on every production place |
Rename the field after conversion. ProducerCountry is 15 characters and cannot have survived the .dbf |
| Some tools tolerate a boundary that crosses itself | Polygons must be non-self-intersecting | Fixable by decomposition, but that changes the shape of the plot — look at it on a map first |
The precision one is worth a second look, because it is the only item on this list that can turn a valid file into an invalid one after it passed. Six decimals is the floor set by Article 2(28) and, in practice, also the ceiling: API V3 cuts coordinates to six decimals. If two vertices of a small plot differ only in the seventh decimal, truncation merges them. A ring that loses vertices can end up with adjacent duplicates or zero area — valid before truncation, broken after it.
You can check all of this in a minute. Clearlane’s free EUDR GeoJSON validator and repair tool runs the cited rule profile in your browser, draws the plots on a map so a coordinate swap becomes obvious, applies the safe repairs and hands the corrected file back. It reads GeoJSON, KML, KMZ, CSV and TSV — it does not read shapefiles, so convert first, then check. The file never leaves your browser and there’s no account.
Point or polygon for each plot?
Over four hectares, non-cattle: you need a polygon with enough points to describe the perimeter. That is Article 2(28), quoted above.
The trap is on the other side. A Point feature with no Area property is not read as “size unknown” — the EUDR system treats it as four hectares. So an unsized point is a claim about the plot, not a blank. If the plot is actually bigger, the file says something untrue about it.
Where the Area property is present it has to be a positive number of hectares, and the current API V3 reference sets a minimum of 0.0001 hectares. Between 0.0001 and 0.1 hectares, be aware the current V3 reference and the older EUDR Validation Rules v1.3 disagree about the floor, so that band is worth a human look rather than a shrug.
The cattle exception is real and narrow. Article 9(1)(d) points cattle geolocation at the establishments where the animals were kept, so an establishment can be a single point whatever its size. It applies to cattle. It is not a general way out of drawing polygons.
If your shapefile already has a polygon for every plot, none of this bites — polygons are accepted for plots of four hectares or less too. The decision only matters when you’re converting a point layer.
The attribute table is the second half of the job
Geometry is the part people worry about. Attributes are the part that fails at upload.
For a Type II file, every production place needs ProducerCountry as a valid ISO 3166-1 alpha-2 code. Type I validates the code when it is supplied. And here’s the collision: the .dbf attribute table that ships inside a shapefile inherits dBASE’s 10-character limit on field names. A column you carefully called ProducerCountry in your GIS was written to disk as something like PRODUCER_C the moment you saved it as a shapefile.
So after conversion, open the GeoJSON and check the property names. Renaming them is a text edit, or in ogr2ogr an SQL select:
ogr2ogr -f GeoJSON plots.geojson plots.shp -t_srs EPSG:4326 -lco RFC7946=YES \
-sql "SELECT PRODUCER_C AS ProducerCountry, AREA_HA AS Area FROM plots"Check the country codes themselves while you’re there. A country name where a code belongs, or a three-letter code, both fail.
Type I or Type II — which am I making?
The Commission’s file description defines two variants, and two of the checks differ between them:
| Type I | Type II | |
|---|---|---|
| Geometry types accepted | Point, Polygon, MultiPolygon, GeometryCollection |
Point, MultiPoint, Polygon, MultiPolygon |
ProducerCountry |
Validated when supplied | Required on every production place |
If a converted file passes for you and fails for your supplier, or the other way round, a variant mismatch is the first thing to rule out.
How many plots fit in one declaration?
Relevant if you’re converting a shapefile of smallholder plots, which is where shapefiles usually come from.
The Commission’s May 2026 Operator API V3 reference documents these limits for an assembled declaration: 100 commodities per declaration, 1,000 producers per commodity, 10,000 producers per declaration, 500 scientific-name and common-name pairs per commodity, and 2,000 grouping references. The assembled declaration’s geolocation data is capped at 25,000,000 bytes — a plain decimal count, not the 1,048,576-byte “MB” some file managers display, so a file your computer calls 24.5 MB is already over.
Those constrain the declaration, not your GeoJSON file as such. But a few hundred detailed polygons will meet the geolocation ceiling before they meet anything else, and full-precision coordinates are exactly what inflates it — another reason to write six decimals rather than fifteen.
What a converted file still doesn’t prove
A file that passes every check above has passed format and data-quality checks. It has not been accepted by the EUDR Information System, and it is not a legal or compliance verdict.
It doesn’t prove the commodities are deforestation-free. It doesn’t prove they were produced in accordance with the relevant legislation of the country of production. It doesn’t complete your risk assessment or any mitigation that assessment calls for. Under Article 3 of Regulation (EU) 2023/1115 (EUDR), all three conditions have to hold — deforestation-free, produced in accordance with the relevant legislation, and covered by a due diligence statement or a simplified declaration. Getting the geometry right is the first step of one of them.
Satellite and remote-sensing evidence is in the same category. It can support a risk assessment and flag a change worth investigating. On its own it doesn’t prove goods are deforestation-free, legally produced, or correctly linked to your supply chain.
The operator stays responsible for the full due diligence assessment and for the statement submitted to the authority.
Convert, then check, then move on
The conversion is the easy half and it’s one command. The half that costs time is everything the command doesn’t know about EUDR: winding, holes, multipart records, six decimals, truncated field names, and whether each plot is entitled to be a point.
Drop the converted file into the free EUDR GeoJSON validator and repair tool and you’ll know in a minute which of those six are still open. Each blocking check also has its own page in the EUDR error catalogue, with the source it comes from and the fix.
Clearlane prepares and validates the data. It does not file to the EUDR Information System or any registry on your behalf.
This article is educational guidance, not legal advice or a compliance verdict.