Talk:Lifecycle prefix

removed

The current definition for "removed" reads: "features that do not exist anymore or never existed but are commonly seen on other sources". I propose to remove the part "or never existed but are commonly seen on other sources", because this has nothing to do with "removed". If people want to tag easter eggs or errors from other maps in the OSM db they should use a distinct tag for it. --Dieterdreist (talk) 12:16, 28 January 2015 (UTC)

Definitely, this was cut&paste from Comparison of life cycle concepts and a few other pages and probably needs a few more cleanups. RicoZ (talk) 13:12, 28 January 2015 (UTC)

I still have a problem with the current definition, why would we encourage to tag "features that do not exist anymore" ? I believe that the consensus for not existing feature is to simply remove them from the osm DB. My proposition is the following : features that don't exist but have an high probability to be re-added by a non surveyed edit because they can be seen on commonly used imagery or import sources

If one still want to propose a tag for features that do not exist anymore, without beeing more specific, I'd suggest to add a tag like removed:reason=nonexisting or to propose a new prefix : nonexistent:building=yes sletuffe (talk) 18:15, 4 February 2015 (UTC)

Currently the page has this big fat warning: "Generally historic objects with no relevance to current state of a site do not belong into the main database". We do not encourage it. In some cases it may be appropriate. More importantly if there are any databases of historic objects or other special databases they may choose to use some of the lifecycle prefixes for their purposes. Documenting this possibility here will hopefully help to keep the data models consistent so the data can be mixed without too much trouble. RicoZ (talk) 21:07, 4 February 2015 (UTC)

Sorry, I missed that warning. What I understand when reading Dieterdreist is that my usage of the removed prefix is not well suited because of the meaning of the word removed that implied it existed. At first, I didn't care about such slight differences that is why I wrote the first definition usage of removed as beeing wide to include any reasons why an object is no more. And because the destroyed prefix allready existed for that purpose. But ok, I'll use another prefix for my/our needs about easter eggs or errors from other maps. The no: prefix looks short, not used too much and does'nt necessarly have a meaning of "it existed". I'll move my documentation to a page for the no prefix sletuffe (talk) 22:04, 4 February 2015 (UTC)

Removed and demolished have implications on how something was made non-existent. As I may not know how it was made non-existent I would much rather see the use of a tag that encompass all. We should tag the result - what is there now. So for me 'nonexistent' is the better tag. Warin61 (talk) 22:14, 3 January 2018 (UTC)

in stead of creating one more namespace, it should be better to merge demolished: removed: former: to was:

