Traitement GNSS sur RTKLib : la marche à suivre

Traitement GNSS sur RTKLib: la marche à suivre

La difficulté se situe en amont: fichiers bruts mal identifiés, observation de base absente, système de coordonnées incomplet, éphémérides incompatibles ou calibration d’antenne oubliée. Dans ce cas, RTKPOST peut produire un fichier de résultat, mais celui-ci ne constitue pas nécessairement une solution géodésique exploitable.

RTKLIB est un logiciel libre conçu pour convertir, contrôler et post-traiter des observations GNSS selon plusieurs approches: DGNSS, statique, cinématique PPK et PPP. Son fonctionnement repose principalement sur deux modules: RTKCONV, qui prépare les fichiers d’observation, et RTKPOST, qui calcule les positions à partir du mobile, de la base et des données de navigation. La logique est claire à condition de respecter l’ordre des opérations.

Le flux de données commence par une conversion propre

La première étape consiste à transformer les fichiers natifs du récepteur en formats que RTKLIB peut interpréter de manière homogène. Selon le constructeur, les données peuvent être livrées dans un format propriétaire, dans un fichier binaire ou déjà sous forme de fichiers d’observation. RTKCONV sert précisément à convertir ces données brutes en fichiers RINEX.

Cette conversion n’est pas une formalité administrative. Elle détermine la manière dont les observations seront ensuite identifiées: code, phase porteuse, fréquence, époque d’enregistrement et constellations disponibles. Une erreur à ce stade se répercute sur toute la chaîne de traitement, généralement sans produire un message suffisamment explicite pour permettre un diagnostic immédiat.

RTKLIB prend en charge les formats RINEX 2.10 à 2.12 ainsi que les versions 3.00 à 3.02. Il accepte également plusieurs versions de RTCM — 2.3, 3.1 et 3.2 — ainsi que BINEX et NMEA 0183. Cette compatibilité est utile lorsque les levés proviennent de récepteurs, de stations permanentes ou de chaînes d’acquisition différentes. Elle ne dispense toutefois pas de vérifier la cohérence des fichiers: deux fichiers lisibles par le logiciel ne sont pas nécessairement adaptés au même calcul.

Ce qu’il faut examiner dans RTKCONV

Dans RTKCONV, le fichier source doit être sélectionné avec précision, puis les paramètres de conversion doivent être contrôlés avant de lancer l’export. L’objectif n’est pas seulement d’obtenir un fichier portant l’extension .obs, mais de conserver une observation suffisamment complète pour le mode de positionnement visé.

Un flux de conversion cohérent comprend généralement:

• un fichier d’observation du récepteur mobile, qui deviendra le fichier Rover;
• un fichier d’observation de la station de base lorsque le calcul est différentiel ou relatif;
• un ou plusieurs fichiers de navigation, contenant les éphémérides radiodiffusées;
• éventuellement des fichiers d’éphémérides précises au format SP3 et des fichiers d’horloge au format CLK;
• les informations permettant d’identifier l’antenne, sa hauteur et son point de référence.

Le fichier d’observation ne doit pas être confondu avec le fichier de navigation. Le premier contient les mesures réalisées par le récepteur; le second décrit les paramètres orbitaux et temporels nécessaires au calcul de la position des satellites. Pour un post-traitement PPK ou statique, RTKPOST doit disposer des observations du mobile, des observations de la base et d’au moins un fichier de navigation, qu’il soit radiodiffusé ou issu d’éphémérides précises.

Un fichier RINEX correctement converti n’est pas encore une solution GNSS: c’est une structure d’observations prête à être interprétée.

Le contrôle doit aussi porter sur les dates et les intervalles temporels. Un fichier Rover enregistré de 10 h 00 à 10 h 30 ne pourra pas être correctement combiné avec une base dont les observations commencent à 10 h 45. Les fichiers peuvent être techniquement valides tout en étant inutilisables ensemble. Dans une architecture de données géospatiales, cette correspondance temporelle joue le même rôle que la clé de jointure dans un modèle relationnel: sans elle, les informations ne s’assemblent pas correctement.

RTKPOST: configurer le calcul avant de chercher la précision

RTKPOST constitue le centre du traitement. Il reçoit les fichiers préparés, applique les paramètres de positionnement et produit les coordonnées calculées. Le logiciel permet notamment de travailler en mode Single, DGNSS, Static, Kinematic ou PPP selon la configuration retenue et les données disponibles.

