Fichier GNSS : comment le convertir en DXF ?

Fichier GNSS: comment le convertir en DXF?

Sur un chantier, nous avons tous vu ce scénario: les points semblent correctement relevés, le fichier s’ouvre dans la DAO, puis le plan arrive minuscule, décalé de plusieurs kilomètres ou avec des altitudes qui ne correspondent à rien de lisible. La donnée n’est pas forcément mauvaise. C’est souvent le passage entre deux mondes qui l’est.

Le GNSS travaille volontiers en coordonnées géographiques, avec une latitude, une longitude et une hauteur liée à l’ellipsoïde. Le format DXF, lui, attend des coordonnées cartésiennes exploitables dans un dessin: X, Y, Z, généralement exprimées en mètres. Entre les deux, il faut faire un vrai travail de préparation, pas seulement appuyer sur « Convertir ».

La réponse courte est donc la suivante: on importe le fichier GNSS, on identifie son système de coordonnées, on le reprojette dans le système local du projet — Lambert 93 dans la plupart des cas en France métropolitaine —, on traite l’altitude si le dessin a une composante 3D, puis on exporte avec une organisation de calques cohérente. C’est ce cheminement qui évite les mauvaises surprises.

Le point de bascule: passer du WGS84 à un plan en mètres

Le problème le plus courant tient à une confusion très simple: un point GNSS n’est pas automatiquement un point topographique prêt à dessiner.

Un fichier GPX, un CSV issu d’une application de collecte ou des trames NMEA contiennent souvent des coordonnées en WGS84, référencées EPSG:4326. Dans ce système, la position est exprimée en degrés. C’est parfaitement adapté à la navigation, à la cartographie web ou au partage de positions. Cela ne l’est pas pour caler directement un relevé dans AutoCAD, BricsCAD ou QCAD.

Dans un DXF topographique, nous voulons manipuler des mètres. Un segment de 12 mètres doit réellement mesurer 12 unités dans le logiciel de DAO, sans gymnastique ni facteur caché. En France, le système de référence le plus fréquent est Lambert 93, soit EPSG:2154.

La différence paraît théorique jusqu’au moment où elle bloque une équipe. Une valeur de l’ordre de 0,00001 degré peut correspondre approximativement à un mètre au sol. Si cette valeur angulaire est lue comme une unité métrique dans le dessin, l’échelle s’effondre. Le plan peut alors sembler vide, car les entités sont concentrées dans une zone infime, ou à l’inverse se retrouver à une distance absurde du fond de plan.

Un DXF ne corrige pas le système de coordonnées à votre place: il dessine exactement les valeurs qu’on lui fournit.

Avant toute exportation, nous devons donc répondre à trois questions concrètes:

• Quelle est la source du fichier? Un GPX de smartphone, un export de contrôleur GNSS, un CSV issu d’une application terrain ou un fichier NMEA ne portent pas tous les mêmes informations.
• Dans quel système les coordonnées sont-elles exprimées? Latitude/longitude WGS84, coordonnées projetées déjà calculées, système local de chantier: il ne faut pas deviner.
• Quel référentiel utilise le plan destinataire? Lambert 93, projection locale, système d’un marché précis ou canevas interne d’un bureau d’études: le bon système est celui du projet, pas celui qui paraît le plus pratique.

Cette étape peut sembler lente quand le conducteur de travaux attend un fichier « pour tout de suite ». En réalité, elle évite la friction la plus coûteuse: celle du projeteur qui doit reprendre un dessin incohérent sans savoir où le décalage a commencé.

Importer dans un logiciel SIG: la méthode la plus souple pour les fichiers hétérogènes

Quand les données arrivent de sources variées, QGIS reste une solution très efficace. Il accepte les GPX, les CSV bien structurés et de nombreux formats vecteur, tout en donnant la main sur la projection et les attributs. Pour l’importation données terrain DAO, c’est souvent le meilleur poste de contrôle avant l’envoi vers la CAO.

