Géolocalisation du bétail EUDR — prête pour TRACES, sans rejets

Chaque établissement, géolocalisé

La traçabilité du bétail implique de nombreux lieux de production — exploitations et pâturages — par déclaration. DDSpass valide chaque parcelle, normalise les codes pays et vérifie que chaque établissement se trouve dans le pays déclaré et sur la terre ferme, pour qu'une coordonnée inversée ne place pas une exploitation dans l'océan.

Pourquoi la règle des 4 hectares ne s'applique pas au bétail

L'exigence « au-delà de 4 ha, il faut un polygone » découle de la définition d'une parcelle à l'Art. 2(28), qui vise les matières premières cultivées sur terre — pas le bétail. Une déclaration bétail porte la géolocalisation de chaque établissement où les animaux ont été détenus ; ce seuil ne détermine donc pas la géométrie comme il le fait pour une parcelle de café ou de cacao. Envoyez un point par établissement, ou une limite cartographiée si vous en avez une — DDSpass valide les deux, répare la géométrie et exporte un fichier combiné ou un par producteur. Tout s'exécute dans votre navigateur — rien n'est envoyé.

Plusieurs parcelles, un seul établissement

Un établissement d'élevage est rarement d'un seul tenant. Parcs, blocs loués et pâturages saisonniers sont séparés, et le troupeau se déplace entre eux. Polygon et MultiPolygon sont tous deux acceptés : une exploitation répartie sur plusieurs parcelles peut donc voyager comme une seule entité ou comme plusieurs — l'essentiel est que chacune porte les propriétés qui l'identifient.

Ces clés forment une liste blanche sensible à la casse : ProducerName, ProducerCountry, ProductionPlace, Area. Un fichier qui écrit productionplace perd la valeur en silence, et une faute de frappe dans une clé structurelle comme geomerty peut casser purement et simplement l'analyse. DDSpass répare les clés quasi correctes et liste chaque renommage.

LineString et MultiLineString ne sont pas des géométries acceptées. Un parc tracé comme une piste ouverte — courant dans les exports GPS et de cartographie agricole — doit d'abord devenir un anneau fermé. DDSpass ferme les tracés réellement fermés et bloque les tracés ouverts plutôt que d'inventer une limite.

Les codes pays dans un fichier multi-fournisseurs

Les déclarations bétail listent souvent des établissements de plusieurs fournisseurs, et chaque entité a besoin de son propre ProducerCountry sous forme de code ISO2 valide. DDSpass vérifie chacun d'eux contre la liste ISO2 complète et convertit les deux codes non standard les plus fréquents — UK en GB, EL en GR.

D'où vient le pays au moment de l'import mérite d'être connu avant d'accuser le fichier. Le bouton Import de premier niveau lit ProducerCountry dans le GeoJSON ; Add production place → Import GeoJSON ne le fait pas. Si le champ arrive vide, vérifiez quel bouton vous avez utilisé — explication ici.

DDSpass teste également chaque établissement contre les frontières réelles du pays déclaré pour lui : une exploitation dont les coordonnées passent de l'autre côté de la ligne, chez un voisin, est signalée à l'écran, et non après la soumission.

Quand un établissement atterrit en mer

Le naufrage le plus courant dans une liste de coordonnées d'exploitations, c'est la latitude et la longitude inversées. Les positions GeoJSON s'écrivent [longitude, latitude] en degrés décimaux WGS84 ; un tableur qui les fournit dans l'ordre de lecture jette un ranch de l'intérieur des terres en plein océan, et TRACES l'importe sans commentaire. Pour chaque établissement, vérifiez que :

• La position est sur la terre ferme, pas en pleine eau.
• La parcelle se situe à l'intérieur du ProducerCountry déclaré pour elle.
• Les coordonnées sont des degrés décimaux dans l'ordre [longitude, latitude] — et non des mètres issus d'une grille nationale projetée.
• Les anneaux sont fermés, comptent au moins quatre positions et ne se croisent pas eux-mêmes.
• Area est un nombre, pas du texte — "Area": "3" est lu comme 0 hectare.

Rien de tout cela n'est rattrapé en aval. TRACES rejette visiblement exactement deux choses : une syntaxe JSON invalide, et un polygone avec anneaux intérieurs, auquel il répond Polygon with holes are not accepted by the system. Tout le reste, sémantiquement faux, est accepté en silence : un écran d'import sans erreur n'est donc pas la preuve d'une déclaration correcte.

Questions

Quelle géolocalisation l'EUDR exige-t-elle pour le bétail ?

La localisation de chaque lieu de production — les établissements et pâturages où le bétail a été détenu. La règle « au-delà de 4 ha, il faut un polygone » de l'Art. 2(28) vise les parcelles des matières premières cultivées sur terre, pas les établissements d'élevage.

Nos limites d'exploitation viennent du cadastre national sous forme de Shapefile. Puis-je les donner à TRACES ?

Non. TRACES n'accepte que .geojson et .json — un Shapefile, un KML ou un fichier Excel ne peuvent même pas être sélectionnés dans son sélecteur de fichiers. Déposez plutôt le Shapefile compressé dans DDSpass : le .prj est lu, la géométrie reprojetée en WGS84, et vous récupérez du GeoJSON. Voir De Shapefile à GeoJSON EUDR.

Un établissement compte cinq parcs distincts. Faut-il une entité ou cinq ?

Les deux fonctionnent, puisque Polygon et MultiPolygon sont acceptés. Un MultiPolygon garde l'exploitation comme un seul lieu de production ; cinq entités vous permettent de nommer chaque parcelle dans ProductionPlace. Quel que soit votre choix, orthographiez ProducerName et ProducerCountry à l'identique — c'est ce couple qui sert de regroupement à l'export Type I.

TRACES a importé notre fichier bétail sans erreur. Cela signifie-t-il que la déclaration est correcte ?

Pas nécessairement. Un import propre vous dit seulement que le JSON s'est analysé et qu'aucun polygone n'avait de trou. Il ne dit rien de l'ordre des coordonnées, du fait qu'un emplacement soit sur la terre ferme, ni du fait que deux établissements couvrent la même terre. Une surface écrite en texte s'importe sans broncher et compte pour 0 hectare.