Comment le LAB a mis en place une infrastructure de traitement et de visualisation de données géographiques

Le Kaizen Lab : des problématiques diverses, des outils communs 

De nombreuses problématiques sociétales, environnementales, ou industrielles ont un aspect spatial. On pense notamment à des questions d’aménagement du territoire, de mobilité, ou de logistique. En conséquence, si l’on souhaite fournir toutes les informations nécessaires pour permettre de prendre des décisions adaptées, on ne peut négliger cet aspect spatial. 

Chez Kaizen, en particulier au Lab et au Pôle Data, nous concentrons nos expertises pour développer des outils qui permettent de valoriser les données notamment pour assister les prises de décisions. 

Bien que les problématiques soient souvent très différentes et qu’elles aient chacune leurs particularités, on peut identifier des outils communs pour réussir à tirer profit de ces données spatiales, notamment pour la récupération des données, la contextualisation, l’homogénéisation, le requêtage, la visualisation, etc… 

Notre objectif étant de créer rapidement de la valeur pour nos partenaires, et donc d’être capable de rapidement nous concentrer sur les aspects métier des problématiques, plutôt que de passer du temps sur de l’outillage.  

Pour permettre cette réactivité, nous avons œuvré pour mettre en place des outils communs à tous les projets, et qui sont entièrement adaptables aux différents besoins des projets sur lesquels nous serons amenés à travailler. 

Les données géographiques : des caractéristiques et des outils spécifiques 

Jusqu’à présent, l’infrastructure du LAB était plutôt centrée sur le monde de l’IoT. Cette orientation se traduisait par l’utilisation d’outils répondants à des contraintes caractéristiques de cet univers tels que la disponibilité, la rapidité d’écriture et de lecture des données ou encore la flexibilité des schémas de données. En cela, notre pipeline Node-red / MongoDB fonctionne très bien et répond bien à nos diverses contraintes. 

Cependant, nous avons vite compris que les données spatiales, souvent nécessaires pour traiter des problématiques spatiales (ah bon ? ^^), ont des caractéristiques complètement différentes et que leur exploitation requiert d’autres outils plus adaptés.  

Les données 

Malheureusement les jeux de données initialement propres, cohérents et homogènes ne courent pas les rues, et c’est d’autant plus vrai pour les données spatiales. Il est donc souvent nécessaire de fusionner différents jeux de données pour répondre aux problématiques, et sans
les bons outils cela peut s’avérer très laborieux. D’une part parce que les volumes à traiter sont généralement très importants (plusieurs giga-octets, rien que pour une région), et d’autre part parce qu’il faut souvent homogénéiser, supprimer les doublons, créer des intersections etc. Enfin, la plupart du temps, les données vont être importées en une fois, puis ensuite retrouvées avec des requêtes complexes. 

Les outils 

Pour traiter ces informations, il faut donc des outils qui permettent de travailler avec les différents formats dans lesquels les données spatiales peuvent exister (GeoJSON, Shapefile, XML…), et non seulement de manipuler les différents systèmes de coordonnées (latitude / longitude, sinusoidale…) mais aussi de prendre en compte les différentes unités de mesure (métrique, impériale…). Ensuite, il faut que ces outils nous permettent de poser des “questions spatiales” telles que : “quels sont les éléments qui s’intersectent ? Se contiennent ? Sont à telle distance de ?” etc. nous permettant de répondre aux problématiques métier. 

La visualisation des données 

Enfin, la partie visualisation des données apporte elle aussi son lot de complexités toutes particulières, dont la gestion de la montée en charge des infrastructures lors des requêtes occupe une place importante. C’est pour cela que l’on met notamment en place des Web Services génériques (donc indépendant des problématiques métier) permettant de mettre à disposition les données spatiales sous forme de WMS – images dont le détail s’adapte automatiquement au niveau de zoom de la carte sur laquelle est affichée l’information, ou WFS – GeoJSON représentant la donnée brute, dont l’affichage peut être entièrement stylisé côté client en fonction du besoin.

Alors, comment on s’y prend ?

Afin de faciliter la compréhension, nous vous proposons une représentation de notre architecture :

Le choix des outils

Le traitement des données géographiques nécessite divers outils. Mais tout d’abord, commençons par la base : les données elles-mêmes. Celles que nous utilisons proviennent d’OpenStreetMap (OSM), un projet collaboratif lié à la cartographie comportant de multiples bases de données libres. Afin de limiter la taille des fichiers de données, OpenStreetMap propose de les extraire au format .pbf et propose également des « diff » permettant de les mettre à jour régulièrement sans en réimporter l’intégralité. 

Il faut également prévoir le stockage des données. Notre choix s’est porté sur PostGIS, l’extension géospatiale de PostgreSQL gérant les bases de données relationnelles et objet.  

