Proposal talk:Demolished
date questions
I like this key. A few questions:
what is the format for the date? the example provided leaves this ambiguous.[Update: found this in the sidebar and corrected in article] it seems pretty important that this is consistently applied, else it can't be accurately interpreted. FWIW I've used dd-mm-yyyy (as OSM's native language is en-GB AFAIK) but would prefer yyyy-mm-dd for computational efficiency and sorting.- can we accept partial dates (e.g. if only the month or year is known)? this would work better with the yyyy-mm-dd format of dates BTW
- can we populate with the value "yes" if the date is unknown?
--Hubne 06:19, 15 April 2011 (BST)
I favour specifying ISO8601 date format. Standard, documented and unambiguous. -- User:EliotB
Please use standard formats like ISO8601. Making month and day optional, and allowing "yes" would be beneficial too. I'm a Brit myself, and I don't recognise dd-mm-yyyy until I twig you probably meant dd/mm/yyyy (and why aren't you using normal, sortable, unambiguous ISO-format dates?) --achadwick 22:42, 5 June 2011 (BST)
Data inconsistency: please recommend namespacing tags affcted by the demolition
This tag suffers from the same data consistency problems as disused=* and abandoned=*: see the pages linked for details. To quote the page for disused=yes:
- In practice, computer programs which use OSM data such as renderers or routing engines cannot be expected to distinguish between, say, a parking structure tagged just as amenity=parking, and one marked both amenity=parking and disused=yes without special rules. Therefore it's necessary to tweak the tagging so that such programs do not see confusing data.
For both of the above tags, I've suggested using the corresponding namespace as a suitable "tweak". Almost as a way of storing the tags which are no longer relevant as a result of the disuse or the abandonment. It's backwards-compatible, at least. The main page for this tag should be updated with some similar wording. It's particularly important to make the recommendations backwards-compatible with software without special handling for demolished=* because routing software may route users to (or along) rubble in this case. Demolished objects will also render as normal objects.
--achadwick 22:37, 5 June 2011 (BST)
Please move to Key:demolished
... since the wiki is case-sensitive ☺ --achadwick 22:39, 5 June 2011 (BST)
"Map what's on the ground"
- -1 on this tag. The general rule and consensus in OSM is to map what's standing and relevant on the ground right now, not historical data, I can't agree with this tag. Demolished objects are fairly obviously no longer still standing or relevant - unless they're a building site now. We have a separate tag for that. Even so, if you choose to go ahead with it, I hope you'll take on board my suggestions above. --achadwick 22:50, 5 June 2011 (BST)
- Yes, this is a terrible idea. Unverifiable, makes using data even more complicated etc. Any demolished object should be removed from OSM Mateusz Konieczny (talk) 07:31, 17 July 2014 (UTC)
- No reason to not have a scheme to tag demolished objects.
- sometimes demollished objects are still visible or even important obstacles
- several initiatives want to map historical objects in separate databases. The tags - if possible - should be still documented and compatible with main OSM
- RicoZ (talk) 22:10, 19 December 2014 (UTC)
This is very relevant considering many residential areas recently devastated by tsunami, earthquakes, wars, etc. Remains still visible on the ground in recent images. It should be actualized buildings that eventually have been reconstructed or replaced ancient ones. I think the perimeter of demolished buildings should be rendered like a line (like for wall) in "demolished=building".
Maps have a purpose. One of the main purposes is for navigation - through a network of "ways". Given that a right of way along a track that has been ploughed up is still a right of way, even though no track is visible, it is important that the track be marked on the map in some way to maintain the connectivity of the network. I am currently marking sections of public tracks (voie communale or chemin rural) that have been ploughed up as abandoned:highway=track rather than demolished:highway=track which would be far more appropriate as they have be destroyed but not necessarily abandoned. --TinyTrouble (talk) 08:31, 13 May 2022 (UTC)
Move to rehabilitate (use ISO dates, recast as a namespace, strongly discourage use)
Per [1], I move that we "rehabilitate" (basically, do away with) this broken tag. I propose
- Modification of this page to avoid bad data creeping into the database, by:
- Rewriting it as a namespace in a similar manner to abandoned and disused;
- Altering the date specification to be Right, namely the ISO 8601 date formats.
- Strongly discouraging its use altogether.
See the linked mailing list thread, or the discussion topics above, for further details.
--achadwick (talk) 17:27, 27 June 2013 (UTC)
redundancy to end_date
If this is used the same way as end_date=*, as is currently proposed, it is quite redundant. Perhaps it can be a yes/no value, to indicate if the tagged object was destroyed (since end_date can mean when that usage of the object stopped). Abbafei (talk) 06:36, 17 July 2014 (UTC)
Or perhaps it can be a namespace tag, like disused=*; for example demolished:building:yes or demolished:highway:tertiary. This can even apply for anything which no longer exists, even things to which demolition does not apply (like a leisure=sport). Abbafei (talk) 06:41, 17 July 2014 (UTC)
Currently proposed for namespace usage @ Comparison of life cycle concepts. Abbafei (talk) 06:08, 25 January 2015 (UTC)
- end_date is dead and especially not usable to mark demolished objects as they would still appear on the map and confuse existing applications. I do not think it is proposed in Comparison of life cycle concepts but should be merely listed there for completeness (and as an example how not to do it). If you see any places where end_date is endorsed in this way please add a big fat warning there.
- I believe this proposal is dead for the same reason and indeed demolished: used as namespace prefix is used instead of it. I will edit the proposal to reflect this. It is a damn serious deficit of the current wiki templates and taginfo that it is impossible to create functional key:namespace entries in the wiki.
- RicoZ (talk) 12:33, 25 January 2015 (UTC)
This tag very important as an aid to locate existing features
Imagine a high voltage power line, where the line and towers have been removed, but the foundations of each tower remain.
You know, like "Laser maps reveal 'lost' Mayan treasures in Guatemala jungle".
OK, with a little weed cutting one can indeed dig up the concrete base of each pylon, and indeed they form a quite straight line on the map. Quite like flat topped Mayan pyramids, albeit a little smaller.
But that would take a big effort.
Therefore we see that being able to simply place the (mostly known, e.g., from electric company museum records) original location of the line, albeit tagged as demolished, would indeed make the string of future tower location archaeological sites all make sense. Also it would help mappers narrow in on possible tower locations (where the line crosses a ridgeline, and there is a suspicious flat area right at the junction, etc. in the absence of cadastral maps.)
Yes, we don't want the line rendered. But the location of it is still valuable data for locating current objects (giant tower bases.) Jidanni (talk) 12:05, 26 October 2020 (UTC)
- Sure, when all the bases are finally mapped, perhaps they could be added to a relation. But still the former power line still makes sense to map, (but not to render. Only the bases should be rendered.) Jidanni (talk) 12:59, 26 October 2020 (UTC)
- Ah! Tag:removed:power=line for the line! Jidanni (talk) 05:07, 27 October 2020 (UTC)