Talk:Lifecycle prefix

From OpenStreetMap Wiki
Jump to: navigation, search


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)


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)

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 (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)