Camptocamp a été mandaté par le Ministère de la Transition Écologique et solidaire pour mettre en œuvre une nouvelle version du module de cartographie de l’infrastructure de données spatiales Géo-IDE.

L’opération Géo-IDE s’inscrit dans le programme global de convergence des outils géomatiques du Ministère de la Transition Écologique et Solidaire (MTES/MCT) et du Ministère de l’Agriculture et de l’Alimentation (MAA) dans le domaine de l’information géographique. Géo-IDE est composé de 4 modules Cartographie, Catalogue, Base et Distribution et a pour objectifs :

  • d’outiller la connaissance des territoires à des fins d’aménagement et de gestion de crise ;
  • d’aider les ministères à remplir leur mission de service public.
  • répondre aux exigences de la directive Inspire qui oblige les autorités publiques à publier l’essentiel de leurs données relatives à l’environnement sous forme de services de recherche, visualisation et téléchargement selon des spécifications techniques très précises.

Le nouveau module de cartographie – Carto 2 – doit permettre aux administrateurs de données de composer des cartes en ligne via un composeur cartographique WEB, de gérer, cataloguer et publier des cartes composées en ligne et « hors ligne » via le SIG déployé dans les services, de partager des cartes « à diffusion restreinte » avec des partenaires autorisés.

Pour toute entité publique et pour le grand public, Carto 2 doit permettre de rechercher les cartes publiques publiées, de visualiser « en ligne » une carte publiée via un visualiseur cartographique WEB, de consulter et/ou télécharger les ressources nécessaires à la reproduction d’une carte publiée.

En 2019, Camptocamp a réalisé la version V1.0 de Carto 2 qui est entrée en production début 2020.

Back Office : composeur de cartes

Le Back Office de Carto 2 est un composeur de cartes dont une copie d’écran est présentée ci-dessous:

Ce back office permet de créer et de publier des cartes. Connectée au système d’identification du ministère, elle sert de façade à l’interface d’administration de Geoserver.

Toute action sur la carte en cours d’édition a une répercussion dans Geoserver (carte, couches, styles). Cette façade se fait via l’utilisation de l’API Rest de Geoserver qu’il a été nécessaire d’enrichir pour les besoins du projet. Elle permet de créer des cartes, des couches et groupes de couches à partir de différents formats (shapfiles, postgis, TAB, geotiff), ainsi que des styles.

Gestion du style

Un des principaux défis techniques de Carto 2 a été la mise en place d’un éditeur de style avancé compatible au niveau client et au niveau serveur.

Le composeur de cartes permet à l’utilisateur de créer une carte à partir de données ou de services et de modifier le style de chacune des couches ainsi créées.

Au moment de la publication, le nouveau style est « poussé » vers Geoserver. Le format de style qui est utilisé – Geostyler Style – est un format pivot dessiné autour des possibilité du SLD. Il présente l’avantage de pouvoir être utilisé aussi bien par les composants clients que par Geoserver, les couches WMS et vecteur sont stylées de la même façon, grâce à des parser autour du GeoStyler.

Utilisation du state

La partie cliente (front-end) de Carto 2 fait usage d’un state manager intégré au framework de composants. Le state permet notamment de stocker la carte en cours d’édition, et assure une parfaite synchronisation entre tous les composants et le modèle édité. Vu l’ampleur et la complexité du back office, il était nécessaire d’utiliser une gestion d’état pour assurer l’authenticité du modèle et éviter les effets de bord. Tout action faite sur la carte passe par le state, qui retranscrit le modèle de données stocké en base de données et retourné par les APIs.

Clean Architecture

Le développement des composants backend s’inscrit dans une logique de qualité essentielle pour un projet de cette envergure. En ce sens, nous avons implémenté une architecture de type « clean architecture » pour les couches de composants backend. Cette architecture, en forme d’oignons, réparti le code source en différentes couches de responsabilité, assure des dépendances unilatérales de l’extérieur vers l’intérieur avec au centre le métier, puis les cas d’usages, et à l’extérieur la couche de présentation et d’intégration.

L’avantage de cette architecture est qu’elle permet de retranscrire les besoins métiers, constants dans le temps, sans être dépendant d’une technologie. Un saut technologique nécessitera une nouvelle implémentation de la couche d’intégration, sans avoir besoin de toucher au métier ni aux cas d’usages. Elle décorrèle aussi complètement l’implémentation métier avec la couche présentation, définies uniquement pour les interfaces branchées à ce backend.

Carrière

Vous souhaitez travailler dans un environnement inspirant et rejoindre nos équipes motivées et multiculturelles ?