EUDR-Geolokalisierung für Rinder — TRACES-fertig, ohne Ablehnung

Jeder Standort, geolokalisiert

Rückverfolgbarkeit bei Rindern bedeutet viele Produktionsorte — Betriebe und Weiden — je Erklärung. DDSpass prüft jede Fläche, vereinheitlicht Ländercodes und kontrolliert, ob jeder Standort im angegebenen Land und an Land liegt, damit eine vertauschte Koordinate keinen Betrieb ins Meer setzt.

Warum die 4-Hektar-Regel für Rinder nicht gilt

Die Vorgabe „über 4 ha muss ein Polygon sein“ stammt aus der Definition einer Landfläche in Art. 2(28) und betrifft die auf Land erzeugten Rohstoffe — nicht Rinder. Eine Rinder-Erklärung trägt die Geolokalisierung jedes Standorts, an dem die Tiere gehalten wurden; die Schwelle entscheidet hier also nicht über die Geometrie wie bei einer Kaffee- oder Kakaofläche. Senden Sie einen Punkt je Standort oder eine kartierte Grenze, wenn Sie eine haben — DDSpass prüft beides, repariert die Geometrie und exportiert eine kombinierte Datei oder eine je Erzeuger. Alles läuft im Browser — nichts wird hochgeladen.

Mehrere Parzellen, ein Betrieb

Ein Rinderbetrieb ist selten eine einzige Form. Koppeln, zugepachtete Blöcke und Saisonweiden liegen auseinander, und die Herde wechselt zwischen ihnen. Polygon und MultiPolygon sind beide zulässig, ein auf mehrere Parzellen verteilter Betrieb kann also als ein Feature oder als mehrere reisen — entscheidend ist, dass jedes die Eigenschaften trägt, die es identifizieren.

Diese Schlüssel sind eine feste Liste, bei der Groß- und Kleinschreibung zählt: ProducerName, ProducerCountry, ProductionPlace, Area. Eine Datei, die productionplace schreibt, verliert den Wert stillschweigend, und ein Tippfehler in einem strukturellen Schlüssel wie geomerty kann das Einlesen ganz verhindern. DDSpass repariert knapp danebenliegende Schlüssel und listet jede Umbenennung auf.

LineString und MultiLineString sind keine zulässige Geometrie. Eine als offener Track erfasste Koppel — in GPS- und Betriebskartierungs-Exporten Routine — muss zuerst zu einem geschlossenen Ring werden. DDSpass schließt tatsächlich geschlossene Tracks und blockiert offene, statt eine Grenze zu erfinden, die niemand abgefahren hat.

Ländercodes in einer Datei mit mehreren Lieferanten

Rinder-Erklärungen führen oft Standorte mehrerer Lieferanten, und jedes Feature braucht sein eigenes ProducerCountry als gültigen ISO2-Code. DDSpass prüft jeden Code gegen die vollständige ISO2-Liste und bildet die beiden häufigen Sonderfälle ab — UK auf GB, EL auf GR.

Woher das Land beim Import kommt, sollten Sie wissen, bevor Sie die Datei verdächtigen. Der oberste Import-Button liest ProducerCountry aus dem GeoJSON; Add Production Place → Import GeoJSON tut das nicht. Bleibt das Feld leer, prüfen Sie zuerst, welchen Button Sie benutzt haben — hier ist es erklärt.

DDSpass prüft außerdem jeden Standort gegen die tatsächlichen Grenzen des für ihn angegebenen Landes, sodass ein Betrieb, dessen Koordinaten jenseits der Grenze im Nachbarland liegen, am Bildschirm auffällt und nicht erst nach der Einreichung.

Wenn ein Betrieb im Meer landet

Der häufigste Totalschaden in einer Koordinatenliste sind vertauschte Breiten- und Längengrade. GeoJSON-Positionen stehen als [Längengrad, Breitengrad] in WGS84-Dezimalgrad; liefert eine Tabelle sie in der Lesereihenfolge, setzt das eine Ranch im Binnenland ins offene Meer — und TRACES importiert das kommentarlos. Prüfen Sie für jeden Standort:

• Die Position liegt an Land, nicht auf offenem Wasser.
• Die Parzelle liegt innerhalb des für sie angegebenen ProducerCountry.
• Die Koordinaten sind Dezimalgrad in der Reihenfolge [Längengrad, Breitengrad] — keine Meter aus einem projizierten nationalen Gitter.
• Ringe sind geschlossen, haben mindestens vier Positionen und überschneiden sich nicht selbst.
• Area ist eine Zahl, kein Text — "Area": "3" wird als 0 Hektar gelesen.

Nichts davon wird später abgefangen. TRACES weist sichtbar genau zwei Dinge zurück: ungültige JSON-Syntax und ein Polygon mit inneren Ringen, beantwortet mit Polygon with holes are not accepted by the system. Alles andere inhaltlich Falsche wird stillschweigend akzeptiert — ein sauberer Importbildschirm ist also kein Beleg für eine korrekte Erklärung.

Fragen

Welche Geolokalisierung verlangt die EUDR für Rinder?

Den Standort jedes Produktionsorts — der Betriebe und Weiden, an denen die Rinder gehalten wurden. Die Regel „über 4 ha muss ein Polygon sein“ aus Art. 2(28) gilt für Landflächen der auf Land erzeugten Rohstoffe, nicht für Rinderstandorte.

Unsere Betriebsgrenzen kommen als Shapefile aus dem nationalen Kataster. Kann ich das an TRACES geben?

Nein. TRACES akzeptiert nur .geojson und .json — ein Shapefile, KML oder Excel lässt sich in seiner Dateiauswahl gar nicht erst anklicken. Legen Sie das gezippte Shapefile stattdessen in DDSpass ab: Die .prj wird gelesen, die Geometrie nach WGS84 reprojiziert, und Sie erhalten GeoJSON zurück. Siehe Shapefile zu EUDR-GeoJSON.

Ein Betrieb hat fünf getrennte Koppeln. Ein Feature oder fünf?

Beides geht, denn Polygon und MultiPolygon sind zulässig. Ein MultiPolygon hält den Betrieb als einen Produktionsort zusammen; fünf Features erlauben es, jede Parzelle einzeln in ProductionPlace zu benennen. Wofür Sie sich auch entscheiden: Schreiben Sie ProducerName und ProducerCountry überall identisch — nach diesem Paar gruppiert der Typ-I-Export.

TRACES hat unsere Rinderdatei fehlerfrei importiert. Heißt das, die Erklärung stimmt?

Nicht zwangsläufig. Ein sauberer Import sagt nur, dass das JSON lesbar war und kein Polygon ein Loch hatte. Über die Koordinatenreihenfolge, darüber, ob ein Standort an Land liegt, oder darüber, ob zwei Betriebe dieselbe Fläche abdecken, sagt er nichts. Eine als Text geschriebene Fläche importiert anstandslos und zählt als 0 Hektar.