Le choix du mode doit être fait avant de renseigner tous les champs, car l’interface adapte certains paramètres à cette sélection. En particulier, le champ destiné au fichier d’observation de la base n’est actif que lorsqu’un mode différentiel ou relatif, comme Static ou Kinematic, est sélectionné. Si ce champ reste inactif, il ne s’agit pas nécessairement d’un dysfonctionnement: le mode choisi ne sollicite simplement pas cette donnée.

Les fichiers à associer

Pour un traitement cinématique PPK avec RTKLIB, la structure minimale est la suivante:

Cette organisation permet de comprendre pourquoi un traitement échoue. Si le Rover est présent mais que la base ne l’est pas, le calcul ne peut pas être présenté comme un PPK relatif complet. Si les observations sont disponibles mais qu’aucun fichier de navigation ne couvre la période du levé, RTKPOST ne dispose pas des informations nécessaires pour positionner les satellites. Si les coordonnées de la base sont approximatives ou exprimées dans un référentiel différent de celui attendu, la solution peut être numériquement calculée tout en restant géométriquement incohérente.

Le fichier de base doit donc être sélectionné explicitement dans RTKPOST, après avoir choisi le mode Static ou Kinematic. Le fichier Rover et celui de la base doivent couvrir une période commune, avec des observations réellement exploitables sur les mêmes satellites et les mêmes fréquences. Une simple proximité temporelle ne suffit pas: les données doivent se recouvrir pendant la durée utile du calcul.

Les paramètres qui structurent la solution

La fenêtre de configuration regroupe plusieurs familles de paramètres. Il est préférable de les traiter comme des couches indépendantes plutôt que de modifier tous les champs simultanément:

1. Le mode de positionnement détermine la nature du calcul: solution autonome, différentielle, statique, cinématique ou PPP.

2. La fréquence et les constellations définissent les observations effectivement exploitées par le moteur de calcul.

3. La stratégie de résolution des ambiguïtés influence le passage d’une solution flottante à une solution fixée, lorsque les observations le permettent.

4. Les seuils de qualité encadrent l’acceptation des positions et la détection des incohérences.

5. Le système de coordonnées permet de relier les résultats calculés au référentiel de production.

6. Les paramètres d’antenne et de station corrigent la géométrie réelle de l’installation.

La tentation consiste souvent à rechercher le réglage qui donne immédiatement le plus grand nombre de positions « fixées ». Ce critère est insuffisant. Une solution fixée n’est pertinente que si elle repose sur des observations cohérentes, une base correctement définie, une bonne calibration d’antenne et une géométrie satellite favorable. Le post-traitement GNSS n’est donc pas une compétition entre paramètres; c’est une chaîne de dépendances.

Base, antenne et éphémérides: les données qui déterminent la géométrie

La précision centimétrique ne dépend pas uniquement de la qualité du récepteur. Dans RTKPOST, les coordonnées de la station de base doivent être définies avec suffisamment de précision et dans le bon référentiel. La hauteur d’antenne doit également être cohérente avec le point réellement mesuré: repère physique, point de référence de l’antenne ou autre origine utilisée par le constructeur.

Une base mal positionnée introduit une erreur systématique dans les coordonnées du Rover. Le résultat peut sembler stable, présenter une trajectoire régulière et même fournir des indicateurs favorables, tout en étant décalé par rapport au contrôle terrain. Dans un projet topographique, cette erreur est particulièrement coûteuse car elle se propage ensuite dans les couches SIG, les plans DAO et les livrables de contrôle.

Le rôle des fichiers de calibration

Les fichiers de calibration d’antenne décrivent les variations du centre de phase selon l’élévation et l’azimut des satellites. RTKLIB peut utiliser des fichiers ANTEX au format .atx ou des données NGS PCV. Leur configuration doit précéder le calcul lorsque l’objectif est d’obtenir une précision décimétrique à centimétrique selon le mode et la durée d’observation.

Sans calibration adaptée, la position calculée peut intégrer des biais liés au comportement de l’antenne. Ce problème devient plus sensible lorsque le Rover et la base utilisent des modèles d’antenne différents, lorsque les angles d’élévation sont faibles ou lorsque l’on cherche à comparer des résultats issus de plusieurs campagnes.

