Geomatys lauréat du challenge numérique « Nouveaux usages des données LITTO3D »
Le Pôle Mer Méditerranée et le SHOM en partenariat avec la BPI, la DGE et TVT Innovation lance un challenge sur les produits et services utilisant les données Litto3D. « Le produit Litto3D® est une base de données altimétrique unique et continue terre-mer donnant une représentation tridimensionnelle de la forme et de la position du sol sur la frange littorale du territoire français. » Geomatys vainqueur du challenge propose de développer un outil facilitant l’exploitation de données Litto3D : LittoToolbox ! Cet outil à destination des organismes impliqués dans l’aménagement du littoral offrira un service SAAS basé sur la plateforme Examind. Accessible sur abonnement il permettra aux utilisateurs de manipuler les données Litto3D et de les croiser avec d’autres données (Sentinel 1, 2 & 3, données météorologiques, données de capteurs in-situ…). Le projet vise à offrir un environnement de travail pour la manipulation de données de sources hétérogènes, accessible sur abonnement. Depuis cet espace, les utilisateurs disposent : Le projet consiste à adapter la plateforme Examind aux besoins spécifiques des acteurs de l’aménagement du littoral (bureaux d’études, offices de tourisme, ports, services étatiques…), afin de leur proposer un outil distant facilitant la manipulation et le croisement des données Litto3D. LittoToolbox s’appuiera sur la plateforme Examind Cloud structuré sous forme de micro-services pour la communication inter-modules (module de traitements deep-learning, module de stockage des données…). Ce projet est une belle illustration des possibilités d’Examind. Notre plateforme générique constitue une base solide pour tous vos développements d’applications métiers.
3D Tiles et ENC en action
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 : 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. 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… 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. 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 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. 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
Retour sur les salons Eurosatory et Toulouse Space Show
Un mois de Juin rythmé à Geomatys Peu présente sur les salons ces dernières années, Geomatys a décidé de dynamiser sa communication. L’objectif ? Faire connaître l’entreprise et sa gamme de produits Examind. Des logiciels de traitement de données géospatiales s’intégrant aisément dans vos systèmes d’informations. Déjà utilisés par de grands industriels (Airbus DS, Naval Group), ils ne demandent qu’à être connus ! Pour cela, deux salons, deux thématiques : la défense et l’observation de la Terre. Le salon Eurosatory 2018 Une grande première pour Geomatys, et un franc succès ! Cinq jours de salon défense et de nombreux visiteurs sur le stand. Quel plaisir pour nous de voir l’intérêt porté à nos solutions et l’engouement autour de nos démonstrations de visualisation 3D. Le Toulouse Space Show 2018 Un salon qui ne nous déçoit jamais ! Encore une fois un grand succès pour Geomatys. Un stand qui ne désemplit pas, des visiteurs qui s’arrêtent car ils ont entendu parler de nous et veulent en savoir plus. Surprise et satisfaction de voir que les premiers utilisateurs de nos solutions les promeuvent. Un grand merci à tous nos clients et visiteurs, qui ont permis la réussite de ces salons et promettent un avenir souriant à la suite logicielle Examind !
Proj.4 may become more similar to Apache SIS
The GDAL/Proj.4 community has raised $142,000 for improving the map projection library behind major Open Source geospatial softwares. The issues to be fixed require an architectural change. Proj.4 is moving away from the early-binding approach (where WGS 84 is used as a pivot system) to a late-binding approach (with no fixed pivot system and with parameters that may depend on the geographic area). This change is required for accurate transformations in some situations. Implementing the late-binding approach requires a more complete EPSG geodetic dataset than the CSV files bundled in Proj.4. SQLite is the proposed alternative. Finally expressing this richer information in a Well Known Text (WKT) format requires ISO 19162 support (also known as « Well Known Text 2 »). The new WKT 2 standard fixes some ambiguities that caused the apparition of non-standard interpretations of WKT 1 standard, and can describe reference systems that can not be described in the previous standard (for example projections over pole). Those improvements to be implemented in Proj.4 were already implemented for more than 10 years in Apache Spatial Information System (SIS) project or its predecessor GeoTools, except WKT 2 which has been implemented in 2014. Indeed the GDAL Coordinate System Barn Raising cites GeoAPI and Apache SIS has inspiration sources. But if Apache SIS was a precursor, it was not because of clever developers. Apache SIS chooses to follow closely the ISO 19111 conceptual model for its design. While apparently overly complex at first sight (developers are often prompt to judge someone’s else model as « unnecessary complexity »), complying with OGC/ISO models allowed Apache SIS to benefit from the insight of the experts who designed those standards. With more than 15 years of experience with this approach, we feel that its long-term benefit has been largely demonstrated since ISO/TC211 experts anticipate in their models many real-world complexities that are not immediately apparent to developers. However this benefit exists only provided that we use the right standards, which are the UML in abstract models (ISO 19115, ISO 19111, etc.). The standards designed for web technologies (WCS, XML, etc.) are usually not suitable for designing the API of a library. Proj.4 is now following a similar path, with a proposed API very similar to ISO 19111 model. If Proj.4 continue on this path, its API would naturally be close to the Java interfaces defined in GeoAPI (and implemented in Apache SIS) since they would share the same conceptual model. This may open an opportunity to use implementation-neutral parts of Proj.4 API for defining a C++ version of GeoAPI, with Proj.4 being one implementation. It would make easier to share tests, or allow users to depend more transparently on the library of their choice.
L’informatique doit-elle s’écrire uniquement au masculin ?
C’est à la lecture de l’article du Monde de décembre 2017 dont le titre est très évocateur “Les femmes de plus en plus minoritaires dans le secteur de l’informatique” que l’idée de se pencher sur la question de la parité dans une PME d’informatique high tech m’est venue : que se passe-t’il à Geomatys dans le domaine ? en tant que DRH ai-je la possibilité d’inverser la tendance ? comment encourager la parité chez nous ? Petite histoire de Geomatys : Geomatys a 13 ans, fondée par deux passionnés d’informatiques (de vrais Geeks). L’entreprise est spécialisée dans le traitement de l’information de géointelligence, conçoit et intègre des solutions logicielles, à destination notamment des acteurs des secteurs Défense, Surveillance et gestion des risques, l’Environnement et les Smart territoires ainsi que l’Observation de la terre. Les solutions proposées facilitent la prise de décision. C’est donc une entreprise à très forte technicité. Depuis, l’entreprise a grandi jusqu’à une quinzaine de personnes, majoritairement techniques et le nombre de femmes n’a jamais représenté plus de 20% de l’effectif. Une petite anecdote illustre parfaitement ce qui nous est arrivé dans le domaine : en juin 2017 nous avons reçu la visite d’une stagiaire de Master 2 Info de Montpellier, elle passe un entretien avec l’un des chargés de projet de Geomatys et un de nos développeurs. Le sujet de stage, un peu complexe, lui plait et elle fait le tour des bureaux … pose un certain nombre de questions et puis… arrive une question à laquelle nous ne nous attendions pas : “mais il n’y a que des hommes chez vous”…. Malheureusement, elle n’a pas souhaité donner suite au recrutement, dommage. Y a-t-il un lien de cause à effet ? On ne le saura jamais, mais l’expression sur son visage à cet instant-là était éloquente ! Je me suis dit que c’était un sujet dont il fallait que je m’occupe. Les questions que je me suis posées à ce moment-là : Nous avons une politique de fidélisation de nos développeurs qui ont un niveau d’expertise élevé, ne nous permettant pas d’investir sur des profils trop vagabonds. Notre taux de turn-over est donc très faible. Comme semble l’indiquer l’article cité en référence, la proportion de “développeuses” est très faible, la probabilité pour une PME de pouvoir en accueillir une devient infinitésimal. En tant que DRH, femme, j’ai commencé par la mise en quarantaine des blagues sexistes (appelées dorénavant, par certains, les “blagues du vendredi”). La politique active de sourcing de profils féminins à compétences égales par ailleurs, ma présence systématique lors de l’accueil des stagiaires féminines… devraient aider un peu à rétablir l’équilibre chez Geomatys. A notre échelle, nous réfléchissons à ce que nous pouvons faire de plus : parrainage et cooptation de profils féminins, explication de notre souhait à nos écoles partenaires… en attendant que les formations en informatique se saisissent du problème qui semble ne faire que s’accentuer. Pour l’immédiat, l’arrivée en août d’une alternante spécialisée dans le traitement Big Data va nous permettre de passer à 3 femmes… En attendant plus… La parité n’est pas un but en soi mais un moyen comme les autres d’ouvrir et de sensibiliser l’entreprise à toutes les préoccupations de la société…. celles des hommes tout autant que celles des femmes….. Si vous avez des idées ou des solutions qui ont fonctionné, dans le domaine, je serais curieuse d’en avoir connaissance; n’hésitez pas à me contacter.
Les 5 raisons de choisir une solution SIG hybride
Autrefois réservés à l’usage de personnels spécialisés, les SIG (Systèmes d’Information Géographique) et la dimension spatiale de leurs données prennent une place de plus en plus importante dans les systèmes d’informations. Ils permettent de cartographier une très grande variété de données pour mieux appréhender notre environnement. Ainsi, les SIG sont étroitement liés aux enjeux actuels (biodiversité, gestion de réseaux, organisation du territoire, protection civile…). C’est pourquoi on assiste, aujourd’hui, à l’avènement de ces infrastructures qui se doivent d’avoir un fort niveau de disponibilité et une grande capacité d’évolutivité. Une approche hybride Open Source et propriétaire peut présenter dans ce cadre de nombreux avantages. Testez avant d’acheter L’achat d’une solution SIG est souvent complexe. La mise en place de l’infrastructure entraîne des changements organisationnels et représente un coût non négligeable. Alors inutile de prendre un risque ! Il est préférable de pouvoir tester la solution avant de l’acheter. En faisant le choix d’une infrastructure hybride vous pourrez essayer la version open source avant de passer à l’achat. Ainsi, vous aurez l’assurance de la compatibilité de la solution avec votre infrastructure et la garantie qu’elle répond à vos besoins. Maîtrisez l’infrastructure Les solutions hybrides reposent sur un cœur open source et donc transparent. Opter pour une solution hybride vous permettra de toujours garder un œil sur l’évolution du code source. Vous pouvez ainsi connaître avec certitude ce qui compose votre infrastructure et en garder la parfaite maîtrise. L’assurance d’une bonne interopérabilité La transparence du cœur des solutions hybrides permet de savoir avec certitude si l’infrastructure est interopérable avec les logiciels déjà présents dans l’entreprise. Il est possible de facilement identifier le respect ou non des standards par la solution. Il est donc judicieux, lorsqu’on se tourne vers une infrastructure hybride, de se renseigner sur les standards du domaine et leur intégration dans la solution. Bénéficier de l’expertise d’une vaste communauté d’acteurs En choisissant une solution hybride vous profiterez de l’expertise de nombreux contributeurs. La communauté open source participe à l’amélioration des infrastructures libres. Basés sur le principe de la coopération, les logiciels open source prennent en compte les besoins réels de la communauté. Ainsi, la contribution des acteurs rend ces infrastructures plus innovantes. Les solutions hybride bénéficient de l’implémentation constante de leur cœur open source. Réduisez le coût de votre licence Basée sur un cœur open source, la solution hybride permet de réaliser des économies. Vous ne payez que la surcouche propriétaire qui offre des fonctionnalités supplémentaires et la gestion de formats complexes. De plus, les certifications vous garantissent un bon niveau d’industrialisation et la conformité de la solution aux exigences requises dans votre secteur d’activité. Geomatys propose une suite hybride, Examind Universe, reposant sur un cœur open source : Examind Community. Cette dernière est basée sur les bibliothèques GeoAPI, Geotoolkit et Apache SIS principalement développées par les équipes de la société. Vous pouvez ainsi faire l’expérience de notre plateforme open source avant de choisir la solution hybride la plus adaptées à vos besoins.
Quels standards OGC pour l’informatique en nuage ?
Les membres du consortium Open Geospatial (OGC) se sont réunis à Orléans du 19 au 23 mars. Depuis peu, ces réunions expérimentent une nouvelle formule pour la séance plénière de clôture. Durant la semaine, les membres votent pour un sujet qui sera présenté et débattu en séance. À Orléans, le sujet discuté à la clôture était latent depuis plusieurs mois. Il avait été soulevé plus explicitement, sous différentes formes, à au moins deux reprises au cours de la semaine. Depuis une ou deux années, les agences spatiales – notamment la NASA et l’ESA – expriment à l’OGC un besoin d’inverser la logique actuelle dans la façon de manipuler les données. Au lieu d’amener les données aux algorithmes (c’est-à-dire de télécharger des données à partir de serveurs vers le poste du scientifique qui effectuera les calculs), on souhaite amener les algorithmes vers les données. La raison est que les données d’observation de la Terre occupent un volume tel que leur téléchargement peut devenir impraticable. On souhaite plutôt exécuter les algorithmes là où se trouvent les données. Ce souhait est déjà partiellement réalisé par certains acteurs. Par exemple Google Earth Engine (GEE) permet d’exécuter des algorithmes définis par l’utilisateur sur les serveurs de Google. Le guide du développeur contient un exemple d’algorithme (un calcul d’indice de végétation) exécuté localement, puis exécuté plus efficacement sur les serveurs où se trouvent les données. Mais cet exemple utilise une interface de programmation (API) propre à Google ; aucun standard géospatial n’y est appliqué. Cette conception expose les utilisateurs au risque de verrouillage du fournisseur. Une situation où les algorithmes écrits pour GEE peuvent être difficiles à porter vers une autre source de données. L’initiative openEO part de ces constatations (besoin d’exécuter des algorithmes là où se trouve la donnée ; les solutions existantes utilisent des API propriétaires) pour proposer une API neutre en Python. Leur prototype permet déjà de définir des algorithmes pour GEE en utilisant une API qu’ils veulent transposable à d’autres fournisseurs. Toutefois, bien que openEO ait été présenté à la réunion OGC à Orléans, l’API montrée semble leur être propre. Il utilise assez peu les modèles conceptuels de l’OGC. Les standards définis par l’OGC s’articulent autour du transfert de données. Soit en définissant des formats de fichiers (par exemple netCDF) ; soit en définissant des services web permettant de télécharger ces fichiers. La principale exception est le standard Web Processing Service (WPS) qui permet d’exécuter des algorithmes à distance. Cependant, ses possibilités sont limitées aux algorithmes pré-définis sur le serveur (auquel cas on ne fait que transmettre des paramètres) ou aux algorithmes exprimables dans un langage proche du SQL (beaucoup plus limité que Python, Java ou autres langages de programmation). Cette situation a amené la NOAA à poser trois questions à Orléans : La réponse à la question 2 pourrait être « tous les standards web et formats de fichiers ». Ce qui englobe beaucoup des standards les plus populaires de l’OGC ! Notons toutefois que même si ces standards peuvent devenir inutiles pendant la phase d’exécution d’un algorithme par l’informatique en nuage, ils restent pertinents pour récupérer le résultat du calcul. Une réponse à la question 3 pourrait être GeoAPI, un standard OGC qui définit des interfaces de programmation depuis plus de 15 ans. GeoAPI poursuit les mêmes objectifs que openEO, mais en prenant le problème par le bout opposé. OpenEO part du haut (« fournir une image à l’utilisateur »), et descend dans les détails au fur et à mesure des besoins. Ils peuvent se permettre cette approche car ils définissent leur propre API, qu’ils complètent à leur rythme. De l’autre côté, GeoAPI s’est donné comme mission d’implémenter les modèles conceptuels standards de l’OGC et de l’ISO. GeoAPI évite de créer son propre modèle, excepté pour des besoins d’intégration avec le langage de programmation ciblé. Par exemple, pour représenter une image, GeoAPI s’appuiera sur le modèle conceptuel définit par ISO 19123 (schema for coverage geometry and functions), qui lui-même dépend de ISO 19107 (spatial schema), qui dépend de ISO 19111 (spatial referencing by coordinates), qui dépend de ISO 19115 (metadata), qui dépend de ISO 19103 (conceptual schema language)… GeoAPI part donc du bas et monte vers les besoins des utilisateurs en suivant le fil des dépendances entre les standards ISO. C’est un processus plus long que l’approche prise par openEO, mais qui tend vers une solution collant mieux aux standards internationaux. Paradoxalement, l’informatique en nuage remet d’actualité une approche qui était en vogue il y a une vingtaine d’années, avant d’être (temporairement?) éclipsée par la vague des protocoles web. Le mode de fonctionnement de Google Earth Engine ressemble au mécanisme derrière les Remote Method Invocations (RMI) du Java, publié en 1997. D’ailleurs, le slogan de Sun Microsystems (le créateur du langage Java à cette époque) était « The network is the computer ». Les API définis par des interfaces Java – comme GeoAPI – se prêtent naturellement à une utilisation par l’informatique en nuage. Étendre cette approche à des langages autres que Java – à commencer par Python – est en cours sur le dépôt de code de GeoAPI.
DIDRO, un outil intégré pour l’auscultation des digues par drone
L’usage des drones se démocratise, ouvrant pour les gestionnaires de digues des perspectives d’auscultation de leurs ouvrages par voie aérienne à des coûts d’opération raisonnables. Il devient possible d’inspecter en une seule journée plusieurs kilomètres de digues (certaines pouvant être d’accès difficile voire impossible à l’homme), facilitant les visites obligatoires et la gestion des situations de crise. Par ailleurs, l’instrumentation de mesure se miniaturise, son coût diminue, et permet une vision globale et profonde des infrastructures, souvent au-delà de ce que peut détecter l’humain, ou avant que les conséquences d’une anomalie majeure ne soient visibles à l’œil nu. Les capacités de traitement et de stockage de données, à l’heure du Big Data, sont telles que tout le monde peut avoir accès à un centre de calcul et de stockage numérique. Le bon usage de ces technologies, même si elles paraissent abordables à tous, impose d’apporter aux utilisateurs des réponses aux questions suivantes : DIDRO est un consortium de chercheurs et d’industriels, réunis sous l’impulsion d’opérateurs de drones et de gestionnaires de digues. Trois ans de travaux ont permis de : Le dispositif type est un drone-hélicoptère, fabriqué par la société Survey Copter, qui embarque : Les données collectées lors d’un vol sont déversées dans une plateforme Cloud de traitement de données, enrichies à partir de processus d’analyse sélectionnés et calibrés, puis interprétées par un expert et mises à disposition du gestionnaire de digues. Geomatys a été choisi par le consortium pour assurer le pilotage du projet, et pour proposer, en partenariat avec Survey Copter, un service d’auscultation par drones aux gestionnaires de digues. Geomatys y apportera son expertise en : La phase de conception est en cours, les premiers essais montrent de très bons résultats. Le service devrait être disponible au second semestre 2019.