Avant de commencer voici un aperçu pour vous ouvrir l’appétit et montrer ce qui peut être fait avec 3D Tiles et les données 2D S-57 de navigation maritime.
Etat de la spécification
Le format 3D Tiles existe depuis quelques années maintenant dans le projet CesiumJS. Il évolue aujourd’hui pour devenir un format standardisé désormais supporté par de nombreux moteurs d’affichages 3D.
La spécification est ouverte aux commentaires car elle n’est pas encore officiellement validée par l’OGC : OGC Seeks Public Comment on 3D Tiles Candidate Community Standard
Que peut-on faire avec 3D Tiles ?
DESCRIPTION DU FORMAT
Le format est en réalité davantage une archive comme un Zip plutôt qu’une véritable définition binaire de format.
Il existe 4 types de tuile 3D :
- B3DM : Batched 3D Models
Surement celui que les développeurs et utilisateurs manipuleront le plus. Sa structure est simple et souple. Il encapsule un fichier Khronos GLTF + des ressources en binaire + une table d’attributs pour les features.
Ce seul format de tuile permet de tout faire et il remplace tous les types qui suivent. Cependant, vous aurez à faire vous-même l’OpenGL, le GLSL, la gestion des ressources, les mathématiques de projection géocentrique/géographique et vous devrez batailler avec les limitations de WebGL et les soucis de compatibilité des différents navigateurs.
Tout (dans le limite du format GLTF) peut être dessiné : Billboards, meshes, vidéos, animations, … du moment que vous avez les compétences suffisantes.
- I3DM : Instanced 3D Models
Celui-ci est pratique pour dessiner un même modèle 3D de très nombreuses fois. C’est une version plus haut niveau de ce qu’on trouve en OpenGL sous le nom de “Instanced Rendering” mais pour des modèles complets.
Chaque instance du modèle peut être légèrement modifiée, sa taille ou son orientation par exemple. Vous devriez donc utiliser ce format pour faire : une forêt d’arbres, les panneaux de signalisation, des pylônes électriques…
- PNTS : Point Clouds
Une autre spécialisation du format 3D Tiles pour les nuages de points. Il n’y a que peu de chose à dire sur ce dernier. Si vous avez beaucoup de points à dessiner avec peu de besoin de symbologie, c’est l’idéal ! Il est possible de configurer la couleur de chaque point ainsi que quelques effets de style en JavaScript si vous utilisez CesiumJS. A l’inverse des précédents formats, vous n’aurez pas à faire de GLTF ou d’OpenGL.
- CMPT : Composite
Le type composite existe pour des raisons plus pragmatiques, afin de réduire les temps de chargement et le nombre de requêtes entre le client et le serveur. Il s’agit d’un groupe de tuiles concaténé dans un seul fichier.
Pour organiser l’ensemble, on trouve des fichiers TileSet en JSON qui décrivent les relations entre les tuiles.
QUELQUES PRÉCISIONS
Contrairement à ce qu’on trouve en WMTS et TMS, les tuiles 3D Tiles ne sont pas placées sur une grille régulière et chaque tuile enfant ne remplace pas nécessairement sa tuile parente. L’arbre des tuiles peut avoir n’importe quelle forme. Elles peuvent se superposer, être l’une au-dessus de l’autre, qu’importe, on est ici en 3D ce qui offre beaucoup de liberté.
Par exemple, si vous avez un bâtiment, quand vous êtes très dézoomé, vous aurez une première tuile avec un cube schématisant le bâtiment. A mesure que l’on zoom dessus, une version de la tuile plus précise vient remplacer la précédente, et en zoomant encore une troisième tuile offre un modèle 3D haute résolution du bâtiment avec des textures… C’est le cas classique ! On parle de LOD (Level of Detail) : niveaux de détails successifs.
Prenons un autre scénario, nous devons afficher des flèches de vent. A un niveau très dézoomé on a une tuile qui contient une flèche de vent fort afin de ne pas surcharger la carte et que celle-ci reste lisible. Puis en zoomant une tuile vient s’ajouter, sans remplacer la tuile parent, celle-ci avec des flèches pour les vents moyens, et ainsi de suite. On obtient un raffinement progressif de l’affichage.
Le coté technique de 3D Tiles
- Même si les données sont rendues sur un globe ou un plan, on a l’impression que le format 3D Tiles n’est pas vraiment du domaine de la géomatique. Il y a 2 systèmes de coordonnées : géocentrique et latitude/longitude exprimés en degrés ou en radians. Le format est trop bas niveau pour être manipulé par des géomaticiens seuls. Il va falloir des compétences en programmation pour construire les fichiers et de bonnes connaissances en OpenGL et GLSL afin d’obtenir des résultats flatteurs.
- Pour générer les tuiles vous devrez reprojeter et raffiner les données vous-même. Vous aurez intérêt à être rigoureux dans vos formules mathématiques ou vous ne verrez rien et aucune erreur ne s’affichera. Et si par chance vous en avez une, ce sera très certainement un message d’erreur peu clair fourni par le pilote OpenGL.
- Un autre point technique est que GLTF, GLTF 2.0 (et ses ressources binaires) est encore très récent et les outils de modélisation 3D n’ont pas encore, tous, de fonctionnalité d’export. Quand ils en auront une, les problèmes de compatibilité entre les différents moteurs 3D devraient apparaître de façon plus flagrante. Il y a fort à parier qu’un générateur de tuile 3D quelconque sera compatible avec uniquement un ensemble de moteurs 3D. Quand on voit encore aujourd’hui les soucis de compatibilité avec des formats comme netCDF, grib, geotiff ou jpeg2000, il est à prévoir des soucis identiques avec 3D Tiles.
Espérons que l’OGC mettra en place des suites de tests afin de réduire les différends et améliorer l’interopérabilité.
Et par rapport aux spécifications OGC et ISO ?
Comme le format OGC-KML (ex Google KML), 3D Tiles, en tant que community standard, n’a pas obligation d’utiliser les spécifications existantes de métadonnées, symbologie, services, géométries, filtres ou du CQL.
- Feature : Le concept de Feature étant un élément clé en SIG. On aurait pu s’attendre à ce que la partie feature-table de 3D Tiles qui est en JSON ait un air de GeoJson pusiqu’ils ont vaguement le même objectif (hormis la partie géométrie). Mais, une fois encore, non. Le modèle est très différent. Pour des raisons de performances, les propriétés sont entassées dans de long tableaux inutilisables par un humain.
- Symbologie : Il aurait été plaisant de retrouver les divers éléments de Symbology Encoding comme les règles de styles ou les filtres. Ou encore, de voir apparaître une première utilisation du travail fait par les Working Groups de l’OGC sur la symbologie 3D, pas pour cette fois non plus.
- Géométrie : 3D Tiles est en 3D et mis à part ISO 19107, il n’existe pas de spécification pour définir des géométries 3D. ISO 1907 est tellement complexe et inadapté aux traitements sur GPU qu’on ne peut pas blâmer 3D Tiles sur ce point.
Comme à l’époque où Google proposait KML à l’OGC, le format étant déjà fini et conçu pour GoogleEarth / GoogleMaps, la même chose semble se répéter ici avec CesiumJS.
3D Tiles vit dans un monde différent, il parle JSON, JavaScript-ish et GLSL.
Geomatys et le format 3D Tiles
Nos équipes jouent avec 3D Tiles depuis quelque temps, ainsi qu’avec les différents formats de Cesium incluant CZML, HeightMap et QuantizedMesh depuis quelques années. Il en résulte un sentiment mitigé.
Il manquait un format 3D standardisé pour commencer à vraiment faire de la 3D en SIG. Et 3D Tiles comble ce manque sans imposer trop de contrainte. C’est un plaisir de travailler en symbologie avec autant de souplesse et pour seule limite la créativité, merci principalement au format GLTF.
Pourtant, il est difficile de voir 3D Tiles comme un format SIG, il ne réutilise rien de ce qu’on connaît en SIG.
Tout le travail de géoréférencement, projection et transformation n’apparaît pas dans le format. Tout doit être préparé en amont par un générateur de tuiles 3D. 3D Tiles est le résultat final en bout de ligne avec pour seul objectif l’affichage. Cela aurait été pratique de générer une tuile 3D, d’indiquer quelque part qu’elle est en EPSG:3031 (stéréographique polaire) ou tout autre système de coordonnées mouvant utilisé dans Moving Features et de laisser le moteur 3D s’occuper du reste.
Au final, 3D Tiles est un bon format, un premier pas normalisé dans la 3D pour les SIG. C’est pourquoi, Geomatys l’implémente sur sa plateforme Examind Server.
Affichage de cartes marines (ENC) en 3D Tiles
Voyons maintenant ce que l’on peut faire avec 3D Tiles et des données IHO S-57 / S-52.
Le format S-57 de l’IHO et la symbologie S-52 sont les standards utilisés pour la navigation maritime. Si le sujet vous intéresse, vous pouvez trouver plus d’informations dans un précédent article : Entre SIG et ECDIS, S-57 et S-52 pour la marine et les militaires
Gardez à l’esprit que les données S-57 ne sont pas faites pour une visualisation 3D, mais le résultat après quelques ajustements est tout à fait satisfaisant.
Une carte S-57 en 2D :
Et en 3D, on obtient ceci :
A faible résolution on affiche uniquement l’emprise des cellules S-57 ainsi que leur identifiant.
En se rapprochant, l’emprise est remplacée par le modèle de terrain calculé à partir des données vecteurs de bathymétries, de trait de côte, des points d’élévation et autres.
On peut voir les pontons et les bâtiments grâce aux données S-57 d’un port.
La qualité générale dépend beaucoup des fichiers S-57. Les informations terrestres ne sont pas principales et sont souvent de moindre qualité, aussi des artefacts visuels apparaissent.
Pour plus d’informations sur Examind et le 3D Tiles, contactez les équipes de Geomatys.