La description de l’antenne ne doit pas être traitée comme un simple attribut documentaire. Elle intervient dans le modèle d’observation et doit correspondre au matériel effectivement utilisé. Une référence générique ou une antenne inconnue peut rendre la correction moins pertinente, même si le fichier RINEX a été correctement produit.

Choisir entre éphémérides radiodiffusées et précises

Les éphémérides radiodiffusées sont généralement associées aux fichiers de navigation issus de l’acquisition GNSS. Elles permettent les traitements courants, notamment lorsque les exigences de précision et la durée d’observation restent compatibles avec ce niveau de donnée.

Les éphémérides précises au format SP3, éventuellement accompagnées de fichiers d’horloge CLK, peuvent être utilisées pour des traitements nécessitant une modélisation orbitale et temporelle plus fine, notamment dans des scénarios PPP. Elles doivent cependant couvrir la période d’observation et être associées au bon ensemble de données. Leur présence dans un dossier ne garantit pas qu’elles seront effectivement exploitées par RTKPOST.

Le choix des éphémérides doit donc être lu avec le mode de calcul. Pour une base et un Rover observant simultanément les mêmes satellites, le traitement relatif bénéficie de la corrélation des erreurs communes. Pour un calcul autonome ou PPP, la dépendance aux modèles orbitaux, aux horloges et aux autres corrections devient différente. Il n’existe pas de fichier universel qui compenserait une configuration incomplète.

La précision n’est pas une propriété isolée du fichier de sortie: elle résulte de l’alignement entre observations, géométrie, référentiel, antennes et modèle de calcul.

PPK, statique et PPP: des objectifs différents

Les modes de traitement ne se distinguent pas seulement par leur nom. Ils correspondent à des géométries d’acquisition et à des objectifs de production différents.

Le mode statique

En statique, le récepteur reste immobile pendant la session d’observation. Cette configuration fournit une série temporelle sur une même station, ce qui permet au calcul d’exploiter la redondance des observations. La durée utile dépend du contexte, de la distance à la base, de la visibilité des satellites et du niveau de précision recherché.

Le mode statique est adapté à la détermination ou au contrôle de points fixes. Il est moins pertinent pour une trajectoire de levé dans laquelle le récepteur se déplace continuellement. Le fichier Rover contient alors une observation d’une station immobile, tandis que le fichier de base doit couvrir la même période si l’on réalise un calcul relatif.

Le mode cinématique PPK

Le PPK, ou cinématique en post-traitement, vise à reconstruire la trajectoire d’un récepteur mobile après l’acquisition. Le calcul compare les observations du Rover à celles d’une base ou d’une station de référence, avec des données temporellement compatibles.

Dans RTKPOST, le mode Kinematic doit être associé au fichier d’observation de la base. Sans ce fichier, le processus ne doit pas être décrit comme un traitement PPK différentiel complet. Cette contrainte est structurante: le Rover seul permet éventuellement une solution d’un autre type, mais il ne fournit pas la référence nécessaire à la résolution relative des ambiguïtés.

Le PPK est particulièrement utile lorsque la liaison temps réel n’était pas disponible ou lorsque l’on souhaite reprendre les paramètres après le levé. Il conserve aussi l’intérêt opérationnel d’une acquisition terrain découplée du calcul: les décisions de traitement peuvent être réévaluées à partir des fichiers bruts, à condition que ceux-ci aient été enregistrés correctement.

Le mode PPP

Le PPP, ou positionnement ponctuel précis, ne repose pas sur une base locale de la même manière qu’un calcul relatif. Il s’appuie sur des produits et des modèles précis, notamment les éphémérides et les corrections d’horloge appropriées. Les attentes en matière de précision, de convergence et de stabilité doivent donc être différenciées de celles d’un PPK court avec base proche.

Présenter tous les modes comme interchangeables crée une confusion fréquente dans les projets SIG. Un fichier traité en Single ne devient pas centimétrique par le simple fait d’être importé dans RTKLIB. De même, l’emploi du terme PPP ne garantit pas un résultat immédiat au niveau du centimètre: la qualité des observations, la durée de la session et les produits utilisés restent déterminantes.

Lire un fichier.pos sans le confondre avec une carte

RTKPOST exporte les résultats dans un fichier texte portant l’extension .pos. Ce fichier constitue la sortie structurée du calcul. Il peut être visualisé dans RTKPLOT ou réutilisé dans des outils SIG et DAO, mais il ne doit pas être considéré comme une couche cartographique prête à publier.

