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.

<status> = yes

see: disused=yes, Proposed features/Abandoned, similar approaches include construction=yes

Advantages:

• all other tags can be added as usual

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
• potential name conflicts: new <status> keys must not have the same name as any other existing key to be universally applicable

life_cycle = <status>

see: Proposed_Features/Status

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:

• applications that do not even know life_cycle=* will still be irritated just as with <status>=yes

<key> = <status> + <status> = <value>

see: railway=disused, railway=abandoned, railway=preserved, highway=construction

Advantages:

• will not irritate applications

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

life_cycle relation

see: Proposed_Features/Life_cycle_relation

Advantages:

• will not irritate 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