It seems there is no information about this online, so I am asking.
Currently, we have the handy building=construction tag-value to describe a building that is inside a construction area and is being worked on. We also have the construction=??? tag to describe the building type that the building will get after construction finishes (i.e., change construction=??? to become building=???).
But I believe there is an overlooked case. What if the building is indeed being worked on, but the work is to demolish it? (Of course, by this tagging, the building structure is still visible on the ground, just that it’s gonna be gone later.)
I personally use construction=demolition in this case, but it seems best to make this part of the OSM canonical tagging standard, to fill in the gap between building=yes and demolished=building.
That’s a great point, and building=demolition would indeed fit the template of building=construction.
The only problem I have with this idea is that demolition is usually a relatively quick operation. Lasting weeks or perhaps one or two months, whereas construction usually takes several months to years for full completion. The problem with this is that many consumers update their data from the OSM database relatively infrequently, which is why we usually don’t tag fast processes.
Important is to leave the original demolished object on the map so the next one using old imagery will not remap it again, in fact 2 mappers came to my town, who deleted the new buildings of the 2 projects that had a start date on them to boot, and mapped the old buildings back in so I reverted that and tagged the demolished buildings accordingly for the next wanderer.
Mapping an area as construction=demolition would be OK. Put a check_date tag on it. The system will flag such objects periodically. We have a de-construction here of motorway trunk overpasses since end of december, so I update the check_date whenever observing. progress… 2000 cubic meters of armored concrete to wreck and transport off according the construction work-board (legally required here). Osmose e.g. will at times ask 'has this construction finished?. StreetComplete does so too, but have disabled that quest… too many constructions that will lay dormant or last 10+ years.
Yeah, sorry, I meant to say this as well in my post above. The lifecycle prefixes are indeed important for that very reason (and include the demolished:*=*-pferix). But the building=demolished value @vectorial8192 is proposing isn’t really a lifecycle tag as it would reside in the building= keyspace.
I don’t like this approach. We map stuff like construction=minor so why shouldn’t we have a tag for buildings undergoing demolition? It should exist at least for buildings that are going to be being demolished for several months.
It’s not a good idea to only have a binary built or demolished, especially if it’s not a binary option for buildings being constructed.
First of all, let me say that I’m not entirely against the new tag, just that I see fundamental issues with it that should be addressed if it were to be formally introduced.
I should also say that reasons why e.g. building=abandoned was deprecated might not apply here, but building=demolitioncould be viewed as problematic by some for the same reasons.
As I’ve understood it, one of the reasons for that tag is precisely so that data consumers who update infrequently can just ignore small or quick construction going on. If you update your data once a year, you don’t want a construction site that exists for a few weeks to show, just because you happened to update the data when it was going on.
Indeed, if the new key would be accepted, it should be made clear that it too describes a quick process, and that people who update infrequently should treat those buildings as already gone.
Like I said, building=demolition does fit the template of building=constructionin OSM-speak, but the actual processes of building something up and demolishing something have essential differences. This is in fact a general truth, or a law of nature: entropy is one way. It takes a lot of energy to build any kind of structure in the universe, but its dissolution to the lowest energy state is a natural tendency. So it takes a lot of energy and time to build a structure, but its demolition is relatively easy and quick in comparison.
So what I’m mainly talking about is a shopping centre being demolished which will take a few more months now. This also means that a barrier surrounding the deconstruction area can be mapped, the surrounding footways and paths got access=no because they’re now blocked off (access:practical=no would be more precise!). There’s also landuse=construction instead of =retail.
I guess you’d want all the other elements to have tags like temporary=yes or access:temporary=yes (or maybe access:temporary=no?) but not everybody wants to add all of these tags to everything and this approach is definitely not popularized.
Would this tag be better or a prefix? Since the goal after is to turn it into demolished:building=* if not to delete.
Indeed, if the new key would be accepted, it should be made clear that it too describes a quick process, and that people who update infrequently should treat those buildings as already gone.
Our map data is often downloaded and used offline on various devices for several weeks or months. For offline data to be useful, it should at least be expected to remain unchanged in the next few weeks when you map it.
So yeah, if the demolition takes more than the “several months” described above, it wouldn’t be temporaneous anymore.
So you want buildings to be marked as not existing anymore despite them existing still for a couple months but you want paths to be mapped as inaccessible even if they will be accessible again soon. If you update data once a year then you’d definitely want to ignore temporary paths and temporarily blocked paths.
maybe we are talking about different things? I was referring to abandoned buildings, i.e. buildings left to natural decay. Buildings that get actively demolished can be seen as already gone, I agree, because we do not map temporary features that last very short.
Oh, thank you for the note. We indeed were talking about different things! I agree with you about the problem concerning demolition.
For abandoned buildings, the Wiki suggests that buildings still standing keep their building=* values, but abandoned ones receive the abandoned: prefix. The idea is that e.g. a hospital or a church that is still standing is still a building=hospital or a building=church, but the ones that have been abandoned are tagged with the prefix that indicate that specific state.
I didn’t say anything about the paths here. I noted that I was against the :practical postfix. Otherwise I think you should be able to glean what I meant above.
The Good practices guide I linked to earlier doesn’t distinguish between temporary features. The idea that quick processes ought not be tagged (or tagged with a key that specifies this) applies across the board. The construction Wiki page says explicitly:
Major road and rail construction schemes typically take several years to complete. […]
Already existing features may be closed for a short time for temporary construction (e.g., old, damaged roads getting rebuilt or a road closed over a weekend to replace a sewer pipe). Don’t use construction=* to tag such short-term closures, consider using conditional restrictions instead.
But still, let me be blunt: you all are evading my question.
If the demolition is to be completed in a short time, say maximum a month, then yes, we the OSM community already know what to do: replace building=yes with demolished=building, or other equivalent lifecycle tagging, and wait until the satellite imagery updates.
You all kept debating what we should do if the demolition would take 1 - 2 months (while entropy is a valid talking point, why would you quote it here?), to evade by limiting the scope. But, that’s exactly NOT what I am asking.
It went through demolition for at least one whole year. This is clearly not a “temporary situation”. Even if you try to evade by “what about data consumers that only update once per year”, it won’t work since the demolition period still spans through the hypothetical update frequency.
By OSM principles, we must tag what we see IRL. Some OSM features can be clearly seen undergoing demolition for an extended amount of time, and we should describe them as such. Given the lack of documentation on what to do about “buildings undergoing demolition”, let me ask again once more:
I definitely am not. I brought the same points as you against not tagging demolition and proposed another option for the tag. @Tolstoi21 said building=demolition is fine also.
For reference, I add construction:demolished:building= to the building= to mean it’s in progress of being “constructed” changed to be a demolished:building= . That’s similar to the logic of proposed:demolished:building= before it starts demolition.
If a more proper and single-namespace solution is sought, I might suggest directly demolishing:*= , as demolition:*= following construction:*= may be confused with demolished:*= . But this doesn’t solve the proposed:demolished:building= case.
I don’t like another building= . It’s not as “minor” construction=minor , and other building= + construction= are often misinterpreted or editing mistakes.
A simple feature such as a building that fell into decay might be tagged with building=yes + abandoned=yes. This is fine and preferable over lifecycle prefix as long as it is still a building.
and building ruined enough to not be a building anymore does not really qualify for abandoned:building - it is rather ruined:building
Oh, indeed! I linked to the incorrect wiki page. Thanks for the note! The rationale for deprecating building=abandoned is explained in that Wiki page thusly:
Normally building=* is used to tag construction type, for example building=church is for any building constructed as a church, no matter how it is used currently. building=abandoned erases distinction between abandoned church, abandoned warehouse, abandoned barn and so on.
One might argue that similar considerations would apply for building=demolition.