Le processus est simple dans son principe, mais chaque choix a son importance.

1. Importer le fichier avec son système source réel.

Pour un GPX, le système est généralement reconnu en WGS84. Pour un CSV, il faut indiquer quelles colonnes correspondent à X et Y, puis attribuer le bon système de coordonnées. Un tableau avec des colonnes longitude et latitude ne devient pas Lambert 93 parce qu’on souhaite travailler en Lambert 93.

2. Vérifier visuellement la position.

Ajouter un fond cartographique ou une couche de référence permet de repérer immédiatement un ordre de grandeur aberrant. Un levé réalisé à Rennes qui s’affiche au large de l’Afrique n’est pas un mystère géodésique: c’est presque toujours un système mal déclaré ou des colonnes inversées.

3. Reprojeter la couche dans le système cible.

Dans le cas habituel d’un projet français, on produit une couche en EPSG:2154. Cette opération transforme les coordonnées géographiques en coordonnées planes métriques. Elle ne dégrade pas, par magie, la précision intrinsèque du levé; elle met les données dans le langage spatial attendu par le plan.

4. Préparer les attributs utiles au dessin.

Code terrain, numéro de point, description, type d’objet, altitude, date de levé: ce sont ces informations qui permettront de créer des calques, des libellés ou des symboles cohérents. Les perdre à l’export, c’est recréer à la main une partie du travail déjà faite sur le terrain.

5. Exporter en DXF.

Dans QGIS, un clic droit sur la couche puis « Exporter » et « Enregistrer les entités sous » permet de choisir le format AutoCAD DXF. Pour un ensemble de couches, l’export du projet en DXF offre une approche plus structurée, à condition d’avoir préparé la symbologie et les noms de couches.

Voici ce que change réellement le choix du format source.

Le vrai avantage du SIG est là: il rend les transformations visibles. Nous pouvons voir les objets, interroger leurs attributs, détecter un point sans code ou une altitude vide, comparer le résultat avec une couche de référence. C’est plus rassurant qu’un convertisseur qui renvoie un fichier à télécharger sans montrer ce qu’il a réellement fait.

Exporter des points GNSS vers AutoCAD: la géométrie ne suffit pas

Un DXF peut contenir des points, des polylignes, des textes, des blocs et des calques. Pourtant, beaucoup de conversions se limitent à envoyer une nuée de points sans contexte. Techniquement, le fichier est valide. Opérationnellement, il devient pénible à exploiter.

Sur le terrain, un point n’est jamais seulement un couple X/Y. Il représente une borne, un regard, une arête de trottoir, un pied de façade, une tête de talus ou un détail à contrôler. Si les codes ont été saisis avec une logique partagée entre l’équipe terrain et le bureau, ils doivent servir jusqu’au dessin final.

C’est ici que l’ergonomie de la chaîne de production fait la différence. Une bonne conversion ne demande pas au dessinateur de deviner ce que signifie « PT_148 ». Elle lui donne au moins les éléments pour trier, isoler et contrôler les objets.

Nous gagnons en fluidité lorsque l’export distingue, par exemple:

• les points ponctuels, placés sur un calque dédié avec leur code ou leur matricule;
• les ruptures linéaires, exportées comme polylignes plutôt que comme une suite de points isolés;
• les objets de contrôle, séparés des détails de levé pour ne pas polluer le dessin final;
• les annotations utiles, comme les cotes altimétriques ou les descriptions, lorsque le niveau de détail du plan le justifie;
• les couches métier, nommées de manière stable afin qu’un projeteur puisse appliquer ses conventions sans reprendre toute la structure.

Cette organisation n’est pas du confort superflu. C’est ce qui transforme un export brut en fichier transmissible. Dans les équipes où plusieurs personnes se relaient entre terrain, traitement et DAO, elle réduit fortement la courbe d’apprentissage et les appels de dernière minute.

Le meilleur export est celui que le collègue ouvre sans devoir vous rappeler pour demander: « Tes points, ils correspondent à quoi? »

