Le 14 décembre 2024, Mayotte était frappée par le cyclone Chido, le plus violent qu’elle ait connu depuis plus de 50 ans. Rapidement, l’IGN a diffusé des imageries Pléiades prises les 17, 18, 20, 21 et 24 décembre et a confirmé le 25 décembre que la communauté OSM pouvaient les utiliser comme source dans ses éditions. De suite, j’ai eu l’envie de les utiliser pour évaluer les dommages du bâti. Pourquoi le bâti ? Du point de vue cartographique, parce que les dommages sont plus visibles sur des infrastructures polygonales que ponctuelles ou linéaires. Du point de vue de la réponse de crise, parce que les dégâts étaient particulièrement importants, ayant fait disparaître ou rendu impraticables les foyers de beaucoup d’habitants.
Trois mois après, ce billet revient sur les grandes étapes de cette cartographie toujours en cours, organisée bénévolement sur du temps libre.
Revue et choix méthodologique
La cartographie des dommages du bâti à l’aide d’imagerie post-désastre n’a évidemment pas été inventée dans OpenStreetMap et des expériences similaires ont déjà été menées par le passé dans OSM.
Après le passage du cyclone Haiyan sur les Philippines en novembre 2013, une cartographie des dommages du bâti avait été réalisée sur la région autour de Tacloban. Par ailleurs, des chercheurs du Harvard Humanitarian Initiative (HHI) avaient publié en mars 2016 un article détaillant une méthodologie qui avait été de suite adaptée à OSM sous la forme de modèles de préréglages et d’un style cartographique pour JOSM, et appliqués notamment à Haïti après le passage du cyclone Mathieu en octobre 2016.
L’approche Haiyan se limite à deux étiquettes pour les bâtiments endommagés, en utilisant directement la clé building=*, ce qui n’est pas idéal. L’approche BAR avait été adaptée jusqu’ici dans OSM via deux clés spécifiques damage=* avec les quatre catégories de dommage définies par les chercheurs du HHI (aucun, minimal, significatif et complet) et damage:structure pour qualifier le type de construction selon trois catégories (léger, medium, lourd). Après des tests menés sur Miréréni, avec les imageries BD Ortho IGN et Pléiades, et des échanges avec un géographe résidant à Mayotte, il m’est apparu que si les classes de dommages étaient aisées à déterminer, le type de construction était difficile à déterminer directement, le seul élément toujours visible étant la toiture. Par ailleurs, le type intermédiaire « medium » paraissait difficile à borner.
Par conséquent, plutôt que d’ajouter une étiquette déduisant un type de construction à partir d’éléments fragmentaires, j’ai préféré ne cartographier que le matériau de toiture avec la clé roof:material déjà existante et bien documentée. Dans le cas de Mayotte, les toitures sont généralement de deux types, soit un toit en tôle métallique de qualité variable, quelle que soit la taille ou l’usage du bâtiment, soit une dalle de béton plane qui est en fait le sol d’un futur étage qui reste à construire.
Lors des premiers tests, la clé damage a été réutilisée, mais elle a le défaut de devenir rapidement obsolète, dès lors qu’un bâtiment non pas détruit, mais endommagé, va être réparé. Et même si elle n’est pas supprimée malgré son obsolescence, il deviendra difficile de savoir par la suite à quel événement elle se rapportait. C’est pour cela que j’ai finalement opté pour une clé damage:DisasterName=*, soit damage:Chido=* dans le cas présent. La même logique d’insertion du nom du désastre a prévalu pour les étiquettes de métadonnées pour renseigner le nom de l’événement, la source de l’imagerie utilisée et sa date de capture.
Cette revue méthodologique a aussi été l’occasion de documenter le wiki OSM, avec la création de deux pages : https://wiki.openstreetmap.org/wiki/FR:BAR_methodology sur la méthodologie BAR et sa première adaptation OSM, qui n’avaient pas encore été documentées et https://wiki.openstreetmap.org/wiki/Building_damage_assessment pour cette nouvelle adaptation centrée sur le bâti.
Période de test de la méthodologie et interactions avec les données EMSR Copernicus
Dans les premiers jours de janvier, les imageries Pléiades sont intégrées aux imageries disponibles depuis le menu d’imagerie de JOSM et les premières versions du nouveau modèle de préréglages et de son style cartographique pour JOSM sont réalisées et testées sur une petite zone de Mamoudzou. Seul imprévu : la qualité moyenne de la géométrie du bâti qui nécessite parfois d’être rectifiée. Le 6 janvier, un projet sur la zone centrale de Mamoudzou est créé dans le Gestionnaire de Tâche HOT et ouvert seulement à des contributeurs OSM intermédiaires ou avancés, avec des instructions détaillées assorties de vidéos en anglais puis en français. Pendant les quelques semaines de ce test, l’étiquetage est légèrement revu (l’intégration du nom du désastre dans les clés, évoqué plus haut) et le style cartographique complètement refait.
Des échanges ont lieu au sein de la communauté OSM France (voir ce fil de forum) et la méthodologie est validée par un représentant du CSTB pour les besoins d’évaluation rapide des dommages. Le choix de Mamoudzou a permis également de comparer les résultats de cette cartographie communautaire inspirée de la méthodologie BAR avec l’évaluation rapide faite entre le 15 et le 24 décembre dans le cadre de l’EMSR (Emergency Management Service Rapid mapping) 780 du programme Copernicus, qui s’est concentrée sur la face centrale à l’est de l’île de Grande-Terre et aussi sur l’île de Petite Terre.
Les données EMSR sur les dommages du bâti, disponibles sous forme de fichiers sous licence ouverte (bien que pas très claire), sont constituées de points vectoriels au centre des bâtiments, avec trois classes différentes : Possiblement endommagé, Endommagé, Détruit, qui semblent correspondre aux catégories minimal, significatif et complet de la méthodologie BAR. Il n’existe donc pas de classe pour les bâtiments non endommagés, et de fait de nombreux bâtiments sur la zone évaluée ne comportent pas de ponctuels en leur centre. Cette approche a pour limite de ne pas permettre de connaître la proportion de bâtiments endommagés par rapport à l’ensemble des bâtiments via les seules données Copernicus. De plus, « possiblement endommagé » peut aussi apparaître comme une classe intermédiaire entre « aucun » et « minimal » de la méthodologie BAR, de sorte que les deux échelles d’évaluation ne se recoupent peut-être pas.
J’ai mis en place un croisement automatisé des ponctuels Copernicus avec les bâtiments OSM actualisés via des diff minute et une mesure des écarts entre les deux évaluations. Cela permet ainsi, pour chaque bâtiment évalué par les deux méthodologies, de connaître les écarts de classe entre les deux évaluations. Il s’avère qu’un écart d’une classe est un cas plus fréquent qu’une classe identique.
Une analyse reste encore à faire pour expliquer ces différences. Cette comparaison s’est cependant limitée à cette zone de test, dans la mesure où il m’a semblé plus important par la suite de cartographier en priorité des zones qui n’ont pas été couvertes par l’EMSR780.
Application sur d’autres zones, mise à disposition des données et animation communautaire
Pour exploiter au mieux les zones couvertes par les imageries Pléiades, j’ai numérisé les zones non masquées par des nuages sur les quatre premières disponibles (celle du 24/12 étant pratiquement inutilisable). L’approche a ensuite été de créer un seul projet à la fois dans le Gestionnaire de tâches HOT, chacun centré sur une seule localité, afin de ne pas décourager les contributeurs face à de multiples projets ou à un grand projet comportant des centaines de tâches. Les premières localités évaluées sont des chefs-lieux de commune, sur les deux façades de la partie septentrionale de Grande-Terre : Tsingoni, Bandraboua, M’Tsamboro, Acoua et M’Tsangamouji.
Comme aucun rendu OSM ne montre ces classes de dommages, j’ai créé plusieurs styles pour la couche de bâti résultante du croisement des données OSM et Copernicus EMSR780, partagées sur des contextes MapStore (l’un en français, l’autre en anglais), avec une présentation de l’approche via les contextes cartographiques propres à MapStore. Les données sont bien sûr téléchargeables depuis l’interface.
Malgré une expérience personnelle de mise en place de projets dans le Gestionnaire de tâches depuis quasiment les débuts de l’outil, l’animation communautaire s’est révélée parfois surprenante : des échanges ou questions techniques classiques via les outils de commentaires de la plate-forme, mais également une proportion non négligeable de contributeurs, a minima de niveau intermédiaire (ayant donc déjà créé au moins 150 groupes de modification OSM) qui ne font que modifier la géométrie des bâtiments, sans caractériser les dommages ou le matériau de toiture, malgré les instructions texte et vidéos les plus détaillées que j’ai pu produire jusqu’ici. Sans doute le poids de l’habitude des projets du Gestionnaire de tâches, consacrés dans leur grande majorité à la création ou modification d’empreinte de bâtiments. Pour tenter d’y remédier, j’ai commencé à organiser des ateliers en visio (en anglais, français ou portugais) pour faire la démonstration de la manière de cartographier ces dommages, en mode tout souris ou via l’utilisation de raccourcis clavier pour aller plus vite.
Parallèlement à la poursuite de la coordination de cet effort de cartographie distant sur Mayotte, d’autres activités sont encore à venir :
- une comparaison de cette cartographie distance avec des données d’évaluations de dommages réalisées sur le terrain. Cela est déjà en partie réalisable avec les images post-désastre hébergées dans Mapillary, et tend à conforter les choix faits sur les imageries Pléiades, mais l’intérêt serait surtout de comparer avec des données d’évaluation menées par des spécialistes de l’évaluation de dommages des bâtiments
- la capacité de réplication de cet exercice, tant dans la documentation pour permettre à d’autres de reprendre cette méthodologie dans d’autres contextes, que dans l’accès crucial à de l’imagerie post-désastre.
