Comparison of life cycle concepts
There are several approaches to map features under construction and disused features, some more, others less widely used. Most of these are only ideas or proposals and are not rendered by any application. This page tries to list them all together with their pros and cons to facilitate a decision on the issue.
The list intentionally tries to not include subjective arguments such as “intuitive” usability. It also ignores current renderer support.
Contents |
<status> = yes
see: disused=yes, Proposed features/Abandoned, Proposed features/vacant, Key:Demolished. Similar approaches include construction=yes
Proposal status: The 'Abandoned' proposed feature is now considered to be 'Abandoned' and did not reach conclusion. A tag-documentation page has been added for it nonetheless. The 'vacant' proposed feature remains considered as a 'Draft', but has not had input since mid-2010. 'Disused' is in widespread use, but consensus is that in it original form the tag was badly-considered and caused sets of tags on an object to be inconsistent (i.e. internally contradictory). Users have used namespaces as workarounds for this inconsistency for some time. As of 2011-06-05, User:Achadwick has codified the approach some people use in the hope of rehabilitating disused=* and abandoned=*.
Advantages:
- Established... badly, and to varying degrees of usefulness.
- All other tags can be added as usual to describe the current properties of the object.
Disadvantages:
- If an application does not know the tag, it will assume that the feature is usable and might display it as such or use it for routing. This flaw can be addressed my making the no-longer-relevant tags unavailable to applications which use them through a simple rename of their keys: the aforementioned namespace-based renaming approach is described below in more detail.
- Potential name conflicts: new <status> keys must not have the same name as any other existing key to be universally applicable (fairly minor problem, surely?)
life_cycle = <status>
- Main article: Proposed_Features/Status
Proposal status: Voting has concluded and the Proposed Feature was rejected based on a 15-15 yea/nay vote total.
Advantages:
- All other tags can be added as usual
- Once an application knows life_cycle=*, new values invented in the future will not cause trouble
- Occupies only life_cycle as a key name, new <status> values can be added without the risk of name conflicts
Disadvantages:
- If an application does not know the tag, it will assume that the feature is useable and might display it as such or use it for routing
<key> = <status> + <status> = <value>
see: railway=disused, railway=abandoned, railway=preserved, highway=construction
Advantages:
- Will not confuse applications (unless they use a highway=* catch-all solution)
Disadvantages:
- Cannot handle features with more than one “major” key (e.g. building=church + amenity=place_of_worship).
- More potential name conflicts than <status>=yes: new <status> keys must not have the same name as any other existing key or value to be universally applicable
<status>:<key> = <value>
This syntax is now documented on Key:disused and produces tags such as disused:amenity=pub. Examples for previously discussed syntactic variants include amenity-disused=pub and was:highway=tertiary.
Tags which are no longer relevant to the current state of the object are renamed so that they don't cause accidental use by programs which might otherwise mistakenly use them. Ideally they're 'namespaced out' all together, meaning that interdependencies between tags are preserved in a restoreable - and, to some extent, machine readable - format.
Advantages:
- All currently applicable tags can be added as usual.
- Will not confuse existing applications.
- Available for all existing keys in a consistent fashion.
- This sort of key renaming permits recording of the state before the point of disuse, abandonment or whatever. If the object reverts to its old state in reality, it's a simple matter to undo the renaming.
Disadvantages:
- Features with more than one key which has become no longer relevant or potentially confusing will need to adjust all such keys.
- Increased cognitive load on the mapper. Mappers must decide whether each individual tag is still applicable or not, and also consider when other, more established schemes such as old_name=* have priority.
- Difficult to handle more concepts than just lifecycle.
life_cycle relation
- Main article: Proposed_Features/Life_cycle_relation
Proposal status: The proposal is still in 'Draft' phase, but has not had input since mid-2009 and should practically be considered 'Abandoned'.
Advantages:
- Will not confuse applications if used correctly
- All other tags can be added to the relation as they would have been added to a feature in use
- Occupies only life_cycle as a relation type and some key names prefixed with life_cycle, new <status> values can be added without the risk of name conflicts
- Supports adding historical/future information to currently used features if desired
Disadvantages:
- Requires use of relations
- Might cause mappers to erroneously ad tags to the apparently “untagged” way
Related concepts
<tag> : <year> - <year>
see: Multilingual names
(This proposal has a different purpose from the others on this page. It cannot describe the current status of a feature at all. Instead, it describes the history of a feature.)
- amenity = school
- amenity:1944-1945 = hospital
- highway = pedestrian
- highway:1974- = pedestrian
- highway:1932-1974 =primary
- maxspeed = 30
- maxspeed:1957-1992 = 50
- name:1871-1933 = Kaiserstraße
- name:1933-1945 = Adolf-Hitler-Straße
- name:1945-1953 = Stalinstraße
- name:1953-1990 = Ernst-Thälmann-Straße
- name:1990- = Konrad-Adenauer-Straße
- ref:1932-1960 = R 96
- ref:1960-1990 = F 96
- ref:1990- = B 96
- surface = paved
- surface:1890-1927 = cobblestone
- surface:1927- = paved
Note: Only a small number of buildings and roads have such a long history