QGIS permet de construire cette logique, mais demande un peu de méthode sur la symbologie et les champs attributaires. Ce temps de paramétrage est rentable dès lors que les livraisons se répètent: levés de récolement, inventaires de réseaux, implantation, diagnostics de voirie ou relevés de patrimoine.

Les suites constructeurs: moins de bricolage, à condition d’assumer leur cadre

Quand le levé vient d’un contrôleur GNSS professionnel et que le bureau utilise l’environnement logiciel du même constructeur, la conversion peut être beaucoup plus directe.

Des suites telles que Trimble Business Center ou Leica Infinity savent importer les données du terrain, conserver les codes, interpréter les bibliothèques de caractéristiques et exporter un DXF ou un DWG avec des calques, couleurs et styles déjà préparés. Si l’équipe utilise une bibliothèque de codes bien tenue — par exemple une bibliothèque FXL dans l’univers Trimble —, une bordure peut devenir une polyligne, un candélabre peut rejoindre son calque et un regard peut recevoir le symbole prévu.

Le bénéfice est net: moins de ressaisie, moins de compromis au moment de passer du carnet au plan, et une continuité plus naturelle entre les personnes qui ont relevé et celles qui dessinent.

Mais cette intégration native ne dispense pas du contrôle. Elle automatise une convention; elle ne remplace pas la convention.

Une bibliothèque de codes mal comprise, un code saisi de façon différente par deux opérateurs ou un projet réglé dans le mauvais système de coordonnées produiront un DXF très propre… et tout aussi faux. C’est le piège des flux trop confortables: lorsqu’ils fonctionnent, on oublie de vérifier ce qu’ils supposent.

Nous recommandons de sécuriser l’adoption autour de quelques habitudes simples:

1. Une convention de codification courte et partagée.

L’opérateur doit pouvoir l’appliquer sans feuilleter trente pages sur le chantier. Si le référentiel est trop compliqué, il sera contourné dès la première urgence.

2. Un projet type par famille de mission.

Récolement, levé de corps de rue, implantation, contrôle de plateforme: les besoins de calques et de livrables ne sont pas identiques. Un modèle par usage évite les réglages improvisés.

3. Un contrôle croisé sur quelques points connus.

Avant d’envoyer le DXF, vérifier une distance, une position sur fond de plan et une altitude de référence est souvent suffisant pour détecter les grosses erreurs de paramétrage.

4. Une transmission claire du système de coordonnées.

Le fichier DXF ne porte pas toujours l’information de référence de manière aussi explicite qu’une couche SIG. Le nom du fichier, le cartouche ou la note de livraison doivent lever toute ambiguïté.

Ce sont des gestes modestes, mais ils empêchent le fameux effet domino: une erreur initiale, invisible dans le contrôleur, devient une reprise de DAO, puis un doute au bureau d’études, puis une journée perdue sur le terrain.

L’altitude: le Z du GNSS n’est pas toujours le Z du plan

C’est le point qui demande le plus de sang-froid. En planimétrie, un GNSS RTK peut fournir couramment une précision horizontale de l’ordre de 20 mm dans de bonnes conditions. En altimétrie, la précision typique est plutôt autour de 40 mm, avec une sensibilité accrue aux conditions de réception, au contrôle du matériel et au modèle utilisé.

Mais la précision n’est qu’une partie du sujet. La nature de l’altitude compte tout autant.

Le GNSS donne nativement une hauteur ellipsoïdale: une distance calculée par rapport à l’ellipsoïde de référence. Or, les plans topographiques, projets VRD et documents d’exécution utilisent généralement une altitude orthométrique, liée à une référence de niveau physique et donc plus proche de ce que nous appelons l’altitude sur le terrain.

Passer de l’une à l’autre implique l’application d’un modèle de géoïde adapté. Sans cette correction, le champ Z peut être cohérent entre les points tout en étant décalé par rapport aux altitudes attendues sur le projet. C’est le genre de décalage qui ne saute pas aux yeux sur un plan 2D, mais qui devient très sérieux dès qu’on calcule des pentes, des cubatures ou des raccordements de réseaux.

