Importation GNSS dans QGIS : la méthode rapide

Importation GNSS dans QGIS: la méthode rapide

Le problème vient plutôt d’un décalage entre plusieurs couches de la chaîne: format d’échange, ordre des coordonnées, système de référence, structure attributaire et gestion de l’altitude. Un fichier peut donc s’ouvrir correctement tout en plaçant les points au mauvais endroit, en supprimant la composante Z ou en produisant une couche impossible à éditer proprement.

La méthode rapide consiste à distinguer ces opérations au lieu de les mélanger: identifier le format produit par le récepteur, charger la géométrie dans son système de coordonnées d’origine, contrôler visuellement et numériquement le résultat, puis convertir la couche vers un format de travail permanent. Dans la plupart des projets, cette séquence est plus fiable qu’un import direct suivi de corrections ponctuelles.

Le format du fichier détermine la méthode d’import

QGIS ne traite pas de la même manière une trace GPX, un tableau CSV et un fichier issu d’un carnet de terrain GNSS. Ces formats peuvent tous contenir des coordonnées, mais ils ne décrivent pas la géométrie avec le même niveau de structure.

Le format GPX est généralement le plus simple lorsqu’il provient d’un récepteur ou d’une application de navigation. QGIS peut lire directement les éléments classiques du format GPS Exchange Format:

• les waypoints, qui correspondent à des points enregistrés individuellement;
• les routes, organisées comme des itinéraires composés de plusieurs positions;
• les traces, qui représentent une succession de points formant une ligne;
• les attributs associés, selon les informations conservées lors de l’export.

Un fichier CSV ou TXT délimité est plus souple, mais il demande davantage de paramétrage. QGIS doit savoir quels champs contiennent les coordonnées, quel séparateur distingue les colonnes et quel système de référence s’applique aux valeurs. La moindre ambiguïté à ce stade peut produire une couche vide, un nuage de points décalé ou une géométrie interprétée avec une mauvaise unité.

Les formats propriétaires des fabricants de matériel GNSS doivent, eux, être considérés comme une étape intermédiaire. Selon le récepteur, l’export peut passer par un logiciel de post-traitement ou de préparation de mission avant de produire un GPX, un CSV, un DXF, un Shapefile ou un GeoPackage. Il n’existe pas une procédure universelle pour les fichiers natifs de chaque constructeur: le flux dépend de l’application utilisée pour les extraire et les convertir.

La rapidité ne vient pas d’un bouton d’importation unique, mais d’un format intermédiaire suffisamment explicite pour que QGIS puisse reconstruire la géométrie sans interprétation ambiguë.

Importer un fichier GPX dans QGIS

L’importation d’un fichier GPX s’effectue depuis le Gestionnaire des sources de données de QGIS. Le fichier est sélectionné comme source vectorielle, puis QGIS propose les différentes couches disponibles lorsqu’il en contient plusieurs. Il faut alors choisir le type de géométrie correspondant au besoin: waypoints, routes ou traces.

Cette distinction est opérationnelle, et non simplement descriptive. Une trace GNSS destinée à analyser un parcours ne se manipule pas comme une série de points de contrôle. De la même manière, les waypoints peuvent contenir des informations utiles pour une collecte ponctuelle, mais ils ne reconstituent pas automatiquement une ligne ou un polygone.

Après le chargement, la première vérification doit porter sur l’emprise de la couche. Si les données sont des coordonnées GPS brutes en latitude et longitude, le système de référence attendu est généralement WGS84, associé à l’EPSG:4326. Il s’agit d’un système géographique exprimé en degrés, et non d’un système projeté exprimé en mètres.

Cette différence explique une grande partie des erreurs d’affichage. Une couche en EPSG:4326 peut être correctement positionnée dans un projet utilisant le Lambert-93, EPSG:2154, à condition que QGIS connaisse le système de coordonnées de la couche et effectue la reprojection à l’affichage. En revanche, attribuer le mauvais CRS à la couche ne revient pas à la reprojeter: cela modifie l’interprétation des nombres et peut déplacer les données de manière radicale.

