Important to note here that the point of this is not just to improve the map so that it reflects Gaza before the bombardment started, but to make sure the basemap is as accurate as it can be before doing post-event mapping.
A bit like @Mateusz_Konieczny suggests in his comment above, we would want to map damage to buildings in Gaza, but this would be by adding attributes (damaged / destroyed). And, these attributes would need a building footprint to be added to.
We are concurrently working on how to do this, so nothing specific to share yet, but wanted to clarify that bringing OSM data up to date for Gaza pre-October 2023 is a means to an end, not the end in itself.
as existing building would not improve quality of OSM data. (By “foreground” I mean area to left of four human figures, excluding structures in background that may be still described as buildings)
Adding some “actually this building does not exist anymore” property does not really help. It is better to not map it as currently existing building.
(note, currently existing objects such as pile of rubble is mappable - though I prefer to not encourage or discourage mapping in Gaza as I lack thorough knowledge of situation that I would need to feel safe about reccomending anything in one direction or another)
Adding some “actually this building does not exist anymore” property does not really help. It is better to not map it as currently existing building.
Disagree here. Knowing the locations of pre-event buildings and their damage state is super important for recovery efforts. Those buildings correspond to something someone owned and will want to rebuild, or at least get support to do something new on the same plot. It also gives idea of what areas could conceivably support a returned population and when.
I might be missing something, but isn’t this exactly the situation that lifecycle prefixes are intended for? (Perhaps that’s what you were hinting at?)
The wiki even gives the example of demolished buildings that are still visible on aerial imagery.
It sounds like the Gaza situation matches this pretty well. Buildings have been destroyed, but available aerials don’t yet reflect this. Simply deleting or not mapping them would be error-prone, as someone else might re-add them from aerials without realising they’ve been destroyed?
OpenHistoricalMap is a good suggestion. As another post mentioned humanitarian use with OSM is well established so we are starting there. I do agree that I think now is a good time to look into how OHM works, licensing, etc to consider if it would work or not for some humanitarian use cases. So we haven’t made a decision yet but are interested in the conversation.
One other caveat about mapping anything in Gaza - the area was adversely affected by the anti-Israel vandalism such as node drags that was described here (as were places further afield such as Greece and Turkey, because coastlines are connected). A query such as this can be used to search for objects last edited by a user in an area - any edits by the accounts in the linked list are definitely worth looking at. Also, any regular geometry errors caused by node drags are probably best resolved first before HOT mappers start making other changes.
Not specific to here, but the usual caveats for organised editing apply - ensure that it’s clear what editing is being done and who is doing it (to make it easier to e.g. undo any accidents afterwards). Another nearby area (the West Bank) has suffered at the hands of well-meaning humanitarian mapping in the past (to be clear, this was not HOT) - it’d be great not to repeat that here too.
I doubt it applies here. Maybe in some cases, if there are still some remains of that building, razed:building=yes could be applicable. Though as @jessiepech mentioned above, there is no such data available for OSM/the project. So the tag might match the situation on the ground, but there is no source available to add this information.
Hmm, that’s not the understanding I came away with from reading the wiki. Quoting from the lifecycle prefixes page:
Using lifecycle prefixes it is possible to clearly mark that specific object must not be remapped without proper verification. Once there is no real risk of remapping them by person thinking that this objects are still existing such elements should be deleted from OSM.
So it sounds like the purpose of the demolished/razed/destroyed/removed prefixes is not to say “there’s still some remains here”. Instead, they’re saying “there was something here until quite recently - it might still be visible on your imagery, but don’t re-map it!”.
Is the wiki wrong here, or am I misunderstanding it?
there is no sources available to OSM (except mapping on the ground) that enables to map the current lifecycle status and would only allow mapping the status before October 2023.
Of course demolished buildings can be added to OSM. If this is the aim, it would beneficial to explain how this should be done without available sources.
In other words: You want to map something in order to avoid it gets mapped?
Ah right, I understand your point now. Makes sense.
I’ve no idea how much of this exists, but on-the-ground photos/videos published under an appropriate license could be used by remote mappers to set lifecycle statuses?
I’d assumed “there is no publicly available post-event imagery” was in reference to aerials only, but perhaps I have that wrong.
It sounds silly when stated like that, but yes that is the purpose of those lifecycle tags
For buildings destroyed in an attack, either of these two lifecycle tags would work:
ruins:building=* wiki: Only ruins are remaining. usage: ~3,400 (as of 2021-04)
destroyed:building=* wiki: Destroyed by an event other than intentional demolition. usage: ~5,300 (as of 2021-04)
When the building may be still standing on imagery, it is a good idea to use these tags rather than deleting the building because another mapper may come around and add the building back (based on imagery)—if it was tagged as razed or destroyed, it would show up in the editor still.
Most of the times OSM “buildings” are rectangles with no height, levels, roof type nor surface. Hence, whenever reliable sources will be available, a buildings baseline is anyway useful for retagging such rectangles in brown field or using namespaces like destroyed, abandoned, disused.
Just for info, we are also responding to / incorporating advice and guidance (and ideas) from the above thread into the wiki page @jessiepech posted up top…
Hi all. Thank you for all your comments and suggestions. HOT and its partners are interested in exploring mapping building status in OSM. There is a recognized need that we have been discussing for one centralized platform to store building status (ie destroyed) and there is strong interest in using OSM from all sides. The tagging advice is particularly useful, and we are taking note (see wiki linked above).
“Please do not adapt or delete any objects which have been mapped as damaged or destroyed, they are likely to have been identified from more up-to-date sources.” is there, what is a good thing.
But maybe even more clear “Building now marked as destroyed or ruined but visible on aerial imagery as existing likely should not be edited as imagery predates conflict.”