Pour une exportation 3D, il faut donc clarifier dès le départ:

• si le contrôleur a enregistré une hauteur ellipsoïdale ou une altitude corrigée;
• quel modèle de géoïde a été utilisé;
• si les altitudes doivent être compatibles avec le référentiel du projet;
• si la couche exportée contient réellement un champ Z exploitable, et non un texte ou une valeur d’attribut déconnectée de la géométrie.

Un DXF peut parfaitement contenir des objets 3D. Encore faut-il que le Z ait du sens. Exporter toutes les entités à zéro est parfois un choix raisonnable pour un fond de plan strictement 2D; livrer des altitudes ellipsoïdales comme si elles étaient des cotes de nivellement ne l’est pas.

Convertir un CSV en DXF dans un SIG ou avec un outil léger

Tous les besoins ne justifient pas de mobiliser une suite complète de traitement GNSS. Pour un fichier de points CSV ou TXT propre, contenant déjà des X, Y, Z dans le bon système local, un outil spécialisé peut faire gagner du temps.

Des convertisseurs légers permettent de créer un DXF à partir d’un tableau de coordonnées sans installer une solution de CAO lourde. Les convertisseurs en ligne peuvent aussi dépanner pour transformer un GPX, un KML ou un CSV, parfois avec une reprojection proposée au passage.

C’est utile pour une opération ponctuelle, un échange rapide ou un petit inventaire. Mais il faut garder la main sur les paramètres. L’outil ne sait pas, par intuition, si les valeurs 48,8566; 2,3522 sont des coordonnées géographiques, si une virgule est décimale ou séparatrice, ni si la colonne « Alt » correspond à une hauteur corrigée.

Avant de convertir un CSV en DXF SIG, nous prenons donc quelques minutes pour lire le fichier comme le ferait la personne qui devra le reprendre demain:

• les coordonnées sont-elles dans l’ordre X puis Y, et non latitude puis longitude;
• les séparateurs décimaux et de colonnes sont-ils interprétés correctement;
• les unités sont-elles bien des mètres;
• le système de référence est-il identifié dans le nom du fichier ou dans la documentation de mission;
• les points ont-ils un identifiant unique;
• la colonne Z est-elle renseignée, homogène et réellement exploitable;
• les champs descriptifs nécessaires à la DAO ont-ils été conservés.

Ce contrôle n’a rien de spectaculaire. Il évite simplement de confondre vitesse et précipitation. Une conversion automatique est un accélérateur: elle accélère un bon flux de données comme elle accélère une erreur mal détectée.

Le bon DXF est celui qui reste compréhensible après le chantier

La conversion GNSS vers DXF n’est pas une formalité informatique placée entre le terrain et le dessin. C’est une étape de traduction entre des pratiques, des logiciels et des métiers qui n’ont pas toujours les mêmes réflexes.

Le GPX, le CSV ou le NMEA racontent une acquisition. Le DXF doit devenir un document de travail fiable pour la DAO. Pour réussir le passage, nous devons préserver trois choses: la bonne position grâce à la reprojection, la bonne hauteur grâce au traitement altimétrique, et le sens métier grâce aux attributs, aux codes et aux calques.

Le Lambert 93 ne résout pas tout, mais il pose un socle solide lorsque le projet le demande. Les suites constructeurs font gagner du temps, mais seulement si les conventions terrain sont tenues. Les outils légers rendent service, mais seulement si l’on contrôle les colonnes et les unités.

Au fond, la bonne méthode est celle que toute l’équipe peut reproduire sans créer de friction: l’opérateur sait ce qu’il relève, le géomaticien sait ce qu’il transforme, le projeteur sait ce qu’il ouvre. À ce moment-là, le DXF cesse d’être un fichier de plus à déboguer et redevient ce qu’il doit être: une base nette pour avancer sur le plan.