Le fichier .pos contient les positions calculées ainsi que des informations associées à la solution. Selon le mode de traitement et la configuration, il permet d’examiner la chronologie des points, les coordonnées, le statut de résolution et les indicateurs de qualité. L’analyse doit porter sur la continuité et la cohérence de l’ensemble, pas uniquement sur quelques lignes sélectionnées.

Les contrôles à réaliser après le calcul

Une lecture structurée du résultat peut suivre cette séquence:

• Vérifier l’emprise temporelle: les premières et dernières époques doivent correspondre à la période réellement observée, sans trou inattendu dans la trajectoire.
• Examiner le statut des solutions: une alternance excessive entre solutions flottantes et fixées peut indiquer des pertes de cycle, une visibilité dégradée ou une configuration trop permissive.
• Repérer les ruptures spatiales: un saut de position isolé doit être comparé à l’évolution temporelle et aux observations correspondantes.
• Contrôler le référentiel: l’import dans un SIG ou une DAO doit utiliser le système de coordonnées correspondant à celui du calcul.
• Comparer les résultats aller-retour: lorsque le traitement bidirectionnel est utilisé, les écarts entre solutions doivent être examinés plutôt que masqués par une moyenne automatique.
• Conserver les fichiers intermédiaires: les RINEX, paramètres de calcul, fichiers d’antenne et fichiers de navigation permettent de reproduire le traitement.

RTKPLOT facilite l’exploration graphique des résultats. Il peut servir à visualiser une trajectoire, à observer la répartition des solutions et à repérer des séquences anormales. Cette visualisation ne remplace pas le contrôle des métadonnées. Une trajectoire visuellement régulière peut toujours être exprimée dans un mauvais référentiel ou affectée par une erreur de hauteur d’antenne.

L’import dans un logiciel SIG intervient seulement après cette validation. Les coordonnées issues du .pos peuvent alors alimenter une couche de points, une ligne de trajectoire ou une table attributaire, selon le processus métier. Pour une utilisation en topographie, il faut conserver le lien entre chaque position, son époque d’observation et son statut de qualité. Exporter uniquement une liste de coordonnées élimine une partie essentielle de l’information de contrôle.

Résoudre les échecs de traitement par couches successives

Lorsque RTKPOST ne produit pas de solution satisfaisante, modifier simultanément le mode, les seuils, les constellations et les paramètres d’ambiguïtés rend le diagnostic presque impossible. La méthode la plus efficace consiste à remonter la chaîne, du résultat vers les données sources.

Première couche: vérifier les fichiers

Commencez par vérifier que les fichiers Rover, base et navigation couvrent la même période. Contrôlez ensuite les extensions, les noms des stations, les constellations observées et la présence effective des mesures dans les RINEX. Une conversion réussie dans RTKCONV ne garantit pas que les champs nécessaires à la suite du traitement soient complets.

Il faut également distinguer le fichier d’observation de la base d’un simple fichier de navigation ou d’un fichier de coordonnées. RTKPOST attend des observations réelles de la station de référence pour un calcul relatif. Un fichier .nav ne peut pas se substituer à un fichier .obs.

Deuxième couche: vérifier la géométrie

Si les fichiers sont cohérents, examinez les coordonnées de la base, le référentiel et la hauteur d’antenne. Une erreur de quelques unités dans la saisie ou une confusion entre hauteur verticale et hauteur inclinée peut déplacer l’ensemble du résultat sans empêcher le calcul.

La calibration d’antenne doit ensuite être vérifiée. Le fichier .atx ou la donnée PCV doit correspondre au modèle d’antenne et être pris en compte par la configuration. Cette étape est souvent négligée parce qu’elle ne modifie pas l’apparence générale de la trajectoire; elle peut pourtant influer directement sur la qualité des coordonnées.

Troisième couche: vérifier le modèle de calcul

Enfin, revenez au mode choisi et aux données disponibles. Le mode Kinematic suppose une référence adaptée et des observations de base simultanées. Le statique suppose une occupation immobile. Le PPP exige des produits précis compatibles avec la session. Le mode Single, lui, ne doit pas être interprété comme un traitement différentiel capable de fournir à lui seul une précision centimétrique.

