Warum lehnt das EUDR-Portal meine Shapefile-Koordinaten ab?

Das EUDR-DDS-Portal TRACES NT akzeptiert keine Shapefile-Dateien (.shp, .dbf, .prj) direkt. Die einzigen unterstützten Geodaten-Formate sind GeoJSON und KML — beide müssen im WGS84-Koordinatensystem (EPSG:4326) vorliegen. Shapefiles sind dagegen oft in lokalen oder europäischen Projektionssystemen gespeichert: UTM-Zonen (z. B. EPSG:32632 für Mitteleuropa), Gauss-Krüger oder ETRS89-LAEA (EU-Statistikprojektion EPSG:3035).

Der häufigste Fehler: Ein Lieferant sendet Parzellendaten als Shapefile — oft als Export aus einem Agrarmanagementsystem oder einem nationalen Katasterservice. Das EUDR-Compliance-Team versucht den Upload und erhält entweder eine direkte Fehlermeldung ("Format nicht unterstützt") oder — nach manueller Konversion — eine Ablehnung wegen falscher Koordinatenwerte.

Die unsichtbare Falle: Viele einfache Konversions-Tools kopieren die Koordinaten aus dem Shapefile ohne das Projektionssystem zu transformieren. Eine Parzelle in ETRS89-UTM Zone 32N hat Koordinaten wie (500000, 5400000) — in Metern. Ohne Umrechnung in Dezimalgrad erscheinen diese Koordinaten als Punkt im Atlantik oder im falschen Kontinent.

Möbelhersteller und Holzimporteure arbeiten oft mit Lieferanten, die ihrerseits hunderte oder tausende Einzelparzellen von Kleinproduzenten aggregieren. Ein Shapefile mit 50.000 Forstparzellen ist im EUDR-Kontext keine Ausnahme — es ist die Realität bei größeren Holzlieferketten aus Rumänien, Polen oder dem Baltikum.

Das Problem für JavaScript-basierte Verarbeitungspipelines: Wenn ein Node.js-Prozess 50.000 Polygone aus einem Shapefile lädt und GEOS-basierte Polygon-Intersection-Berechnungen durchführt (um zu prüfen welche Parzellen mit JRC-Walddaten-Kacheln überlappen), entsteht ein Zwischenstatus von 4 GB und mehr im V8-Heap. Die Garbage-Collector-Pause kann über 45 Sekunden betragen — und endet häufig mit einem OOM-Kill (Error: JavaScript heap out of memory).

Die technische Ursache ist fundamental: GEOS-Polygon-Intersection ist eine quadratisch skalierende Operation. Bibliotheken wie turf.js oder shapefile.js sind für interaktive Kartenanwendungen mit einigen hundert Geometrien ausgelegt — nicht für Batch-Verarbeitung von Zehntausenden Forstparzellen gegen Satellitendaten-Kacheln. Für diesen Anwendungsfall braucht es nativen Code mit explizitem Speichermanagement.

Die Situation ist akut: Ein Schiff mit Holzlieferungen liegt im Hamburger Hafen. Die Import-Genehmigung erlischt um 17:00 Uhr wenn keine gültige DDS eingereicht ist. Das Shapefile des Lieferanten lässt sich nicht hochladen, die Konversion schlägt fehl, der Node.js-Server bricht ab.

Sofortmaßnahmen in dieser Reihenfolge: Erstens — Shapefile-Prüfung mit QGIS (kostenlos). QGIS öffnet das Shapefile und zeigt das Projektionssystem an. Dann: Rechtsklick auf Layer → Exportieren → Als GeoJSON, Koordinatensystem EPSG:4326. Das ist die schnellste Möglichkeit für eine einmalige Konversion. Zweitens — Falls QGIS nicht verfügbar: GDAL via ogr2ogr: ogr2ogr -f GeoJSON -t_srs EPSG:4326 out.geojson in.shp. Drittens — Das resultierende GeoJSON muss auf Plausibilität geprüft werden: Liegen die Koordinaten im erwarteten Land? Ein Geojson.io-Check genügt.

Wenn die Frist nicht einzuhalten ist: TRACES NT Help Desk kontaktieren. Dokumentieren Sie den technischen Fehler schriftlich mit Timestamp und Fehlermeldung. In nachgewiesenen technischen Ausnahmefällen können Behörden zeitlich begrenzte Ausnahmen gewähren — aber nur mit proaktiver Kommunikation vor Ablauf der Frist.