Parmi les outils SIG, il est rare de trouver le support des formats de marine et militaire. Dans cet article, je vais vous présenter l’un d’entre eux, ainsi que sa symbologie associée.
1. Les spécifications de l’OHI
L’Organisation Hydrographique Internationale a publié une grande quantité de documents et de spécifications pour les capteurs, la sécurité, la symbologie et les formats vecteurs ou raster. La liste complète est disponible sur http://www.iho.int/iho_pubs/IHO_Download.htm
Dans cet article, nous allons regarder en particulier deux des spécifications les plus utilisées :
- S-57 : le format de données vecteurs
- S-52 : la symbologie des cartes marines
Ces deux spécifications sont les principales utilisées par les systèmes ECDIS. ECDIS signifie Electronic Chart Display and Information System (Système de visualisation des cartes électroniques et d’information), pour faire simple, tout bateau de taille moyenne, ou plus, est équipé avec ce type de système. Il permet d’afficher des informations comme, la position du bateau, le trait de côte, la bathymétrie, les phares, les bouées, les zones interdites, les routes de navigation ,etc.
2. Le format vecteur S-57
Le format lui-même est long à décrire, la spécification et ses annexes approchant le millier de pages.
Donc, voici les principales caractéristiques du format :
- Encodage de type ASCII entrecoupé de délimiteurs Non-ASCII
- Support des géométries spaghetti, chainées et topologiques
- Support de la gestion de version et des mises à jour incrémentales
- Support du partionnement géographique sur plusieurs fichiers
- Types d’Enregistrements et de champs sous forme de tables
- De nouveaux types d’enregistrements et de champs peuvent être définis dans d’autres documents ou être ignorés
- Les enregistrements peuvent porter leur procédures de rendu
Comme vous pouvez le voir, S-57, dans sa version 3, a de nombreuses propriétés intéressantes que l’on ne trouve pas dans les formats usuels SIG. Bien qu’il soit ancien (1996) et qu’il n’utilise pas de technique de compression avancée, les fichiers sont très compacts et quelques kilo-octects contiennent une quantité considérable de données. Même si le format supporte la topologie durant les dernières années, je n’ai pas rencontré de fichier qui l’utilise. Je suppose que ce dernier modèle interne est trop compliqué à manipuler et à encoder pour les producteurs de données.
La spécification de base contient environ 150 types d’enregistrements différents et 200 champs.
Avec les extensions Additional Military Layers (AML) et Mariner, on arrive à plus de 250 types et 500 champs.
Coté implémentation, nous avons converti les types d’enregistrements en Feature Type OGC et les champs en Attributes, en suivant les interfaces de la librairie OGC GeoAPI. Il n’y a pas de perte lors de la conversion.
Voici un exemple visuel du fichier : US4CA60M (2Mo)
Il y a tellement d’informations qu’il est difficile de comprendre ce que l’on regarde.
3. La symbologie S-52
Comme on vient de le voir, S-57 est très dense et sans symbologie appropriée, l’utilisateur est perdu dans les données, c’est le problème que va résoudre S-52.
Pour être capable d’afficher la symbologie S-52, nous avons utilisé l’API extensible du moteur de rendu 2D. Quand vous créez un style, au lieu d’utiliser des PointSymbolizer, LineSymbolizer et PolygonSymbolizer OGC, nous avons ajouté un S52Symbolizer. Cette API a permis de définir ce nouveau symbolizeur et son stockage dans un fichier OGC SLD.
Pour ceux qui utilisent SLD, voici à quoi ressemble ce nouveau symbolizeur :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <sld:UserStyle xmlns:se="http://www.opengis.net/se" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:sld="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:ns6="http://geotoolkit.org" xmlns:ns8="http://www.opengis.net/gml/3.2"> <se:Description> <se:Title></se:Title> <se:Abstract></se:Abstract> </se:Description> <sld:IsDefault>false</sld:IsDefault> <se:FeatureTypeStyle> <se:Description> <se:Title></se:Title> <se:Abstract></se:Abstract> </se:Description> <se:Rule> <se:Description> <se:Title></se:Title> <se:Abstract></se:Abstract> </se:Description> <se:MinScaleDenominator>0.0</se:MinScaleDenominator> <se:MaxScaleDenominator>1.7976931348623157E308</se:MaxScaleDenominator> <ns6:S52Symbolizer> <Configuration> <DisplayChartCategory>STANDARD</DisplayChartCategory> <DisplayMarinerCategory>MARINERS STANDARD</DisplayMarinerCategory> <Palette>DAY</Palette> <AreaLookupTable>PLAIN_BOUNDARIES</AreaLookupTable> <LineLookupTable>LINES</LineLookupTable> <PointLookupTable>SIMPLIFIED</PointLookupTable> <NoText>false</NoText> <SafetyDepth>30.0</SafetyDepth> <ShallowContour>2.0</ShallowContour> <SafetyContour>30.0</SafetyContour> <DeepContour>30.0</DeepContour> <LowAccuracySymbol>false</LowAccuracySymbol> <TwoShade>true</TwoShade> <ShallowPattern>false</ShallowPattern> <ShipOutline>false</ShipOutline> <ContourLabel>true</ContourLabel> <SafetyContourLabel>true</SafetyContourLabel> <TimeTag>0.0</TimeTag> <FullSector>true</FullSector> <LightDescription>false</LightDescription> <DangerShallowWater>false</DangerShallowWater> <AnalyzeDepth>0.0</AnalyzeDepth> <ScaleFilter>true</ScaleFilter> </Configuration> </ns6:S52Symbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle>
Pourquoi ne pas remplacer S-52 complètement par le classic OGC Symbology Encoding et les fichiers SLD ?
La raison est simple : le SLD ne peut pas se substituer à S-52. Il serait capable de remplacer peut être 80% de S-52, mais, pour beaucoup de raisons, cela produirait un fichier de style très complexe, plein d’expressions et de fonctions. Plus compliqué encore, S-52 s’appuie sur des relations entre les éléments. Par exemple, les récifs n’ont pas la même icône s’ils sont en eau profonde ou peu profonde, cela implique de connaître ce qu’il y a exactement en dessous de chaque récif et ce qu’ils intersectent. Les phares affichent des rayons/secteurs multiples avec des distances réelles et de nombreuses procédures de rendu sont tout simplement impossibles à exprimer en SLD avec des filtres et des conditions.
Voici ce que S-52 appelle une procédure, (et ce n’est là, que la moitié de la procédure LIGHTS05) :
Changeons maintenant le style de la donnée précédente, on obtient :
C’est bien plus lisible et ce n’est que la configuration de base, il y a beaucoup de propriétés configurables comme la taille du texte, la couleur, la palette, les éléments visibles,etc.
Parmi toutes les propriétés, S-52 définit les palettes : JOUR, CREPUSCULE et NUIT qui sont étudiées pour assurer une bonne visibilité en faible ou en absence de lumière. L’image ci-dessus en mode crépuscule donne ceci :
4. L’éditeur de style
Parmi les multiples prérequis des systèmes ECDIS, il y en a un sur les interfaces utilisateurs. L’utilisateur doit être capable d’ajuster le rendu, la visibilié des textes, leur tailles, les types d’objets affichés ou encore des informations sur son bateau qui peuvent avoir un impact sur le rendu.
A côté de la configuration, un certain nombre d’informations doivent être accessibles à l’utilisateur comme le catalogue des symboles S-52 et leur signification.
Pour remplir cet objectif, l’éditeur de SLD a été étendu avec un éditeur S-52 pour tous ces éléments.
- Paramètres généraux
- Filtres des types de feature
- Palette de couleurs
- Catalogue des symboles
5. Conclusion
Les outils de marine et leurs formats ont beaucoup en commun avec ceux des SIG ; bizarrement, ces deux mondes sont encore séparés, non pas à cause des formats, mais des communautés qui sont bien distinctes. Les cartes ECDIS sont auto-suffisantes, elles n’ont pas besoin d’être complétées avec des données additionnelles, contrairement au domaine SIG classique où mélanger les données de diverses sources est un De Facto. A cause de cela, les utilisateurs ECDIS ont seulement besoin de mettre à jour leurs données auprès de leur fournisseur habituel et c’est tout.
Comparé à du GML, du KML, une Geodatabase ou du shapefile, le S-57 est largement supérieur. Il est peut être ancien, mais son modèle est plus avancé et résout plusieurs des problèmes que l’on a aujourd’hui en SIG avec la gestion des versions, la topologie et le tuilage. Si S-57 était nettoyé en utilisant les derniers algorithmes et techniques d’encodage, il remplacerait l’ensemble des formats de fichier SIG vecteur sur de nombreux points.
S-52, lui est plus que complexe mais, il est le résultat de décennies d’expériences de marins sur la symbologie marine et est devenu un De Facto au niveau international, pour les cartes de navigation marine. Styler plus de deux cents types de features sur différentes échelles et rassembler toutes les procédures de rendu a dû demander un travail de plusieurs années. En tant que spécialiste SIG et développeur je ne peux qu’admirer le résultat.
J’espère que vous aurez apprécié l’article 😉