Ce qu’il faut contrôler après un import GPX

Une fois la couche chargée, plusieurs contrôles rapides permettent de repérer les anomalies avant toute conversion:

1. Comparer l’emprise avec le territoire étudié. Une trace attendue en France ne doit pas se retrouver dans une autre région du monde à cause d’un EPSG mal sélectionné.

2. Vérifier le type de géométrie. Une couche de traces doit être constituée de lignes, tandis qu’une couche de waypoints doit rester ponctuelle. Une confusion à ce stade peut fausser les traitements spatiaux ultérieurs.

3. Examiner les champs attributaires. Les noms, dates, identifiants, vitesses ou informations d’altitude ne sont pas toujours présents selon le logiciel ayant produit le GPX.

4. Contrôler l’altitude. La valeur Z peut être conservée comme attribut numérique sans être intégrée directement à la géométrie tridimensionnelle.

5. Tester l’édition. Une couche GPX importée est exploitable pour la lecture, mais elle n’offre pas nécessairement le même comportement qu’une couche de travail enregistrée dans un format vectoriel permanent.

L’altitude est un cas particulier. Dans un tableau ou une structure GPX, elle peut être disponible sous forme de champ attributaire. Cela ne signifie pas qu’elle est automatiquement incorporée à chaque sommet de la géométrie. Pour produire une géométrie 3D, il peut être nécessaire de sélectionner le champ d’altitude et d’utiliser un traitement tel que « Définir la valeur Z ». La donnée doit donc être vérifiée avant toute analyse de pente, de profil altimétrique ou de comparaison avec un modèle numérique de terrain.

Importer un CSV de coordonnées dans QGIS

Le CSV est souvent le format le plus pratique pour une campagne GNSS lorsque le logiciel de terrain exporte une table simple. Il permet de conserver les attributs métier — identifiant, code, description, date, précision ou statut — en parallèle des coordonnées. En contrepartie, QGIS ne peut pas deviner seul la structure du fichier.

L’import s’effectue avec l’outil « Ajouter une couche de texte délimité ». La fenêtre de paramétrage doit être lue comme une description du modèle de données:

• quel caractère sépare les champs;
• quelle colonne contient la coordonnée X;
• quelle colonne contient la coordonnée Y;
• quelle colonne contient éventuellement la coordonnée Z;
• quel est le système de coordonnées des valeurs;
• quelle encodage permet de conserver correctement les caractères.

Pour des coordonnées géographiques, X correspond généralement à la longitude et Y à la latitude. Pour des coordonnées projetées françaises en Lambert-93, X correspond à l’Est et Y au Nord, avec des valeurs exprimées en mètres. Cette convention doit être confirmée à partir de la documentation d’export ou de la structure du fichier, car l’intitulé des champs peut être trompeur.

Une inversion longitude-latitude est l’une des erreurs les plus fréquentes. Elle ne produit pas toujours une erreur technique: QGIS peut parfaitement créer des points à partir de deux colonnes valides, mais les placer dans une zone sans rapport avec le levé. La validation géographique est donc une étape du traitement, pas une simple formalité visuelle.

Séparateur de champs et séparateur décimal

Deux séparateurs sont à distinguer:

• le séparateur de champs, par exemple la virgule, le point-virgule ou la tabulation;
• le séparateur décimal, qui peut être le point ou la virgule selon le logiciel et les paramètres régionaux.

Un fichier peut ainsi utiliser le point-virgule entre les colonnes et la virgule dans les nombres décimaux. Si QGIS reçoit une configuration différente, les coordonnées peuvent être lues comme du texte, regroupées dans une seule colonne ou tronquées à la première décimale.

Le contrôle le plus efficace consiste à observer l’aperçu proposé dans la fenêtre d’importation. Les colonnes doivent apparaître séparément, les coordonnées doivent être reconnues comme numériques et les valeurs doivent présenter une précision cohérente avec le levé. Si les coordonnées contiennent des caractères, des unités ou des espaces parasites, le nettoyage doit être réalisé avant la création de la géométrie.

