KML to TRACES-ready EUDR GeoJSON — without rejections

Why TRACES rejects KML

The EU Information System expects a GeoJSON FeatureCollection in WGS84 (longitude, latitude). A KML export carries the right shapes but the wrong container, the wrong coordinate order in places, altitude values, and often unclosed polygons — each of which is a documented rejection cause.

DDSpass converts the KML to GeoJSON and repairs those issues: it closes rings, drops altitude, standardises the country code, and flags anything a person must review.

How to convert

Drop your .kml (or a KMZ unzipped to KML) into the tool. You get a clean, TRACES-ready GeoJSON plus a plain-language fix report you can send back to your supplier. Everything runs in your browser — the file is never uploaded.

KMZ is a zipped KML, not a second format

Google Earth’s Save Place As writes .kmz by default, so the file most suppliers actually send is a KMZ. It is not a different format: it is a zip archive holding doc.kml plus any icons or images the placemark referenced. TRACES accepts neither extension — only .geojson and .json can even be selected.

Drop the .kmz in as it is. DDSpass opens the archive, reads doc.kml (or any .kml inside it) and converts that — no manual unzipping. If the archive contains no KML at all, you get a clear block instead of a silently empty output file.

Folder trees come across too. Google Earth files organised one folder per village, cooperative or survey day are flattened into a single FeatureCollection, because that is the shape the import expects. Folder names are not part of the EUDR property set, so the producer and place have to live in each placemark’s properties, not in the folder structure.

What a Google Earth file carries that TRACES will not read

KML positions are written as longitude,latitude,altitude — three values, and Google Earth writes the third even when it is zero. EUDR geolocation is two-dimensional, so the altitude means nothing to the declaration. DDSpass drops it and keeps the longitude/latitude pair in WGS84 decimal degrees, which is the coordinate order GeoJSON uses.

Style URLs, icon and colour definitions and the HTML description bubble are simply ignored: TRACES reads an exact, case-sensitive set of property names. A placemark’s name is not ProductionPlace, so check that these four exist and are spelled precisely. DDSpass fills a missing production place with a numbered placeholder and flags a missing or non-ISO2 country for the supplier to answer.

• ProducerName — who produced the commodity
• ProducerCountry — country of production as an ISO2 code (UK is mapped to GB, EL to GR)
• ProductionPlace — the plot or place description
• Area — hectares, as a number, never as text

A drawn path is not a plot boundary

In Google Earth, Add › Polygon and Add › Path look almost identical on screen and export completely differently. A path becomes a KML <LineString>, and LineString and MultiLineString are not accepted geometry for EUDR — the permitted types are Point, MultiPoint, Polygon and MultiPolygon.

If the path was drawn closed, with the last vertex dropped on the first, it is a boundary in everything but its type and DDSpass promotes it to a Polygon. If it is open, it is blocked rather than closed for you: joining two loose ends would invent a boundary nobody walked. Re-draw it as a polygon and export again.

Real polygons need two further checks. Every ring must be closed — first position identical to the last, at least four positions — and a plot drawn with a cut-out for a lake, a building or an unplanted patch becomes an interior ring, the one geometry TRACES visibly refuses: Polygon with holes are not accepted by the system. DDSpass closes open rings and removes interior rings with a warning, so you can decide whether that excluded ground belongs in the declared hectares.

Questions

Does TRACES accept KML for EUDR?

No. The EU system only accepts GeoJSON for geolocation. KML and KMZ must be converted first.

Is my supplier data uploaded anywhere?

No. Conversion and validation happen entirely in your browser; the file never leaves your device.

Do I have to unzip a KMZ before converting it?

No. Drop the .kmz straight in — it is a zip containing doc.kml, and DDSpass opens it and reads the KML inside. Since KMZ is Google Earth's default save format, this is the normal case rather than the exception. If the archive holds no KML at all, you get a clear block instead of an empty file.

My KML coordinates have a third altitude value — is that a problem?

KML writes positions as longitude, latitude, altitude, and Google Earth includes the third value even when it is zero. EUDR geolocation is two-dimensional, so the altitude carries no meaning for the declaration. It is dropped during conversion and the remaining longitude/latitude pair is kept in WGS84 decimal degrees.

I drew the plot as a path in Google Earth instead of a polygon — will it work?

Not as it stands. A path exports as a LineString, which is not one of the accepted geometry types (Point, MultiPoint, Polygon, MultiPolygon). If your path is genuinely closed, DDSpass converts it into a Polygon; if it is open it is blocked, because closing it automatically would invent a boundary that was never surveyed.