Convertissez un Shapefile en GeoJSON EUDR prêt pour TRACES — sans rejets

Pourquoi un Shapefile demande plus qu'un renommage

Un Shapefile est un ensemble — .shp (formes), .shx (index), .dbf (attributs) et surtout .prj (le système de référence de coordonnées). Les parcelles sont souvent stockées dans une grille nationale projetée en mètres, et non dans les degrés de longitude/latitude WGS84 exigés par TRACES. Changez l'extension sans reprojeter et chaque parcelle atterrit au mauvais endroit — ou échoue purement et simplement.

DDSpass lit le .prj, reprojette en degrés décimaux WGS84 et répare la géométrie que portent souvent les Shapefiles — anneaux auto-sécants du tracé automatique, polygones non fermés, trous — et signale tout ce qu'une personne doit vérifier.

Compressez, déposez, c'est fait

Mettez le .shp avec au moins ses .shx, .dbf et .prj dans un .zip et déposez-le. Vous obtenez un GeoJSON propre et prêt pour TRACES ainsi qu'un rapport de corrections en langage clair pour votre fournisseur. Les données cadastrales et parcellaires sont sensibles — tout s'exécute dans votre navigateur et le fichier n'est jamais envoyé.

Le .prj manquant est l'échec classique

Ouvrez le .shp sans sa projection et un sommet donne quelque chose comme 512340, 4318220. Rien dans le fichier ne dit s'il s'agit de mètres dans une grille nationale, de pieds ou d'autre chose — et ce ne sont manifestement pas des degrés, puisque la longitude va de −180 à 180 et la latitude de −90 à 90. Le .prj est la seule partie de l'ensemble qui réponde à la question.

Lorsqu'il est présent, DDSpass reprojette en degrés décimaux WGS84 et l'affaire est réglée. Lorsqu'il manque, les parcelles sont signalées comme une grille locale à renvoyer plutôt que devinées — et cette retenue est essentielle, car TRACES ne contrôle pas la vraisemblance des coordonnées. Un fichier converti sous une projection inventée est accepté intégralement, chaque parcelle au mauvais endroit et sans le moindre avertissement.

Le remède est du côté du SIG : demandez que la couche soit réexportée avec son fichier de projection, ou exportée directement en WGS84 / EPSG:4326. L'un comme l'autre tient en une boîte de dialogue dans QGIS ou ArcGIS et lève l'ambiguïté pour de bon.

Les noms d'attributs sont tronqués à dix caractères

Le format DBF limite les noms de champs à dix caractères : les noms de propriétés EUDR ne peuvent donc pas survivre intacts à un aller-retour par un Shapefile. TRACES lit une liste exacte, sensible à la casse — ProducerName, ProducerCountry, ProductionPlace, Area — et un nom tronqué n'est pas lu du tout :

• ProducerName → ProducerNa — deux caractères perdus, récupérés automatiquement
• ProducerCountry → ProducerCo — coupé trop tôt pour être sans ambiguïté
• ProductionPlace → Production — même problème
• Area → Area — assez court pour survivre intact

DDSpass récupère les quasi-correspondances, y compris les simples différences de casse, et liste chaque renommage dans le rapport de corrections avec le nom d'origine et le nom final, pour que rien ne soit mis en correspondance à votre insu. Ce qu'il ne peut pas résoudre est signalé comme manquant plutôt que deviné : un lieu de production absent est rempli par un espace réservé numéroté, et un pays manquant — ou écrit en toutes lettres au lieu d'un code ISO2 valide — est signalé au fournisseur. Comme la limite de dix caractères appartient au format et non à vos réglages d'export, vérifier cette liste de renommages fait partie du travail.

Plusieurs couches, et le plafond de 25 Mo

Les livraisons forestières et cadastrales arrivent rarement en une seule couche. Si le zip contient plusieurs fichiers .shp — parcelles, peuplements, blocs — chaque couche est lue et combinée en un seul FeatureCollection, pour que rien ne soit discrètement abandonné. Un zip qui ne contient aucun .shp mais plusieurs jeux de données indépendants est au contraire traité comme un lot, et chaque fichier est vérifié pour lui-même.

Les limites cadastrales et tracées par machine se heurtent ensuite à l'autre mur : une DDS est plafonnée à 25 Mo, et des bords de parcelle relevés au centimètre portent un nombre de sommets dont aucun contour d'exploitation n'a besoin. DDSpass supprime d'abord les sommets colinéaires, ce qui est sans perte — un point posé sur une droite entre ses voisins ne décrit rien — puis simplifie davantage sans jamais laisser la surface totale dériver de plus de 0,5 %. Si le fichier ne rentre toujours pas, vous obtenez les instructions officielles de division de la DDS, et la sortie par producteur (Type I) pour le découper.

Un détail propre aux données SIG de haute précision : le système arrondit les coordonnées à six décimales. Une limite tracée à neuf décimales peut avoir des sommets voisins qui se confondent une fois arrondis et deviennent des doublons — exactement la condition qui rend invalide un anneau valide. Ils sont détectés et fusionnés pendant la conversion, au lieu de partir dans la déclaration.

Questions

TRACES accepte-t-il un Shapefile pour l'EUDR ?

Non. Le système de l'UE n'accepte que le GeoJSON pour la géolocalisation. Un Shapefile doit d'abord être converti — et reprojeté en WGS84.

Quels fichiers me faut-il dans le zip ?

Au minimum .shp, .shx et .dbf ; incluez le .prj pour que le système de coordonnées soit connu. Sans .prj, DDSpass ne peut pas reprojeter de façon fiable et signale les parcelles comme grille locale à renvoyer.

Mon Shapefile est-il envoyé quelque part ?

Non. Il est lu, reprojeté et validé entièrement dans votre navigateur ; le fichier ne quitte jamais votre appareil.

Mes noms d'attributs ont été tronqués à dix caractères — est-ce grave ?

Cela peut l'être. Le format DBF limite les noms de champs à dix caractères : ProducerCountry revient donc en ProducerCo et ProductionPlace en Production, alors que TRACES lit une liste exacte de noms de propriétés, sensible à la casse. DDSpass récupère automatiquement les correspondances proches, liste chaque renommage dans le rapport de corrections et signale ce qu'il n'a pas pu associer plutôt que de le deviner.

Le zip peut-il contenir plus d'un shapefile ?

Oui. Chaque couche .shp présente dans le zip est lue et combinée en un seul FeatureCollection : une livraison découpée en parcelles ou en blocs ne perd donc rien. Si le zip ne contient aucun .shp mais plusieurs fichiers de données indépendants — KML, Excel, GeoJSON — il est au contraire traité comme un lot et chaque fichier est vérifié séparément.