Un CSV ne constitue pas toujours une base de données géospatiale complète. Il est adapté à l’échange, au contrôle et à l’import ponctuel, mais moins adapté à la conservation d’une structure complexe comprenant plusieurs couches, des relations, des contraintes de domaine ou des géométries éditables.

Le système de coordonnées: ne pas confondre attribuer et reprojeter

Le système de coordonnées de référence, ou CRS, décrit la manière dont les nombres représentent une position sur la Terre. Dans un flux GNSS, il intervient à deux moments différents: lors de la lecture du fichier source et lors de la production de la couche de travail.

La première opération consiste à attribuer le CRS source. QGIS doit savoir ce que signifient les valeurs déjà présentes dans le fichier. Des coordonnées en longitude et latitude issues d’un fichier GPS brut relèvent généralement du WGS84, EPSG:4326. Des coordonnées X/Y en mètres dans un projet national français relèvent généralement du Lambert-93, EPSG:2154.

La seconde opération consiste à reprojeter la couche vers le système adapté au projet. Pour une analyse cartographique en France métropolitaine, le Lambert-93 est souvent utilisé lorsque les traitements nécessitent des distances, des surfaces ou des coordonnées métriques. La reprojection transforme les coordonnées; elle ne se contente pas de modifier l’étiquette du CRS.

Cette distinction peut être résumée ainsi:

Le projet QGIS peut afficher automatiquement des couches dans un même référentiel grâce à la reprojection à la volée. Cette facilité ne dispense pas de choisir un CRS de stockage cohérent. Une base de données qui mélange des couches conservées en degrés, en mètres et dans des références locales devient rapidement difficile à interroger et à maintenir.

Les requêtes spatiales sont particulièrement sensibles à cette organisation. Une distance calculée sur des coordonnées géographiques en degrés ne se lit pas comme une distance en mètres dans un système projeté. Les contrôles de proximité, les buffers, les surfaces et les opérations de topologie doivent donc s’appuyer sur un référentiel adapté au calcul demandé.

Intégrer l’altitude Z dans les données GNSS

Les données GNSS peuvent contenir trois composantes: X, Y et Z. Pourtant, l’altitude est fréquemment traitée comme une colonne supplémentaire plutôt que comme une dimension de la géométrie.

Cette distinction change le comportement de QGIS. Une couche de points 2D accompagnée d’un champ altitude permet d’afficher une valeur et de la symboliser, mais elle ne devient pas automatiquement une couche de points 3D. De même, une ligne dont les sommets ne portent pas de valeur Z ne peut pas être utilisée comme une véritable trajectoire tridimensionnelle, même si l’altitude existe dans sa table attributaire.

Le traitement dépend donc de l’objectif:

• pour une carte descriptive, un champ d’altitude peut suffire;
• pour un profil, une extrusion ou une analyse 3D, la valeur doit être intégrée à la géométrie;
• pour une comparaison altimétrique, il faut également vérifier la nature de la hauteur: ellipsoïdale, orthométrique ou corrigée par un modèle de géoïde;
• pour une production topographique, il faut conserver la traçabilité de la source et de la méthode de calcul.

QGIS peut utiliser un champ numérique afin de définir la valeur Z de la géométrie. Avant ce traitement, la colonne doit être nettoyée: valeurs vides, unités, séparateurs décimaux et éventuels codes de mesure doivent être traités. Une altitude enregistrée comme texte ne peut pas être utilisée de manière fiable dans une opération géométrique.

La qualité du résultat ne dépend pas seulement du logiciel SIG. Elle dépend aussi du traitement GNSS en amont, du mode de correction, de la configuration du récepteur et du référentiel altimétrique choisi. QGIS organise et transforme la donnée; il ne reconstitue pas une précision qui n’a pas été produite lors de l’acquisition.

Une altitude stockée dans la table n’est pas encore une géométrie 3D. Il faut contrôler la colonne, sélectionner la bonne dimension et produire explicitement la nouvelle géométrie.

Convertir la couche importée vers un format de travail

Après un import GPX ou CSV, la couche devrait généralement être exportée vers un format vectoriel permanent. Cette conversion stabilise le flux et évite de construire un projet opérationnel sur un fichier conçu principalement pour l’échange.