no: can be keep to feature that never exist (for example to mark a error in an opendata feed that need to be fixed in "upstream" Marc marc (talk) 17:12, 4 January 2018 (UTC)

Yes, merging to one is what I am after. But 'removed' cannot be merged into 'demolished' as the meanings are a little different. They and 'no' could be merged into, say, 'absent' as that incorporates all these meanings, hopefully makes it clear as to the intent and makes it easier for translation? The meanings of 'former', 'was', 'past' and some uses of 'historic' (these designate a previous state) might be merged into, say, 'former'? Warin61 (talk) 22:08, 4 January 2018 (UTC)

Meaning of "demolished"

I think that demolished does not imply "without any traces left" and have no idea when and how it got into comparison of life cycle concepts from where I originally copied without much thinking. RicoZ (talk) 13:56, 5 February 2015 (UTC)

I'm the one who originally added that description in 11/2014 because there was a few usage in the db of the destroyed: prefix but no description of the exact meaning. From english dictionnary demolish : To tear down or break apart the structure of; raze. Without any other clues how have other mappers used it, I'm okay to stick to that definition. sletuffe (talk) 17:17, 5 February 2015 (UTC)

For me "demolished" means "intentionally destroyed beyond repair" - this definition also would make more sense and not conflict with the use of removed, destroyed,ruined. RicoZ (talk) 13:56, 5 February 2015 (UTC)

I'm unsure that we have less conflict however, the english definition of demolished doesn't forbid a state where there is nothing left from the structure. If demolition is "intentionally destroyed beyond repair", then it does not defers much from destroyed:. Beeing in a ruined state doesn't necessarly mean it was demolished (as demolished seams to imply "intentionnaly"), but if it was destroyed it could be in a ruined state or with nothing left. Tricky... and bike shedding imho sletuffe (talk) 17:17, 5 February 2015 (UTC)

There may be traces left or not, "demolished" does not say anything about this aspect. "Destroyed" can be the result of willful or accidental destruction by man - or natural disaster. In contrast "demolished" is more likely to mean intentional/planned destruction. It looks ok as it is now. RicoZ (talk) 20:43, 5 February 2015 (UTC)

Demolished does not include 'removed'. As the result of both is the vanishing of the feature and the mapper may not know the method that caused the vanishing both these tags are poor choices. Nonexistent is a better choice. Warin61 (talk) 22:16, 3 January 2018 (UTC)

ruined: or ruins: ?

Also, wondering if it should be really "ruins:" instead of the currently suggested "ruined:"? True - all other prefixes are formed as past tenses of verbs but semantically ruined:building=casino is simply wrong - it could suggest the casino is commercially bankrupt. "ruins:building=casino" does not have this problem. RicoZ (talk) 13:56, 5 February 2015 (UTC)

ruined is my choice. I don't see any incredible argument against one or the other sletuffe (talk) 17:17, 5 February 2015 (UTC)

for my language feeling "ruins:" is much better here. "ruined" is almost never used to describe the physical state of a building but instead the financial state (bankruptcy) of a business or a bank. "Ruins" is used to describe the heap of rubble left after a disintergated building. RicoZ (talk) 20:53, 5 February 2015 (UTC)

My native language is german so I did a search about this. "Ruined" on Wiktionary yields nothing, but Oxford, Cambridge and Oxford from 1914 all put our intended meaning first. And ruined really fit's best to all other common prefixes.--Jojo4u (talk) 20:02, 25 July 2015 (UTC)

As Jojo4u says - ruined fits. The past participle case of 'ruined' matches the case used by present popular tags of 'disused:' and 'abandoned:' Warin61 (talk) 22:23, 3 January 2018 (UTC)

I would go for "ruins:" since it is already established as a word in "ruins=yes". --Zetex (talk) 20:09, 30 March 2017 (UTC)

"ruins:" is better. It describes the state of the object, like "construction:". The less favourable "ruined:" may fit to other lifecycle prefixes ending with "ed". But those prefixes "abandoned:, demolished:, removed: or razed:" describe human actions to that object which isn't the case for a house burnt down in a bushfire (for example).--Hb 02:24, 5 February 2020 (UTC)

Vestige

Some are using 'dismantled:' to indicate that there are some indications remaining of the feature. For example a railway track that is absent but leaves behind cuttings, embankments and/or raised ballast. The word 'dismantled' does not mean this, 'vestige' is a better fit. So, "'vestiage' meaning some small trace of the feature remains". Warin61 (talk) 23:16, 4 January 2018 (UTC)

Testing possibilities to rename prefix keys

Hi, for testing purposes I have renamed key:disused to disused:=* and key:abandoned to abandoned:*=*. Want to see what works better for users and wiki search engines.. post your findings here. RicoZ (talk) 12:28, 29 March 2015 (UTC)

One problematic issue is that the tag template links to the version without the colon. See disused:building=church, for example. (And before you change the template, note that adding the : to the link would break links for tags like access:conditional). --Tordanik 15:54, 30 March 2015 (UTC)

This is just a test for the easiest workaround. Currently I don't feel like hacking these templates .. I admire people who can program this strange thing which reminds me of a brainfuck dialect but it is nothing for me.

Regarding access and access:, it could be done with redirects or the page could be split for access and access:* . RicoZ (talk) 19:53, 30 March 2015 (UTC)

Any progress on which is better? Best from my limited point of view would be Namespace:abandoned as the page title. From your two options: Key:abandoned:* looked very alien to me when first browsed it, I'd choose Key:abandoned:. --Jojo4u (talk) 17:40, 25 July 2015 (UTC)

Will look again, was away. RicoZ (talk) 12:19, 29 July 2015 (UTC)

Quite clearly, the version without the "*" wins in search engine comparison (google and builtin) so I am all for it. RicoZ (talk) 20:29, 30 July 2015 (UTC)

Thanks for unifying the tags. But where on the wiki can we discuss page names and descriptions of namespace/prefix/postfix/extension broader? I'm not convinced to use "Key:" for a Namespace. I also came accross Template:PrefixNamespaceDescription Template:PostfixNamespaceDescription here: Template:Description.--Jojo4u (talk) 10:56, 2 August 2015 (UTC)

Anything would be better than abusing "key:" but someone has to write the mentioned templates first. Only few people can do this. When that is done taginfo support needs to be done which only one person can do. Even as experienced programmer I am not enthusiastic about learning how to create complicated templates, have rarely ever seen something as painfull as template programming. RicoZ (talk) 11:33, 2 August 2015 (UTC)

To see what it involves, look here: User_talk:Moresby/Description#Rationale_for_this_new_template. It might help to ask around on various devel lists, forums, and here: User_talk:Moresby#Template_support_for_namespaces RicoZ (talk) 12:07, 2 August 2015 (UTC)

For the record, I'm not a fan of calling things like language suffixes "namespaces". That's a term people have imported from outside OSM, and it does not really fit the semantics. --Tordanik 13:53, 3 August 2015 (UTC)

Feel free to update Namespace#Nomenclature (which I created recently) to tone it down a bit.--Jojo4u (talk) 14:17, 3 August 2015 (UTC)

We can stick with using prefix and postfix, but how to name the whole concept? How to name the page Namespace? I agree that a suffix is hardly a namespace as we know it.--Jojo4u (talk) 20:13, 4 August 2015 (UTC)

I have started Proposed features/Namespaces in wiki. Agree that semantically prefix/suffix is better than namespace. It may make sense to treat them together in one overview page and technically in one future wiki-namespace and a common template. RicoZ (talk) 17:31, 5 August 2015 (UTC)

One possible alternative to calling them "namespaces" would be using the term "affix", which is an umbrella term for prefixes, suffixes, and infixes. --Tordanik 12:56, 6 August 2015 (UTC)

Many people would interpret affix as suffix, witkionary lists the other meaning as well but comes after suffix. RicoZ (talk) 11:08, 7 August 2015 (UTC)

And many people would interpret namespace as "a conceptual space that groups classes, identifiers, etc. to avoid conflicts with items in unrelated code that have the same names", which is the only definition of the term on wiktionary. If you don't like "affix", then let's call the page "Key prefixes, suffixes and infixes" or something. Namespace is simply wrong, even our prefixes aren't really namespaces. --Tordanik 12:04, 7 August 2015 (UTC)

Good enough for me if nothing better surfaces. Also I am wondering are there any "true" infixes or is so that those infixes merely result from situations where two or more affixes are combined? RicoZ (talk) 13:58, 7 August 2015 (UTC)

No, I think every key gets defined on it's own or as prefix or suffix. We should keep infix out of the wiki for the moment.--Jojo4u (talk) 17:24, 12 August 2015 (UTC)

New home construction stages

When mapping new residential developments under construction, I tag a home site as planned:building=house when it's obvious that a house has been planned to be built there. By that time, the lot has been graded and usually marked. Before the street was even paved, the infrastructure connections (power, telecommunications, water, sewer) would have been extended into the lot. Often some other detail such as the lot number ref=* and street address addr:street=* can already be tagged.

Only when the ground is actually broken for building the house (or at least the outline of the foundation has been chalked in for imminent digging) do I change the tag to construction:building=house. New taggable properties will soon appear, including building:levels=* (though JOSM complains about this).

I remove the construction: prefix only when the house is occupied by the new residents or advertised as "move-in ready" by the builder (or it's very clear that all construction activity has been completed).

--T99 (talk) 19:40, 19 November 2016 (UTC)

POI being refurbished

If a POI already exists, but it's closed temporarily and undergoing some construction work, what would be the proper way to tag it? -- SwiftFast (talk) 08:26, 30 May 2017 (UTC)

nothing immediately fitting, you could use "construction:" and/or opening times or makeup your own prefix. As it is both disused and in construction you could also use the combination "disused:POI" + "construction:POI" possibly with a date namespace postfix.RicoZ (talk) 09:17, 5 June 2017 (UTC)

I agree with "construction", but it would require to amend the definition, because "construction" is currently only defined for the initial phase of a feature.

What tag when the building is existent and in good shape?

I would like to tag states fo building, also when it's operational in good shape, what would be the best option when it's in good shape? Should we use operational_status=* ? Probably by Violaine Do on 13 July 2018.

If you tag building=something it is implied the building is existing.
Not sure how we could assess the building is in good condition, compared to which quality standard? Would there be different levels of good condition, which distinction would you propose to make? Shall we have subtags for different elements (e.g. roof, facade, structure)? I believe it would be difficult in terms of verifiability. —Dieterdreist (talk) 21:37, 13 July 2018 (UTC)

I see this as the default value, the usual condition - when the life cycle tags are missing the feature is 'alive'. You could see the feature as 'young', 'mature', 'ageing', 'renovated', etc. But still 'alive'. OSM does not normally tag the usual condition, this removes a good deal of work for both mappers and data consumers. For example roads are assumed to be oneway=no as that is the usual condition. Note that the lifecycle can be applied to all features not just buildings. Warin61 (talk) 23:02, 13 July 2018 (UTC)

Hum interesting! Actually there is so many places where tags are not filled, that we cannot be sure that it's filled when there is no info (i mean if oneway isn't filled doesn't mean that road is both way). I would not guess that all the buildings drawn in OSM from remote through HOTOSM projects are in good state for example. Thing is that in development world, buildings can be used but in a dangerous states (european centered point of view still). Operational status gives the chance to detail the state of buildings, there are options such as 'needs_maintenance' or 'restricted' or 'defective'. I agree with you Dieterdreist that we can not say "this building is in bad shape" because this judgment could change from a person to an other (this is what condition key does actually, not a big fan of it) but we might find keys/tags that define that the building is in a bad state (like defective/needs_maintenance/etc) In the lifecycle option here in this page, once the building is existing there is options such as disused or abandonned (prior to ruined or others) but nothing in between, which is what I find is missing here. And @Dieterdreist I also think we could define generally speaking the state of the building and then detail it. Still with operational_status, it could be operational_status:wall etc... --Violaine Do (talk) 04:13, 20 July 2018 (UTC)

Lifecycle prefix rendering

Why aren't objects with this tags rendered on the OSM map? It could be really informative if they will rendered, escpecially ruined bridges, roads, railways etc. For example: I have tertirary highway with ruined bridge (yeap it is really tertirary highway). I want to tag it as demolished, but it must be rendered on the map because it is tertirary road! I think it can be rendered as dotted line or something else inconspicuous. --Otavva (talk) 08:54, 27 April 2019 (UTC)

Rendering in OSM Carto is discussed at https://github.com/gravitystorm/openstreetmap-carto/issues (please check whatever issue was already reported before creating a new one!) Mateusz Konieczny (talk) 09:25, 27 April 2019 (UTC)

For this specific case - how this tertiary road passes waterway? With a ford? Mateusz Konieczny (talk) 09:25, 27 April 2019 (UTC)

There is no way to go across this river. It placed in danger (military) territory, so this bridge will no repaired. But as I said this road is a part of the contry tertirary road network relation. Because of it I shouldn't delete this bridge so the abandoned lifeprefix is really good in this case. But it is not rendered. Thank you for your answer. And actually it is not demolished. It is destroyed. I have written misplaced words because I'm not a native English speaker. --Otavva (talk) 06:04, 29 April 2019 (UTC)

Can you link this specific road? I am pretty sure that dead end road is not highway=tertiary. Note that OSM road classification of roads is not obligated to follow official road classification. Mateusz Konieczny (talk) 07:05, 29 April 2019 (UTC)

The talking is here. --Otavva (talk) 13:25, 29 April 2019 (UTC)

Half built

Mention cases where a house has been halfway built (skeleton and all), but

• due to permit violations, death of owner, or unknown issues, construction has been halted, for years already now.

Jidanni (talk) 00:20, 8 October 2019 (UTC)

Combine stages of decay sections

Please don't have **two** stages of decay sections. It is already so confusing. Thanks. Jidanni (talk) 06:14, 8 October 2019 (UTC)

Damaged

Add a tagging method to say a place/thing is simply damaged, with no other opinions inferred. Jidanni (talk) 02:48, 6 February 2020 (UTC)

Razed

Razed, as in "completely removed", contradicts the Examples table which says "don't tag anything if no trace of it remains" --Shrddr (talk) 21:29, 14 May 2020 (UTC)

I attempted to improve it Mateusz Konieczny (talk) 23:26, 14 May 2020 (UTC)

"Place where railway existed in the past. It must not be tagged in any way, as no identifiable trace of it remains and is unlikely to be mistakenly mapped again."

This is correct in theory, this is the Practice (note the dynamics):

• https://taginfo.openstreetmap.org/keys/razed:railway#chronology (13 810)
• https://taginfo.openstreetmap.org/tags/railway=razed#chronology (31 309)

Most of the mapped razed railways i know are long disappeared, even from aerial images. Apparently there is a need for mapping this.

I'm not sure if the wiki should ignore the Practice. I do not want to discuss here if that's right or wrong, I suspect that topic is controversial. But if you should not mention the dispute rather than doing so if that did not exist? (sorry about my google-english) --Jo (talk) 00:18, 14 March 2021 (UTC)

"even from aerial images" what about visibility in terrain? In last bigger discussion on mailing list people claimed that railway=razed railways are mapped because of leaving identifiable traces. Can you give examples of ones where there are no traces whatsoever of any kind so I can delete them (after checking that with local mappers)? Mateusz Konieczny (talk) 07:51, 14 March 2021 (UTC)

Hiking routes

We are currently discussing the use of lifecycle prefixes for hiking routes. Our scenario is about a part of the route currently not passable because of a natural event such as a landslide, rockfall or fallen trees. There are 2 questions, the first whether we should split the relation if only a part is not usable, and the second about the tagging to apply. There is state=* which is explicitly defined for routes. Or we could use a lifecycle prefix on the route tag, such as disused:route=hiking or construction:route=hiking. These routes are not abandoned, but they are also not only "disused" because maintenance / construction work will be necessary to bring them back into a usable state. --Dieterdreist (talk) 11:24, 15 March 2021 (UTC)

Personally I see following as good ideas:

1. mark ways themself with access=no, possible also lifecycle prefix
2. Split relation into parts that is suspended and existing (marking all as disused is a bad idea, such closed section should be marked if it is a long term issue)
3. Use disused:route=hiking or construction:route=hiking (I am not fan of state=* type of things, attributes should not suddenly negate main tags - see trolltag. But if it has a wide acceptance...)

Mateusz Konieczny (talk) 11:41, 15 March 2021 (UTC)

I agree with your answers and would also advocate to prefer life cycle over "state", because it makes it easier if we do not invent a new system for every field of application, but rather follow a system that can cope with all situations following the same logics. Problem I see is that "construction:" isn't defined for maintenance or repair work, currently. Could it reappear in other sections (e.g. a new section maintenance), or should we introduce new keys/prefixes? --Dieterdreist (talk) 13:00, 15 March 2021 (UTC)

At least in Poland "construction" (typically highway=construction - but the same would apply to lifecycle prefixes) is routinely used for both brand new construction or reconstruction of existing one Mateusz Konieczny (talk) 13:02, 15 March 2021 (UTC)

I can confirm this for Germany and Italy as well, so I believe it is no problem to amend the page. --Dieterdreist (talk) 14:47, 15 March 2021 (UTC)

Difference between demolished:, removed: vs razed:?

Is there any difference between demloished:, removed: and razed:? I don't see any difference between:

• "features that have been demolished, without any traces left" (definition of demloished:),
• "features that do not exist anymore" (definition of removed:) and
• "features that have been completely removed" (definition of razed:).

--Dafadllyn (talk) 18:19, 16 April 2021 (UTC)

De facto there is no difference and may be treated as the same. If there is difference in how some mappers use it, I would not assume that it is shared by other mappers. Mateusz Konieczny (talk) 18:34, 16 April 2021 (UTC)

Thanks for your reply! I've edited the page to make it more clear. --Dafadllyn (talk) 21:18, 17 April 2021 (UTC)

@Mateusz Konieczny: I would disagree that it may be treated as the same – or it "may be", but it shouldn't in most cases. I think to say it like that is a bit too simple (or very very pragmatic). Because: why should there be no difference "de facto"? Perhaps sometimes there is no big difference, but sometimes there can be a clear difference. Why should these prefixes not be used according to their (perhaps primary!) lexical semantics? Perhaps not everybody has exactly the same meaning of these words in his mind, but I would not say that these words don't express a difference nor that they may be treated as the same. We have different word to express different meanings (they can be small, but perhaps important), otherwise we would not need them and have only one word. And of course, the usage of lifecycle prefixes can never be a 100% precise science, it should be seen as a range of possibilities where one of them may fit better than another – and sometimes it's perhaps not very clear which one fits best, perhaps because the context is not clear enough. And if it becomes clearer after some time, a prefix could also be changed ...

I see the greatest similarity between razed: and removed: (in the meaning of an "active removal"), but a greater difference to demolished: (a word which has two meanings I think – in its second meaning it can be a state which is hard to distinguish in reality with abandoned: I think – see my explanations below). I try to make a difference between these 3 prefixes and I use some examples to make it clearer … And I am not a native speaker of English, but I think I have a good understanding of the differences of these words because there are quite good analog words in German (my native language). But perhaps an English native speaker can make it even clearer or point out something that I am missing ...

• razed: A building or another object can be razed which means that is has been dismantled (e.g. with a digger) completely. „Razed to the ground“ is a good and typical expression I think. Nothing directly visible is left of the object. But there can be an empty space for some time where this building was standing before – therefore it can make sense to tag it with the prefix (perhaps a new building or something different will be built there soon and the outline can be used again!). Or a tree in a public area was razed – then not even a stump is left, only some earth where it stood before. Perhaps a new tree will be planted there later – in the meantime, it could be tagged with razed:natural=tree (if there is a stump, you could use natural=stump).
• removed: This is perhaps in the result (I think that is what you mean with "de facto") very similar to razed:. But I think it suits better for objects which can be moved away rather that it is necessary to destroy them first and then taking away the leftovers (but I know: "removing something" can ALSO mean this – but "razing" ALWAYS means one thing ...). Therefore I would use it if another process has taken place in comparison to razing something ... And some mappers perhaps also use it if an object has "moved" to another place, e.g. a restaurant which has a new address, but wasn't closed or shut down – it still exists somewhere else. But I am not sure if this is a good usage and if this meaning is also a second meaning of the word "remove". Perhaps something like "moved:" or "relocated:" would be more precise in these cases. But it fits if you have in mind that something which was removed CAN still exist as a hole, intact thing at another place – like this restaurant (but something which was removed could also have been destroyed or partially destroyed in the process of removing – but then "razed" often fits better, I think – if it was "razed to the ground" with nothing leftover somewhere – except on a waste deposit).
• demolished: I think this word has two meanings in English, as far as I understand it – it can mean to destroy/remove something completely (similar to razing something), but it can also mean that an object was damaged/smashed up heavily by brute force (e.g. by humans or a storm or something else). And in German we have the same word but use it only in the second meaning. And I think it would be reasonable to use the prefix also preferentially in this second meaning, because we have already the other 2 prefixes for the first meaning. Demolished in the meaning of "heavily damaged" means: it cannot be used in the meantime, but its state is not the desired (normal) one and with a certain (more high than low) degree of probability the object will be repaired again. In reality it can look similar, but it's not the same like abandoned: – then something was "actively" given up and with a very high degree of probability it will not be repaired, more likely it will be razed (or removed) in the future. Often, but not always you can differ it by human/visual judgment and if you know something about the context of this state.

At the end, it's perhaps not a very big problem if mappers use the prefixes in a slightly different (their personal?) way. But for people who have a good "Sprachgefühl" (a good feeling for words and language) and a clear judgement of a situation it may be quite clear which prefix suits the best. But I think it's a bad idea to write "razed: is a duplicate of removed:" oder use the phrase "possible duplicate" (duplicate for me means: no difference at all!). You could say "is similar to"/"has similarities with" or something like that. And at the end more (good!) examples of a larger range of objects could really be helpful – with a "best choice" recommendation in difficult cases – which could be discussed here. And for me it's very strange that the text for demolished: says: "Not existing anymore because of active removal" – the second meaning of "demolished" (which IMO could be the first for the usage as a prefix for OpenStreetMap) is missing completely. --Goodidea (talk) 01:05, 30 September 2021 (UTC)

was:*=* must be marked as deprecated

In my observation, all previous captures with was:*=* can be replaced by the relevant, more detailed descriptive lifecycle prefixes. The key was:*=* is 100% replaceable by more detailed keys. The key was:*=* is not needed!--streckenkundler (talk) 20:40, 23 Juli 2022 (UTC)

I disagree. How do you propose to tag an object that was simply converted from one thing to another? E.g. a shop that has been changed to a cafe? There's nothing disused, razed, abandoned... there. Mueschel (talk) 20:47, 23 July 2022 (UTC)

"There's nothing disused, razed, abandoned... there" then there is also no reason to map anything (and "mapper may map it from outdated imagery" does not really apply to shops) Mateusz Konieczny (talk) 06:41, 24 July 2022 (UTC)

I disagree, too. I find it useful/elegant e.g. to tag the main key of an object with one of the "main" lifecycle prefixes like disused:/razed:/removed:/... and other, less important (sub) keys with "was:" instead of deleting them or given them the same prefix as the main key (in certain cases! not always!) ... This improves readability for human mappers or users and makes it easy for other mappers in the future to re-activate the keys if an object returns to a "normal" state. For example: a tree has been felled and was tagged with natural=tree, leaf_type=broadleaved, leaf_cyle=deciduous, genus=acer, then you could perhaps tag it as razed:natural=tree, was:leaf_type=broadleaved, was:leaf_cylce=deciduous, was:genus=acer. If a new tree is planted some time later in the same place (this happens more often in inner cities), you can quickly reset all tags and no one will be forgotten because another mapper may not have looked at the history exactly. Perhaps this isn't the usual way of using the prefix and will meet with some objection, but I like it that way in certain cases and don't see any serious reason not to. Goodidea (talk) 15:45, 25 July 2022 (UTC)

Although it should be used quite sparingly, I too think there are valid uses. It might be used when old thing is replaced by new one (and other lifecycle tags do not apply), but the old one is still quite relevant/important. e.g. random example way 88363245 is tourism=museum nowdays, but it was notable amenity=townhall at the time (and it might be preserved as such or not, depending on specific case), or way 165028956 which is amenity=cafe now, but it is popular now as in times past it was:military=checkpoint. --mnalis (talk) 10:16, 14 February 2023 (UTC)

Flawed with prefixes construction, disused, abandoned

As the page states "By using this key prefix it is ensured that current or legacy applications are not confused by objects which do not exist or are not fully functional and only software aware of this tagging concept will evaluate those." According the definitions here for each stage, the problem is that features in:

• "proposed" whaterver its tagging scheme, as nothing proves that it will ever be built, contributors should not record such features in OSM as stated in the rules and it constitutes a waste of server resources. I've seen several proposed features staying for years and never ever built, so imagine the amount of data worldwide.
• "planned" as prefix it is OK, but a clear source=* should be provided.
• "construction" can be already considered as such and identifiable on terrain.
• "disused" and "abandoned" can still be considered as such since they can be restored. I've seen contributors putting tracks as abandoned instead of degrading them with the key tracktype=* just because of higher grasses grown the track whereas there is still erosion.
• "ruins" as prefix this is OK, not anymore as the value of a key, like a pile of bricks and beams can't be considered as a building. The feature is clearly transformed and maybe could still be tagged for other interests such as historic=ruins, the walls of a building on an archaeological site, etc
• the other prefixes can serve as archive to avoid recording back in OSM's database because of misinformation, as the page says "No longer existing objects may be marked as existing in other sources".
  

Other examples... It can happen that an unclassified road becomes a track grade1 or grade2, I've seen this in former quarries, disused for the original purpose but still used for leisure activities. There are some ancient buildings preserved but disused or abandoned, some still have an interest, other can serve as points of reference for orientation.
Therefore this tagging scheme enters in conflict with the established ones. For features that can be recognized as such, we should encourage the use of established keys with its specific values to ensure the faithful representation of reality and rather use the lifecycle prefix only when the feature can't yet or anymore be considered as such. Using this flawed tag scheme clearly introduces conflicts of tagging between contributors as the page Comparison of life cycle concepts explains the advantages/disadvantages of each.
--SHARCRASH (talk) 11:31, 7 September 2022 (UTC)