Le choix d’utiliser l’outil d’import de données OpenStreetMap osm2pgsql est limpide puisque c’est l’outil le plus adapté à notre cas d’usage et à nos besoins tout en nous laissant libre de réaliser le traitement des données brutes importées dans notre base de données.  

Autre choix évident, l’outil d’administration pgAdmin, qui se présente sous la forme d’une simple application web se connectant directement à notre base de données. C’est l’outil de référence pour administrer les bases PostgreSQL tout en permettant l’utilisation de toutes les fonctionnalités de l’extension PostGIS. De plus, il est possible très simplement, via une requête SQL, de visualiser graphiquement toutes ou partie de nos données sans besoin de développement supplémentaire sur notre application métier (le KZS Showcase), nous épargnant de possibles problématiques plus liées à l’infrastructure qu’aux données en elles-mêmes. 

Les données OSM sont très complètes mais ne sont pas directement prêtes pour n’importe quelle utilisation. Il est impensable de simplement importer des données via osm2pgsql et directement créer un itinéraire entre deux points. Nous avons donc créé un script qui, en ayant comme entrée un fichier de données OSM ainsi qu’une base de données, importe ces données et les utilise pour créer des tables dédiées à chacune de nos fonctionnalités (dont nous parlons juste après).

Afin d’aborder les fonctions de routage, nous optons pour pgrouting, une librairie complétant les bases de données géospatiale PostGIS ou PostgreSQL afin de fournir des outils de routage géospatial et d’analyse de réseaux. Cette librairie fournit les principaux outils pour commencer le routage : des fonctions de calcul de plus courts chemins avec divers algorithmes possibles, une solution au « Traveling Salesman Problem » et la création de réseau géographique. Nous utilisons justement toutes ces fonctions pour répondre à notre cas d’usage. 

Le script SQL exécuté par le script d’import crée comme dit plus haut les différentes tables de travail nécessaires, en utilisant notamment des fonctions du module complémentaire pgRouting. Nous utilisons ensuite des fonctions développées de notre côté afin de mettre tout cela ensemble, et générer un itinéraire entre plusieurs points répondant au problème du « Traveling Salesman Problem » à partir de coordonnées géographiques données par l’utilisateur. 

Lorsque nous souhaitons visualiser les données retournées par pgrouting, les outils de PostgreSQL et de pgAdmin montrent leurs limites. Ainsi, nous préconisons GeoServer, un serveur OpenSource créé pour partager et utiliser des données géospatiales. Celui-ci implémente notamment les protocoles standards industriels OGC comme les Web Feature Service (WFS) et Web Map Service (WMS) qui peuvent être retournés par des requêtes HTTP, afin de consulter le contenu de couches SQL. Ces dernières nous servent à visualiser les données sur notre application web Angular utilisant Leaflet pour gérer l’affichage de cartes interactives.

Le déploiement

Le déploiement de tous ces outils de manière unitaire et native peut s’avérer complexe à mesure que l’on ajoute des environnements et systèmes d’exploitation différents. Afin de faciliter cela, nous utilisons des conteneurs Docker, avec docker-compose ainsi que des « docker secrets » afin de gérer l’aspect cyber-sécurité. Pour le stockage des données, le docker officiel de pgrouting incluant PostGIS se suffit, en ajoutant les bonnes extensions à la base de données. PgAdmin propose également une version Docker stable et à jour. Nous avons réalisé un conteneur ‘Utilitarian’ incluant l’outil d’import de données osm2pgsql afin de faciliter la mise en production. Pour ce qui est de l’import de données GeoJSON, nous l’avons également dockerisé. Nous avons dû en outre créer l’image pour le GeoServer pour les raisons qui vous seront explicitées dans la partie ‘Difficultés Rencontrées’.  

Le confinement : contexte inhabituel pour un cas d’usage encré dans l’actualité 

Afin de travailler sur un cas concret, nous nous sommes intéressés à la génération d’un itinéraire. En effet, le contexte de confinement lié à la pandémie nous a permis de répondre à des besoins liés à des contraintes inhabituelles. Ainsi, nous nous sommes lancé le défi de générer aléatoirement un itinéraire de moins d’une heure dans un polygone, correspondant à l’iso distance d’1km autour d’une adresse rentrée par l’utilisateur. Au départ nous utilisions des APIs pour réaliser cela mais elles ont vite montré leurs limites de personnalisation et de conditions possibles. 
Grâce à notre nouvelle infrastructure, nous pouvons désormais résoudre ce cas d’usage de cette manière : nous générons des points aléatoires dans l’iso distance, nous résolvons le Traveling Sales Person sur l’ensemble de ces points, puis nous réalisons des itinéraires de plus court chemin deux à deux que nous affichons à l’utilisateur grâce à Leaflet et au WFS proposé par Geoserver. 