Le GeoPackage, avec l’extension .gpkg, est souvent le choix le plus cohérent pour un projet QGIS. Il peut contenir plusieurs couches dans un même fichier, conserver des noms de champs plus explicites et supporter une structure plus riche que le Shapefile. Il facilite également la conservation d’un modèle de données regroupant points, lignes, secteurs, observations et tables associées.

Le Shapefile reste présent dans de nombreux échanges, mais ses contraintes historiques compliquent la gestion des données métier. Les noms de champs sont notamment limités à 10 caractères, ce qui conduit à abréger des attributs et à perdre parfois la lisibilité du modèle relationnel. Certains champs texte peuvent également être soumis à une longueur maximale standard de 254 caractères selon le type d’export et le pilote utilisé.

Lors de l’export, le CRS de destination doit être sélectionné explicitement. Si le fichier source est en WGS84 mais que la base de travail doit être en Lambert-93, il faut choisir le Lambert-93 comme CRS de sortie afin de transformer réellement les coordonnées. Modifier uniquement le nom du système de référence dans les propriétés de la couche ne produit pas cette conversion.

L’export est également le moment de vérifier le type de géométrie, la conservation des champs et la présence éventuelle de la dimension Z. Une couche peut être visuellement correcte dans QGIS tout en ayant perdu une partie de ses attributs lors de la conversion. Il faut donc comparer la structure avant et après export, surtout lorsque le fichier alimente ensuite une application de collecte ou une base partagée.

Et les fichiers NMEA?

La demande d’importer un fichier NMEA dans QGIS revient souvent lorsque les données proviennent d’un récepteur GNSS ou d’une session d’enregistrement brute. Le NMEA est toutefois un format de trames textuelles, conçu pour transmettre des informations de position et d’état entre équipements, et non pour fournir directement une couche vectorielle structurée comparable à un GeoPackage.

Le traitement dépend du contenu du fichier et de l’outil qui l’a produit. Dans un flux professionnel, on passe généralement par une étape de lecture ou de conversion capable d’extraire les phrases utiles, de reconstruire les positions et de produire un format que QGIS sait importer plus directement, comme un CSV structuré ou un GPX.

Cette étape doit préserver plusieurs éléments:

• les coordonnées et leur ordre;
• l’horodatage;
• la qualité ou le statut de la position;
• le nombre de satellites, lorsqu’il est disponible;
• la hauteur et son référentiel;
• les éventuelles informations de correction ou de solution GNSS.

Il serait donc imprudent de traiter tous les fichiers NMEA comme s’ils suivaient une structure identique. Le choix du convertisseur doit être lié au type de trame, au récepteur et à l’usage attendu. Une conversion qui ne conserve que la latitude et la longitude peut suffire pour visualiser une trajectoire, mais devenir insuffisante pour analyser la qualité du positionnement ou reconstituer un levé.

Dans ce cas, QGIS intervient après la conversion, pour contrôler la couche, appliquer le CRS source, filtrer les positions, produire des géométries et intégrer les résultats dans le modèle spatial du projet. Le logiciel SIG ne doit pas être utilisé comme un lecteur universel de tous les formats bruts: la séparation entre acquisition, conversion et exploitation rend le flux plus lisible et plus reproductible.

Organiser le traitement des données GNSS dans QGIS

L’importation ponctuelle est simple. La difficulté apparaît lorsque les fichiers arrivent régulièrement, depuis plusieurs opérateurs ou plusieurs équipements. À ce moment, le sujet devient une question d’architecture de données.

Un modèle minimal peut séparer:

• une couche de positions brutes, conservée comme référence d’acquisition;
• une couche nettoyée, destinée aux contrôles et aux corrections;
• une couche métier, enrichie par les codes, statuts et observations;
• une table de métadonnées décrivant la campagne, l’opérateur, la date et le matériel;
• une couche de publication, simplifiée pour la carte ou l’application.

Cette séparation évite de modifier directement la donnée source et facilite la reprise d’un traitement. Elle permet également de comparer les versions, de retrouver l’origine d’un point et de documenter la transformation appliquée entre le fichier reçu et la couche publiée.

