Proposal:Status
| status | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | Tordanik |
| Tagging: | life_cycle=disused / construction / in_use |
| Applies to: | all |
| Definition: | defines operating state of the tagged object, depending on the value |
| Statistics: |
|
| Rendered as: | depends on object the tag is added to, see also #Values |
| Draft started: | |
| Proposed on: | 2008-07-17 |
| RFC start: | 2008-07-20 |
| Vote start: | 2008-09-28 |
| Vote end: | 2008-10-12 |
The value of life_cycle determines the tagged object’s state of operation, i.e. the object’s position in its life cycle.
Rationale
Features under construction and disused objects in various states of decay are common and usually mapworthy – while they cannot be used for their intended/original purpose, they still serve as visible landmarks or may be of historical interest. It is common for maps to include this type of information.
Current OSM tagging
There are already solutions for a small subset of OSM’s map features, especially railways (railway=disused, railway=abandoned, railway=preserved) and highways (highway=construction). These have in common that they replace the information about the type of railway/highway with the status information. (highway suggests to use another tag to keep that data, e.g. highway=construction with construction=motorway).
Another tag used to express state information is disused=yes. There is a proposal to introduce a similar tag for abandoned features. These, however, require client software to be aware of all of them to avoid severe misinformation.
Other proposals related to this topic include a suggestion for mapping abandoned military bases.
Until now, to sum up, there is no complete set of status information that can be used on all features equally.
Also see Comparison of life cycle concepts for a discussion of the different ideas.
Aim of the proposal
The “status” proposal is intended to create a future-proof as well as easily understandable and usable solution for this problem: Unlike existing solutions, it is not limited to a specific mapping domain. and can be extended with more values if desired. Changing the life cycle status does not necessarily affect the feature’s other tags.
Values
| Key | Value | Element | Comment | Rendering |
|---|---|---|---|---|
| life_cycle | in_use |   
|
A feature that is in normal use. This is the default. | normal rendering |
| life_cycle | construction |
|
A feature under construction. | some semi-transparent, dashed or dotted version of the normal rendering at the renderer’s discretion. |
| life_cycle | disused |
|
A feature which is no longer used but where infrastructure remains in place. | some semi-transparent, dashed or dotted version of the normal rendering at the renderer’s discretion. |
Other values have been proposed or are already in use with other concepts, such as planned, abandoned and preserved. These can easily be added to the life_cycle key, but will get their own proposals so they can be discussed individually.
Examples
motorway under construction:
highway=motorway
+ life_cycle=construction
nuclear power plant under construction:
power=generator
+ power_source=nuclear
+ life_cycle=construction
Implications and recommendation for tagging
Any life_cycle other than in_use implies that the general public cannot use the feature.
However, it might cause problems (especially when life_cycle is used on highways) if routing and rendering applications that are unaware of the existence of the life_cycle key consider it a usable feature. It is therefore recommended to explicitly state the usage restriction (e.g. using access=no or other appropriate access tags) . This is recommended until all major applications support life_cycle=* directly.
See also
Discussion
Please use the talk page.
Voting
Please indicate below whether you approve or disapprove this proposal. If you agree with the general concept, but would like a different key name better, add an appropriate comment to your vote. Please do not discuss in the voting section, use the talk page instead. Remember to take into account the arguments brought up in discussions before casting your vote.
I approve this proposal. --Tordanik 21:52, 28 September 2008 (UTC)- I approve this proposal. This should have been here from the begging. It may cause problems now due to backwards compatibility, but I think it's worth the trouble --Jttt 22:06, 28 September 2008 (UTC)
- I approve this proposal. --Chris66 08:30, 29 September 2008 (UTC)
I oppose this proposal. See Talk:Proposed features/Construction for reasons why this is a bad idea. Chriscf 08:46, 29 September 2008 (UTC)- I oppose this proposal. Not backwards compatible... bad idea. ditto Chriscf -- Randomjunk 10:06, 29 September 2008 (UTC)
- I oppose this proposal. for any road features. A road under construction is not a primary highway (or whatever) until it is in use so it should not be a highway=primary. For other objects, don't care. Alv 13:25, 1 October 2008 (UTC)
- I approve this proposal. --Vrabcak 13:35, 29 September 2008 (UTC)
- I oppose this proposal. This would cause the renderer to look for two tags instead for one - this is double work. I oppose for performance reasons. --Lulu-Ann 14:57, 29 September 2008 (UTC)
- I approve this proposal. --Josias 15:08, 29 September 2008 (UTC)
- I oppose this proposal. -- Gustavf 15:57, 29 September 2008 (UTC)
- I approve this proposal. xylome 23:26, 29 September 2008 (UTC)
- I approve this proposal. Renders still need to check additional tags for access, and this enables a wider range of usage information than merely whether it is accessible or not JanneM 12:05, 30 September 2008 (UTC)
- I approve this proposal. As Jttt notes, this technique is scalable and easily converted to by scripts, so checking of multiple tags would not be an issue, or at least not for very long. Its activation could even be delayed until the only such current tag is eliminated completely. Circeus 00:15, 30 September 2008 (UTC)
- I approve this proposal. This tag with its reduced set of values should have been there from the start. SvenR 12:33, 30 September 2008 (UTC)
- I oppose this proposal. "not efficient, not scalable, and (most importantly) not backwards-compatible" (as Chriscf said in deleted comment).It seems silly to break stuff to me -- Basemonkey 13:09, 1 October 2008 (UTC)
- I oppose this proposal. Nibblenibble 13:37, 1 October 2008 (UTC)
- I approve this proposal. --Zottel 14:45, 1 October 2008 (UTC)
- I oppose this proposal. Pieren 15:01, 1 October 2008 (UTC)
- I oppose this proposal. Bobkare 15:06, 1 October 2008 (UTC)
- I oppose this proposal. --Cartinus 23:26, 1 October 2008 (UTC)
- I oppose this proposal. This is going to make anything that currently uses osm data to be updated, therefore it is not backwards compatible. Smsm1 10:18, 2 October 2008 (UTC)
- I oppose this proposal. - It's a much bigger issue to render something as a road or as a motorway when it no longer/does not yet exist - than, say, doing the same with a road with access restrictions. If a highway=construction, construction=* tag is parsed by an render without support for that - then it won't show up - big deal as it doesn't yet exist as a road open to traffic. If a highway=disused etc. is put through a renderer without support for that, then it won't show up - no loss there - as it no longer exists. If a highway=*, status=disused etc. is parsed by a renderer without that support - then it shows up as a normal road - even if nothing is there on the ground. That for me is a big issue. A road with "access=private" can at least by used by the landowners. Richard B 11:31, 2 October 2008 (UTC)
- I approve this proposal. Lucadelu 0:29, 5 OCTOBER 2008 (utc)
- I oppose this proposal. Not a good way to solve the issue, not backwards compatible - prone to older programs that use OSM data rendering abandoned/unfinished things as if they are fully operational, thus confusing the users Bilbo 15:01, 6 October 2008 (UTC)
- I approve this proposal. abunai 12:53, 7 October 2008 (UTC)
- I approve this proposal. Bomm 16:07, 7 October 2008 (UTC)
- I oppose this proposal. Garry 01:25, 9 October 2008 (UTC)"No" for this name! A correct form could be "operating_state" but never "life cycle"!
- I oppose this proposal. Matt 16:22, 10 October 2008 (UTC) This looks like change for change's sake - its only improvement over existing tagging is that an update affects one, not two, tags. Also, "life_cycle" is an awful name.
- I approve this proposal. Alexrudd 16:51, 10 October 2008 (UTC) Objections seem to be based on the fact that existing applications will have problems if they don't implement current tags. The problem with this logic is that applications are already in trouble if they don't know about some tags. (abandoned = yes, access=no, etc.) This is a much cleaner and unified solution.
- I approve this proposal.--Walley 11:14, 11 October 2008 (UTC)
Votes cast after 2008-10-12
Voting results
With 15 approving and 15 opposing votes, the proposed life_cycle tag failed to achieve majority approval and has therefore been rejected.
- We have a little problem here. Look at votes from Basemonkey and Nibblenibble. Their votes are highly suspicious. For both of them this was the only one contribution, the users were created in one day in short succession, they're no users with the same name at openstreetmap.org. I really think that they're fake users created by somebody who really didn't like the proposal. --Jttt 05:18, 13 October 2008 (UTC)
- Even if they were (on which I'm not guessing), 15 to 13 is not a majority. Alv 05:23, 13 October 2008 (UTC)
- Unless my maths is letting me down, 15 to 13 is a majority, but that still represents significant opopsition among those that voted. Chriscf 08:48, 13 October 2008 (UTC)
- Today I learned that the word majority doesn't mean a two-thirds majority or even a three-fifths majority, which seemed more appropriate for (major) changes. The voting should be secondary to finding the best and unified way to tag any features for which a adequately apparent way is not known. Alv 10:37, 3 November 2008 (UTC)
- Agreed, which is why I'm reluctant to suggest that a simple majority would be enough for a potentially breakage-inducing change such as this. It goes without saying that there needs to be consensus, and I think that we're in somewhat violent agreement in saying that such a small margin doesn't reflect this. Chriscf 14:21, 3 November 2008 (UTC)
- Today I learned that the word majority doesn't mean a two-thirds majority or even a three-fifths majority, which seemed more appropriate for (major) changes. The voting should be secondary to finding the best and unified way to tag any features for which a adequately apparent way is not known. Alv 10:37, 3 November 2008 (UTC)
- Unless my maths is letting me down, 15 to 13 is a majority, but that still represents significant opopsition among those that voted. Chriscf 08:48, 13 October 2008 (UTC)
- OMG Wiki Voting Flawed in unverifiable votes shocker... and as said, 15 to 13 is a definite non-starter anyway when most no votes were because it breaks stuff. You need a consensus to do such things, and it was obvious before the vote that one did not exist. ---- Randomjunk 14:52, 13 October 2008 (UTC)
- Even if they were (on which I'm not guessing), 15 to 13 is not a majority. Alv 05:23, 13 October 2008 (UTC)