Difficultés : plusieurs problématiques à résoudre 

Le temps de traitement des données 

La première des difficultés, qui a provoqué un décalage entre les prévisions et la réalité du temps de développement a été le volume de données. En effet, les fichiers OSM sont au format xml, mais sont souvent compressés en pbf, dont le taux de compression avoisine les 96%, ce qui donne un fichier pbf décompressé de la France d’environ 98 Go. Or nous avons commencé à travailler sur ce sujet en utilisant nos ordinateurs portables, des machines assez récentes, ayant 8 cœurs logiques et 8Go de RAM. Mais en exploitant la totalité de ces ressources, un import du département de l’Isère (un fichier pbf de 75 Mo) dure 17 minutes, dont un peu plus de 3 minutes pour la décompression et l’insertion en base. 

Même démarche pour la génération d’un itinéraire répondant au « Traveling Salesman Problem », sur ce même jeu de données, avec 22 points, le temps d’exécution se trouve dans les 5 minutes. 

Afin de réduire les temps de traitement la solution est d’utiliser un jeu de données moins large, mais cela pose le problème de qualité des données. Un département est la plus petite zone prédéfinie qu’il est possible d’importer. Des outils fournis par OSM existent pour récupérer une zone de son choix, mais la taille de la zone est limitée à un quartier de ville. Par conséquent la zone de test devient trop restreinte pour s’assurer que les fonctionnalités développées soient correctes.  

Évidemment ces soucis sont résolus, notre environnement de production étant basé sur une machine virtuelle dimensionnée pour notre cas d’usage. Une seconde machine équivalente est utilisée pour effectuer les traitements de données dans de meilleures conditions. 

La création du réseau et de l’architecture logicielle 

Ensuite, la création du réseau a été un obstacle tenace. En effet, nous avions tout d’abord utilisé la fonction createTopology proposée par pgRouting permettant de créer un réseau à partir de nos données OSM. Cela nous paraissait la meilleure option à notre disposition. Cependant, celle-ci a démontré ses limites puisque lors d’une démonstration de plus court chemin entre deux points, un chemin était trouvé la moitié du temps et par moment il n’était pas du tout le plus court chemin possible ! Il y avait donc un souci dans la génération de notre réseau. Ainsi, nous avons réfléchi à plusieurs possibilités pour améliorer ce réseau : augmenter la tolérance, changer d’outil d’import de données… Après avoir étudié et testé ces possibilités sans grand succès, nous avons pensé à renouer l’entièreté de notre réseau à l’aide de la fonction nodeNetwork de pgRouting, ce qui a fonctionné après plusieurs tentatives infructueuses. Ensuite, nous avons regroupé les informations de notre table originelle et celle de notre réseau renoué afin de re-créer un réseau prenant en compte les index de hauteur (z-index) et cela fut une réussite. 

Comme expliqué plus haut, nous avons mis en place une architecture entièrement dockerisée, nous utilisons donc, pour chaque logiciel, des images fournies par leurs développeurs sur Docker Hub. Un souci est apparu avec l’image GeoServer en version 2.16.2 au niveau des accès anonymes aux services de données et aucun paramétrage ne semblait résoudre le souci. Par conséquent, nous avons rapidement décidé de créer notre propre image, afin de remplacer l’image officielle. Cette dernière est basée sur la version 2.16.2 trouvable sur le site officiel GeoServer, et fonctionne de manière similaire à celle-ci.  

L’image kaizenlab/geoserver est disponible en open source sur Docker Hub.

Évolutions envisagées : vers un nouveau cas d’usage ? 

Désormais, nous pouvons repousser les limites des APIs et imaginer davantage d’évolutions. En effet, nous aimerions pouvoir utiliser plus de critères pour générer nos itinéraires, tels que le fait de ne pas emprunter deux fois la même route, mais également d’éviter certains endroits, comme les parcs (pour éviter la foule ou éviter d’y proposer un itinéraire alors qu’ils sont fermés). De plus, pour rendre la génération plus ludique, nous aimerions proposer la fonctionnalité de générer un itinéraire à partir d’une photo ou d’un mot-clé. 

L’idée nous ayant mené vers la mise en place de ce système est la génération d’itinéraires piétons, qui est un cas d’usage très particulier
et il existe une quantité énorme d’autres utilisations possibles qu’il serait intéressant d’implémenter. Nous sommes donc évidemment impatients de mettre en place un nouveau cas d’utilisation en adéquation avec le besoin de l’un de nos partenaires. 

G.Daras, O.Pitarch, J.Sanchez, R.Tod