@Jorieke_V @SColchester Since the new thread is about flood damage and not wind damage, I will post my (long) answer here because it does not apply to flood damage.
Keep the damage tag?
The issue of whether to keep the damage tag may appear as a short-term vs. long-term approach regarding a tag that informs about a past event. Those in favor of the short-term approach consider the damage tag a “historical” tag that should not remain in OSM but be tolerated for a few months following the disaster. However, this historical feature is not only related to a past event.
First, “historical” does not mean that it is unrelated to the current situation. There are historical tags in OSM that are commonly used and accepted. The most common example is start_date=*, a de facto key that is difficult to verify on site and has occurred more than 17 million times in OSM. It is certainly very interesting information for the present. A building constructed ten years ago likely has different characteristics than a building constructed fifty years ago.
Some people seem to consider damage as something temporary by nature. If I may quote from past discussions in the forum: “Of course, if the damage is repaired, the damage tags should also disappear from OSM.” However, I disagree with this opinion because the repairs may not restore the building. From my discussions with architects based in Mayotte, I learned that damaged buildings may never be the same and that being hit by Cyclone Chido will become an intrinsic feature of them. Even buildings that appear unaffected are expected to encounter problems in the future due to Cyclone Chido and the frequent use of poor construction techniques. This is also typically the case for buildings with concrete roofs that serve as basements for future floors. These buildings seem unaffected, but they often have cracks that are not visible in satellite imagery.
Consequently, it makes sense to keep information about such dramatic disasters whose damages will leave scars for decades. This may not be the case for every disaster, nor may it be appreciated by those responsible for damage evaluations.
Inform about the event name
Such a cyclone has not affected Mayotte for decades, and we hope it will not happen again for at least the same amount of time. However, it may occur more frequently in the future due to climate change. Therefore, I would not use just the simple damage key as proposed, but rather keep the damage:[disaster_name]=* approach, because it could cause confusion if a second major disaster occurs.
Cover all cases
I do not understand why the “no damage” case should be excluded. The international ISO 19011:2018 standard for auditing processes requires marking non‑applicable items as “N/A” and recording “None” or “No observation” when an item yields no finding. I mention this not to say that we should necessarily follow ISO standards, but it is widely accepted that leaving uninformed cases is confusing. I experienced this when I compared the results of the BAR-inspired assessment in OSM with the Copernicus EMSR assessment.
The current damage tagging I implemented in the presets currently misses at least one case: when evaluation is not possible based on the imagery. We could specify the reason: cloud coverage or hidden by a taller building. In Mayotte, the Not applicable (N/A) case would be used at least for buildings in ruins. There may be other cases, in Mayotte or in different contexts.**
“No roof” is also interesting information, but there is no official tag for it. The key:roof tag is deprecated, except for “roof=no”, which has the most occurrences: https://wiki.openstreetmap.org/wiki/Key:roof. I added it to the latest version of the presets.
Using the BAR methodology for other types of natural disaster
I want to emphasize that the BAR methodology was designed by its authors for wind damage. Using it for other types of disasters, such as floods, may not be appropriate. From imagery showing floods, you can usually see how the road network is affected. You may also see flooded gardens. However, I don’t know how to evaluate whether the building itself is flooded or how to distinguish between three levels of damage using vertical imagery.
Reviewed tagging proposal
Damage tagging
damage:[event]:none,minimal,significant,complete,hidden,not_applicable
or if we want to be more specific:
damage:[event]:none,minimal,significant,complete,hidden_by_clouds, hidden_by_building,not_applicable
The absence of this tag indicates that the building was not evaluated.
Roof tagging
Since roof materials are a key factor in both the initial damage and future vulnerability when cyclone Chido hit, and since the tag may naturally evolve (especially in this cultural context, where people build their houses floor by floor over a long period of time), it makes sense to include it in an event tag.
roof:material:[event]=metal, concrete,[…],no_roof
While the material types are globally diverse, there are generally only two or three in every cultural context. The absence of a roof would also be noted.
Long term tagging?
I find the numerous existing tags (unrelated to damages) for the buildings in Mayotte really informative. But I know some OSM contributors would like the number of tags to be as minimal as possible. We can imagine a long term tagging made by the evaluation coordinator(s) for the whole affected area once the damage mapping is over. It would merge both the damage categories and the roof material. This tag would be:
damage:[event]=[none,minimal,significant,complete)roof(none, metal,concrete,wood,ceramic,straw…]
For Chido in Mayotte, we would have for example:
damage:Chido=significant_with_metal_roof or damage:Chido=none_with_concrete_roof
Context tags
Ideally, these tags would be set on changesets rather than on objects. Unfortunately, the Tasking Manager does not yet allow project managers to set changeset tags or aliases for the imagery source. For the latter, it uses the URL by default. These URLs are very long for the Pleiades imagery in Chido.
I used source:damage:Chido=CNES / Airbus, but some people thought it read strangely, as if the imagery were the source of the damage. Would source:damage_survey:Chido=CNES / Airbus solve this?
I think I will delete the damage:Chido:event=TC-2024-000225-COMtag. It provides the GLIDE number of the specific disaster, which can be found on this reference site. However, this should only be a changeset tag.
destroyed: lifecycle tag prefix
For those unfamiliar with the lifestyle approach proposed in 2015 aund used since, see its wiki page : Lifecycle prefix - OpenStreetMap Wiki. For destroyed:, see Key:destroyed - OpenStreetMap Wiki. I am not opposed to it, but it seems it still has an “in use” status, not an “approved” status.
I can edit the JOSM preset to replace the building=yes with destroyed:building=yes (or battle a bit with condition if we want to maintain other values). This would require to have a specific preset dialog for every damage class, but that is not a big deal.