Local mappers have noted that, while the individual buildings are (as or writing) still standing, they are severely damaged by fire, and chances of immediate / medium-term reinhabitation are very slim. There is an implicit consensus that the buildings should be marked as “ruined”, skipping the “abandoned” state.
Sadly buildings which are heavily damaged by fire most times cannot be restored but have to be demolished and reconstructed. It depends on the scope of damage caused by the fires.
At the time being I would recomment do add ruins=yes to the existing buildings tags and observe the future development. I agree to @Mateusz_Konieczny that it is better to add ruins=yes to an existing building instead of changing the existing tag to ruins:building=yes.
ruined=yes is just a less used duplicate of ruins=yes so I would not consider using that.
I want to avoid ruins for consistency in the word form for lifecycle (disused= , abandoned= , demolished= ), different use from historic=ruins + ruins= (railway= is the one not using =yes / =no ), and any confusion from building=ruins as sham ruins (while it may be controversial)
This year saw a mass addition of ruins:building=
damage:*= seems to be confusing whether it’s only partially damaged=
There’s the undocumented damage= for the severity, and =total , =destroyed , =complete overlapping with others from destroyed:*=
If anything, I would “reverse import” OHM’s start_event=
No, it’s largely used to describe damages.
For the subjectivity of some tags, see the two articles below (in French and English) to make a better assessment:
However, for such a fire, @Map_HeRo is right, the logic is: find the root cause, destroy the buildings, build something new.
Sometimes for political reasons, the skeleton is kept, but as the concrete has suffered, the total cost is higher. But the politicians didn’t do what the previous politicians had decided…
damage:*= : Is described as “is a lifecycle prefix” already, meaning it overlaps with ruin*=
damage:event= : Various formats being underscored, unspaced, spaced, hashtags, and id. =war has not been handled properly.
damage:type= : Described as “The type of the event”, so actually belongs to damage:event= side. As seen from damage:event=war + damage:type=explosion , they are mixing up the cause event, and the mechanism (eg fires can be caused by earthquakes), not to mention the meaningless *:type= suffix. =collapse is actually not that bad, for small collapses.
Eg damage:Chido:*= : Using non-finite freeform text naming is not the best idea
damage:*:event= : And yet another format of what *:event= can be used in. More of an *:ID:GLIDE= for numbering.
Does any application actually use damage:*= though? Taginfo only records a JOSM preset. If not, it’s akin to pushing a octagonal stone wheel cart, instead of driving a car.
There’s only the damage:Chido:*= format they developed. Seems no damage:event= + damage:type=` then?
Ps naming it is still not unique, as typhoon names can be reused in eg Western Pacific, unless requested to be removed for damages. Also I wondered how it’s named for aftershocks.
As said, damage:event:wikidata provides unicity, as here for instance. Valid also for earthquakes. Normally if the name of the event is based on the Wikipedia page, it’s unique too.