La structure attributaire doit rester stable. Les champs doivent avoir un nom explicite, un type cohérent et une longueur suffisante. Les codes métier ne devraient pas être saisis librement lorsqu’ils doivent alimenter des requêtes, des filtres ou des formulaires de collecte. Une liste de valeurs contrôlées réduit les variantes d’écriture et améliore l’interopérabilité entre QGIS, les applications terrain et les bases de données spatiales.

La topologie intervient ensuite selon la nature du levé. Pour des points, on cherchera par exemple les doublons ou les positions anormalement proches. Pour des lignes, on contrôlera les ruptures, les géométries invalides ou les séquences incohérentes. Pour des polygones issus d’une numérisation ou d’un levé, les recouvrements et les lacunes doivent être traités avec des règles adaptées au modèle métier.

L’automatisation peut être introduite progressivement. Un modèle de traitement QGIS ou un script peut enchaîner l’import, la normalisation des champs, la transformation du CRS, la création de la dimension Z et l’export vers le GeoPackage. L’intérêt n’est pas de supprimer toute intervention humaine, mais de rendre les étapes répétitives identiques d’une campagne à l’autre.

Une procédure courte, mais contrôlée

Pour un fichier GNSS courant, la séquence suivante couvre la plupart des besoins:

1. Identifier le format et son origine. Un GPX, un CSV et un fichier NMEA ne suivent pas la même chaîne d’import.

2. Inspecter la structure avant l’ouverture. Relever les noms de colonnes, le séparateur, le séparateur décimal, les éventuels champs d’altitude et les informations de date.

3. Importer dans QGIS avec le CRS source. Pour des coordonnées GPS en latitude/longitude, le WGS84, EPSG:4326, est généralement le point de départ; pour des coordonnées métriques françaises, le Lambert-93, EPSG:2154, peut être adapté lorsque c’est bien le référentiel fourni.

4. Contrôler l’emprise et l’ordre X/Y. Une couche qui s’affiche n’est pas nécessairement une couche correctement positionnée.

5. Vérifier la dimension Z. Déterminer si l’altitude est un attribut ou une composante géométrique réellement exploitable.

6. Nettoyer les attributs. Corriger les valeurs vides, les types de champs, les caractères parasites et les incohérences de codification.

7. Exporter vers un format permanent. Le GeoPackage est généralement plus adapté au travail quotidien que le fichier d’échange initial.

8. Documenter la transformation. Conserver le format d’origine, le CRS source, le CRS de sortie et les traitements appliqués.

Cette procédure est rapide parce qu’elle élimine les corrections tardives. Une erreur de CRS détectée après plusieurs jointures spatiales ou plusieurs exports peut contaminer toute la chaîne. À l’inverse, un contrôle d’emprise effectué immédiatement permet d’arrêter le traitement avant que la mauvaise interprétation ne se propage.

La bonne architecture vaut mieux qu’une conversion de dernière minute

L’importation de données GNSS dans QGIS n’est pas seulement une opération de lecture de fichier. C’est une interface entre un système d’acquisition, un format d’échange et un modèle de données géographiques. Chaque couche du flux a sa responsabilité: le récepteur produit la mesure, le logiciel de conversion structure le fichier, QGIS contrôle et transforme la donnée, puis la base spatiale organise son exploitation.

Pour un usage ponctuel, l’import direct d’un GPX ou d’un CSV suffit, à condition de paramétrer correctement le CRS, les champs de coordonnées et les séparateurs. Pour un projet topographique récurrent, la conversion vers un GeoPackage, la conservation de la donnée brute et la standardisation des attributs deviennent rapidement nécessaires.

La méthode la plus fiable reste donc la plus explicite: charger dans le référentiel d’origine, vérifier la géométrie, traiter séparément l’altitude, reprojeter au moment de l’export et conserver une structure stable. QGIS fournit les outils nécessaires; la qualité du résultat dépend surtout de la cohérence du modèle relationnel et de la discipline appliquée au flux de données.