EN version below
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.
Translated with DeepL.com (free version)
OSM mapping of building damage in Mayotte after cyclone Chido
On December 14, 2024, Mayotte was hit by Cyclone Chido, the most violent cyclone to hit the island in over 50 years. IGN quickly released Pleiades imagery taken on December 17, 18, 20, 21 and 24, and confirmed on December 25 that the OSM community could use it as a source for its editions. I immediately wanted to use them to assess damage to buildings. Why buildings? From a cartographic point of view, because damage is more visible on polygonal infrastructures than on punctual or linear ones. From a crisis-response point of view, because the damage was particularly extensive, having made the homes of many inhabitants disappear or impassable.
Three months on, this post takes a look back at the major stages of this ongoing mapping project, organized on a voluntary basis in my spare time.
Review and methodological choices
Mapping building damage using post-disaster imagery was obviously not invented in OpenStreetMap, and similar experiments have been carried out in the past in OSM.
After Cyclone Haiyan hit the Philippines in November 2013, building damage mapping had been carried out in the region around Tacloban. In March 2016, researchers at the Harvard Humanitarian Initiative (HHI) published an article detailing a methodology that was subsequently adapted to OSM in the form of preset models and a cartographic style for JOSM, and applied to Haiti after Cyclone Matthew in October 2016.
The Haiyan approach is limited to two labels for damaged buildings, using the building=* key directly, which is not ideal. The BAR approach had so far been adapted in OSM via two specific keys damage=* with the four categories of damage defined by HHI researchers (none, minimal, significant and complete) and damage:structure to qualify the type of construction according to three categories (light, medium, heavy). After tests carried out on Miréréni, using BD Ortho IGN and Pléiades imagery, and discussions with a geographer living in Mayotte, it became clear to me that while the damage classes were easy to determine, the construction type was difficult to determine directly, as the only element still visible was the roof. In addition, the intermediate “medium” type seemed difficult to classify.
Consequently, rather than adding a label deducing a construction type from fragmentary elements, I preferred to map only the roofing material with the already existing and well-documented roof:material key. In the case of Mayotte, roofs are generally of two types, either a metal sheet roof of varying quality, whatever the size or use of the building, or a flat concrete slab which is in fact the floor of a future storey yet to be built.
During initial tests, the damage key was reused, but it has the disadvantage of quickly becoming obsolete, as soon as a building is repaired that is damaged rather than destroyed. And even if it’s not deleted despite its obsolescence, it will be difficult to know what event it refers to. That’s why I finally opted for a key damage:DisasterName=*, or damage:Chido=* in this case. The same logic of inserting the name of the disaster prevailed for the metadata tags to inform the name of the event, the source of the imagery used and its capture date.
This methodological review was also an opportunity to document the OSM wiki, with the creation of two pages: https://wiki.openstreetmap.org/wiki/FR:BAR_methodology on the BAR methodology and its first OSM adaptation, which had not yet been documented, and https://wiki.openstreetmap.org/wiki/Building_damage_assessment for this new adaptation focused on the built environment.
Methodology testing and interactions with EMSR Copernicus data
In the first days of January, Pleiades imagery was integrated into the imagery available from the JOSM imagery menu, and the first versions of the new preset model and its cartographic style for JOSM were produced and tested on a small area of Mamoudzou. The only unforeseen problem was the average quality of the building geometry, which sometimes needed to be rectified. On January 6, a project on the central area of Mamoudzou was created in the HOT Task Manager and opened only to intermediate or advanced OSM contributors, with detailed instructions accompanied by videos in English and then in French. During the few weeks of this test, the labeling is slightly revised (the integration of the disaster name in the keys, mentioned above) and the cartographic style is completely redone.
Discussions took place within the OSM France community (see this forum thread) and the methodology was validated by a representative of the CSTB for the purposes of rapid damage assessment. The choice of Mamoudzou also enabled us to compare the results of this community mapping inspired by the BAR methodology with the rapid assessment carried out between December 15 and 24 as part of the Copernicus program’s EMSR (Emergency Management Service Rapid mapping) 780, which focused on the central eastern face of the island of Grande-Terre and also on the island of Petite Terre.
The EMSR building damage data, available as open-licensed files (although not very clear), consist of vector points at the center of buildings, with three different classes: Possibly damaged, Damaged, Destroyed, which seem to correspond to the BAR methodology’s minimal, significant and complete categories. This means that there is no class for undamaged buildings, and in fact many buildings in the area under assessment have no points at their center. The limitation of this approach is that the proportion of damaged buildings in relation to the total number of buildings cannot be determined using Copernicus data alone. Furthermore, “possibly damaged” may also appear as an intermediate class between ‘none’ and “minimal” in the BAR methodology, so the two assessment scales may not overlap.
I’ve set up an automated cross-referencing of Copernicus point values with OSM buildings updated via diff minutes, and a measurement of the differences between the two assessments. This means that for each building evaluated by the two methodologies, we can see the class differences between the two evaluations. It turns out that a difference of one class is more frequent than an identical class.
An analysis has yet to be carried out to explain these differences. However, this comparison was limited to this test area, as I felt it was more important to map areas not covered by EMSR780.
Application to other areas, making data available and community outreach
To make the most of the areas covered by Pleiades imagery, I digitized the first four areas not obscured by clouds (the one for 12/24 was practically unusable). The approach was then to create one project at a time in the HOT Tasking Manager, each centered on a single locality, so as not to discourage contributors when faced with multiple projects or a large project with hundreds of tasks. The first localities to be evaluated are commune chief towns on both sides of the northern part of Grande-Terre: Tsingoni, Bandraboua, M’Tsamboro, Acoua and M’Tsangamouji.
As no OSM rendering shows these damage classes, I’ve created several styles for the building layer resulting from the cross-referencing of OSM and Copernicus EMSR780 data, shared on MapStore contexts (one in French, the other in English), with a presentation of the approach via MapStore’s own cartographic contexts. Data can of course be downloaded from the interface.
Despite my personal experience of setting up projects in the Task Manager since almost the very beginning of the tool, community animation has sometimes proved surprising: classic exchanges or technical questions via the platform’s commenting tools, but also a not inconsiderable proportion of contributors, at least of intermediate level (having therefore already created at least 150 OSM modification groups) who only modify building geometry, without characterizing damage or roofing material, despite the most detailed text and video instructions I’ve been able to produce so far. This is undoubtedly due to the habitual use of Task Manager projects, the vast majority of which are devoted to creating or modifying building footprints. In an attempt to remedy this, I’ve started organizing video workshops (in English, French or Portuguese) to demonstrate how to map this damage, in all-mouse mode or using keyboard shortcuts to speed things up.
As well as continuing to coordinate this remote mapping effort on Mayotte, other activities are still to come:
- a comparison of this remote mapping with damage assessment data collected in the field. This is already partly feasible with post-disaster imagery hosted in Mapillary, and tends to confirm the choices made with Pleiades imagery, but the interest would lie above all in comparing with assessment data carried out by building damage assessment specialists
- the replicability of this exercise, both in terms of documentation to enable others to take up this methodology in other contexts, and in the crucial access to post-disaster imagery.