Cette hiérarchie évite de transformer un problème de données en problème de réglage. Dans la plupart des chaînes de traitement GNSS, l’optimisation la plus rentable consiste à améliorer la qualité de l’entrée et la traçabilité des métadonnées avant de chercher un paramètre plus sophistiqué.

Organiser RTKLIB dans une chaîne SIG durable

RTKLIB est souvent utilisé comme une application autonome, mais il devient beaucoup plus efficace lorsqu’il est intégré à une architecture de production claire. Les fichiers bruts doivent être conservés séparément des RINEX convertis, des paramètres de calcul et des résultats .pos. Chaque étape doit pouvoir être reprise sans réécrire l’ensemble du flux.

Une organisation simple peut associer à chaque session:

• l’identifiant du chantier et de la journée d’acquisition;
• le rôle du récepteur, Rover ou base;
• le référentiel de travail;
• le modèle d’antenne et la hauteur saisie;
• la version des fichiers de navigation ou d’éphémérides;
• le mode de calcul utilisé;
• le fichier de configuration RTKPOST;
• le résultat .pos et son statut de validation.

Cette structure facilite l’interopérabilité avec les logiciels SIG, les outils de DAO topographique et les applications de collecte terrain. Elle réduit aussi les erreurs de correspondance lorsqu’un même levé doit être recalculé avec une autre stratégie ou intégré dans plusieurs projets.

Le point essentiel est de séparer le calcul GNSS de la mise en forme cartographique. RTKLIB produit des positions et des indicateurs de traitement; le SIG gère ensuite les couches, les attributs, la topologie et les règles de représentation. Mélanger ces responsabilités dans un seul fichier exporté complique les requêtes spatiales et fragilise la reproductibilité.

Dans un environnement automatisé, les fichiers RINEX, .nav, .sp3, .clk, .atx et .pos peuvent également être pilotés par des scripts ou des interfaces de programmation. L’objectif n’est pas d’automatiser aveuglément le calcul, mais de rendre explicites les entrées, les paramètres et les sorties. Une chaîne automatisée qui ne conserve pas sa configuration reste difficile à auditer.

Une procédure fiable pour le post-traitement GNSS

Le traitement de données GNSS sur RTKLIB peut être résumé par une séquence opérationnelle, à condition de ne pas la réduire à une simple suite de clics:

1. Identifier les fichiers bruts et le rôle de chaque récepteur. Déterminez quel fichier correspond au Rover, lequel correspond à la base et quelles données de navigation couvrent la session.

2. Convertir les données avec RTKCONV. Produisez les fichiers RINEX nécessaires et contrôlez leur contenu, leur période et leurs observations.

3. Choisir le mode dans RTKPOST. Sélectionnez Static, Kinematic, PPP ou un autre mode en fonction de la géométrie réelle de l’acquisition.

4. Renseigner le Rover et la base. Pour un traitement relatif ou PPK, associez les observations des deux stations et vérifiez leur recouvrement temporel.

5. Ajouter la navigation ou les produits précis. Utilisez les fichiers .nav, .sp3 et .clk appropriés à la stratégie retenue.

6. Configurer la base et l’antenne. Saisissez les coordonnées, la hauteur et les paramètres de calibration correspondants.

7. Lancer le calcul sans masquer les sorties intermédiaires. Le fichier .pos doit être conservé avec la configuration utilisée.

8. Contrôler le résultat dans RTKPLOT et dans le SIG. Analysez les statuts, les ruptures, le référentiel et la cohérence spatiale avant toute livraison.

Cette procédure ne promet pas une précision identique pour chaque session. Elle garantit en revanche que les causes d’écart restent identifiables. La précision décimétrique à centimétrique dépendra ensuite du mode choisi, de la durée d’observation, de la qualité des signaux, de la distance et de la qualité de la référence, ainsi que de la configuration des modèles.

RTKLIB doit donc être abordé comme un composant de traitement dans une chaîne géospatiale, et non comme une boîte noire capable de transformer n’importe quel fichier récepteur en coordonnées topographiques. RTKCONV prépare les observations; RTKPOST applique un modèle; RTKPLOT aide à interpréter la sortie; le SIG ou la DAO assure ensuite l’exploitation métier.

La méthode la plus robuste est celle qui conserve cette séparation des responsabilités. Lorsque les fichiers, les référentiels, les antennes et les paramètres sont documentés, le post-traitement GNSS devient reproductible, contrôlable et réellement interopérable avec les autres outils de la production topographique.