OpenCPN, CM93 Offsets Avertissement du site officiel
http://opencpn.org/ocpn/CM93_Offsets
- “There is absolutely no guarantee that a correction, based on one point, as described below, will be valid for the whole chart cell. Be very careful when using this feature.”
- “Il n’y a absolument aucune garantie qu’une correction, basée sur un point, tel que décrit ci-dessous, soit valable pour l’ensemble des cellules de la carte. Soyez très prudent lorsque vous utilisez cette fonction.”
Et pourtant ils l’ont fait. Pourquoi compenser des données géodésiques d’une carte ??? Y aurait il un problème spécifique aux CM93 ???
Comment OpenCPN lit-il les compensations ???
Pour obtenir le menu contextuel de compensation depuis un point sur la carte : |
![]() |
Lexique
- Pour l’ajustement du réglage des cellules
- |03820080 : n° de la cellule CM93
- M_COVRD ID : identification d’un n° d’ordre dans une cellule
- WGS X : valeur géodésique compensée en latitude
- WGS Y : valeur géodésique compensée en longitude
- Perso X : valeurs géodésique que l’on entrera manuellement
- Perso Y : valeurs géodésique que l’on entrera manuellement
- Réglages personnel X et Y : fenêtre de saisie des valeurs
- OK (non montré sur cette copie d’écran) : validation
- Pour le contrôle des objets des données cartographiques (voir copie d’écran sur les objets présents, ci-après)
- Pré-requis :
- activation de la case “information relative aux objets” dans l’onglet “Cartes vectorielles” de la boite à outil
- Par un clic gauche sur la carte => (M_COVR) : objet défini par l’OHI, décrivant les attributs de cette zone
- Attributs de (M_COVR) :
- (HORDAT) : système géodésique appliqué (2) correspond aux WGS 84
- (_sorhd) : source du système géodésique compensé, ici (3) = EU50
- (_wgsox) : valeur en latitude compensée depuis EU50 vers WGS84
- (_wgsoy) : valeur en longitude compensée depuis EU50 vers WGS84
- (MARSYS) : système de balisage
- (CSCALE) : échelle de digitalisation
- (_dgdat) : date de digitalisation de la carte
- (SORIND) : indication de la source cartographique
- Pré-requis :
![]() |
- Exemple de compensation
Cellule non compensée | Même cellule après compensation |
---|---|
![]() |
![]() |
La trace est juste | La trace est juste |
La géodésie de la carte est fausse | Compensée manuellement, la géodésie de la carte est juste |
Compensation, ce que nous expliquent les auteurs d’OpenCPN :
- Les CM93 s’organisent en couches aux échelles en principe homogènes, dans l’ordre :
- Zones Z : échelle 1:20 000 000 surface 40° x 40°, homogènes
- Zones A : échelle 1:3 000 000 surface 20° x 20°, homogènes
- Zones B : échelle 1:1 000 000 surface 10° x 10°, échelles hétérogènes, mais surfaces homogènes
- Zones C : échelle 1:200 000 surface 2° x 2°, hétérogènes elles peuvent être fragmentées et identifiées par une ID d’identification
- Zones D : échelle 1:100 000, très hétérogènes, elles peuvent être fragmentées et identifiées par une ID d’identification
- Zones E : échelle 1:20 à 30 000, échelle et surface hétérogènes
- Zones F : échelle 1:20 000, échelle et surface hétérogènes
- Zones G : échelle 1:5 000, échelle et surface hétérogènes
La digitalisation ne se fait qu’après accord avec les Services hydrographiques nationaux. Mais là aussi c’est très hétérogène, et l’origine des cartes des services hydro nationaux peuvent venir d’autres services hydro, dont certains relevés datent du XIXème siècle.
De ce fait, des données numérisées avec un service hydro donné, pour une région géographique donnée, à un échelle donnée, resteront cohérentes entre elles pour une échelle donnée, si elles ont pour origine un système géodésique commun. Si ce système géodésique est WGS84, adopté et recommandé par l’OHI. Ce sera parfait, il n’y aura pas besoin de compensation.
Si, le système géodésique est différent, il faudra alors donner des indications de compensation, pour que le programme de cartographie, OpenCPN dans ce cas, lise et compense ces informations, pour les ramener au standard WGS84. Ce sont ces informations que l’on peut lire avec le menu contextuel des objets et l’affichage de l’objet (’M_COVR) et de ses attributs, comme indiqué en début de ce dossier.
Mais il n’y a pas que le décalage géodésique qui entre en compte. si dans les grands pays développés, les services hydrographiques nationaux sont homogènes dans leur archivage de cartes, on peut trouver de grandes différences dans la plus part des pays peu développés. Le problème pour un éditeur de cartes vectorielles, sera alors de négocier avec plusieurs services hydrographiques ; et d’assembler un patchwork de morceaux de cartes d’origines différentes. ce qui explique les trois cas de figures ci-dessous.
- Dans le 1er cas, la baie de Seine, toutes les origines viennent du SHOM et de l’UHKO en WGS84 : les zones sont homogènes et régulières
- Dans le 2ème cas, celui de l’île de Karaman, les origines viennent du SHOM, de l’UHKO et des services italiens, les zones restent assez homogènes, les services hydrographique locaux (Yémen), ne perturbant pas les données
- Dans le 3ème cas, celui de Bodrum, on traite des données d’origines anglaise, américaine, française, italienne, grecque et... turque. ces deux dernières fournissant des informations de levés anciens, récupérées auprès des services italiens et anglais... Au résultat ; un patchwork impressionnant.
Découpe de zone en baie de Seine | Découpe de zone Mer Rouge (Karaman) | Découpe de zone en Turquie (Bodrum) |
---|---|---|
![]() |
![]() |
![]() |
Le tricotage des zones se fera par couches. La présentation sur l’écran montrera la couche en adéquation avec le niveau de zoom. Or, il s’agit d’un mille feuilles de cellules, reclassées par zones, ces zones homogènes pour une couche données, ne le seront pas, à la verticale d’un même point, avec les zones des autres couches.
Conséquences du tricotage des zones
Ce qui signifie qu’à la verticale d’un point géodésique précis, on pourra trouver autant de compensations que de cellules empilées sur les différentes couches.
Dans ces conditions :
- Soit les compensations automatiques, sont fiables parce que les systèmes géodésiques d’origines sont fiables
- Soit ces compensations sont fausses parce que les systèmes géodésiques d’origines sont exotiques, voire douteux...
- Soit l’un ou/et l’autre, ajoutés aux risques d’un relevé ancien, avec des moyens manquant de précision, ou/et, c’est fréquent, un manque de rigueur dans le traitement des informations cartographiques. Manque de rigueur pouvant venir du service qui numérise la carte, des services cartographiques d’origine, ou des services cartographiques de première main, dont se sont servis les précédents...
- Or... le tout peut être sujet à caution. Au résultat, il est prudent de ne pas se fier les yeux fermés à une carte électronique, quelque soit l’éditeur, mais aussi des cartes papiers, dont au final on a peu de moyens de contrôle physique de leur exactitude...
Il est évident que le risque d’erreur est d’autant plus faible, que la zone ciblée est fréquentée. Qui plus est, si elle est fréquentée par des cargos d’une région “riche en dollars”. C’est extrêmement parlant si on considère les relevé, donnés pour les Dardanelles, précis au mètre près, et à peine 40 milles, ceux de Moudhros, dans l’île grecque de Limnos, décalée de 110 m vers le 70°
Exemple d’imbrication de zones : Pythagorion dans le détroit de Samos
Pour atterrir à Pythagorion, un navigateur partant d’Antalya ; soit un plus de 250 milles, devra gérer 31 zones de compensation géodésique, ayant pour origine (SORIND) 18 cartes différentes, aucune n’étant homogène
Les contrôles hydrographiques dans les pays “dits industrialisés”
Contrôles sur le terrain
Plus un service hydrographique national apportera de soins à ses contrôles, plus on aura de chance de trouver des données correctement compensées. En exemple de la qualité et de la fiabilité dans nos eaux : une série de cartes en atlantique et en méditerranée français, cartographiés par le SHOM, et, contre exemple, une série de cartes aux origines multiples pour le détroit de Samos.
Conclusions
La comparaisons entre les versions 1999 et 2011, sur l’Atlantique et la Méditerranée français, indiquent clairement que les cartes du SHOM étaient correctement géo référencées que ce soit en EU50 ou en WGS84. Les fusions/transparences montrent que le trait de côte a été bien levé. Après de multiple sondages, il apparaît qu’il en est de même, chez les allemands, les anglais, les américains, les portugais, etc... du moins, sur leurs côtes...
Lisbonne | Penzance | Kiel | Delaware |
![]() |
![]() |
![]() |
![]() |
Si les levés sont justes, si les digitalisations ont été menées avec soin, si le maillage C-map est correcte alors, dans la plus part des régions ouest européennes ou nous naviguons, les C-map récentes seront fiables, et il n’y aura pas besoin de compensation géodésique manuelle ;
Si on considère une navigation plus lointaine, dans des eaux peu fréquentées, alors, le risque d’erreur est grand. Soit que les levés soient anciens et approximatifs, soit que les références géodésiques d’origines soient mal définies, soit que la maillage devenue tellement complexe prête à un risque d’erreur lors de la numérisation des CM93... alors, il n’existe qu’une solution fiable, c’est un contrôle par des fusions transparences. Ce type de contrôle permettra de plus ; une mise à jour des infrastructures plus récente par Google Earth, que par C-map...
Dans le cas de figure ou tout est faux, ou pire, partiellement juste... Espérer rétablir une fiabilité, en compensant manuellement cellule par cellule, sans avertissement à postériori (rien ne vous indiquera à l’écran qu’une cellule a été compensée) ; relève d’une naïveté peu compatible avec le sens marin... C’est probablement ce qu’à voulu indiquer le développeur du projet dans ses réserves mises en exergue au début de ce dossier...
Les liens utiles
- Documentation OHI
- Etat des levées et de la cartographie marine à travers le monde
- Relevé de surveillance des levés hydrographiques
- Liste et index des différents systèmes géodésiques (index donné par l’attribut « _sorhd » , indiquant le système géodésique d’origine)
- Les limites des CM93
- Les techniques de fusion/transparence du logiciel GE2KAP
- Forum techniques
s/y Laorana Finike Turquie février 2013