Comparison of life cycle concepts

This page provides an overview of various methods used to tag the life-cycle of features from proposal and construction, through operation, disuse, abandonment and eventual destruction. Some methods are common, others are less widely used or discouraged. Some methods are strongly discouraged for the main OSM project but accepted and in widespread use in the separate Open Historical Map project.

Note that page welcoming to OSM contains "What it doesn't include is opinionated data like ratings, historical or hypothetical features, and data from copyrighted sources."

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

For example highway=construction + construction=motorway

This scheme is established for highways and some people apply it to buildings as well. It is not easily extended to other domains and should not be used in places other than defined in the wiki as it may confuse data consumers when applied to tags or tag combinations where it is not expected.

Advantages:

• Well established for highway=*

Disadvantages:

• Cannot handle features with more than one “major” key (e.g. building=church + amenity=place_of_worship)
• Potential name conflicts: new <status> keys must not have the same name as any other existing key or value to be universally applicable
• Tag namespace is poluted by many keys (such as "construction")
• Differing and inconsistent conventions for highways and railroads.
• Applications will be confused when they do not expect the use of this tagging concept for a particular tag. For example a map displaying a generic all purpose icon for any shop=<whatever> would display this icon even for shop=abandoned.

Lifecycle prefix (<status>:<key> = <value>)

The lifecycle/status namespace prefix can be used to tag objects with a status such as proposed, planned, construction, disused, abandoned, demolished, historic

For example: disused:amenity=pub

Also: construction:amenity=parking, proposed:lanes=2, abandoned:railway=narrow_gauge

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.

See also date namespace for a related proposal to include dates for historic tags, for example name:-1965=Kings Place. The two possibilities can be combined.

See lifecycle prefix for more details.

Also

highway=secondary

name=Blar road

ref=B123

lanes=2

lit=no

proposed:highway=motorway

proposed:ref=M99

proposed:name=<null> (a secondary decision is to agree how to tag a key which no longer has a value)

proposed:oneway=true

proposed:lanes=3

proposed:lit=yes

historic:railway=rail

historic:name=Blar to blar railway

Advantages:

• All currently applicable tags can be added as usual.
• Will not confuse existing applications.
• Easy for software to strip of these prefix to create a OSM model with the historic or proposed feature included.
• Lifecycle information can be added to any key in a consistent fashion.
• Retains full information about the former use (unlike railway=abandoned for instance, where the former tagging for railway is lost).
• Offers the possibility to rationalise other historic-related tags, for example old_name=*, railway=station_site etc.

Disadvantages:

• Mappers will need to update many keys (although this does result in more detail in the model).
• Mappers will need to decide whether each individual tag is still applicable or not (although this may be an advantage).

Railways

Rail tracks are traditionally marked disused etc with

railway=disused, railway=abandoned, railway=preserved, and similar.

This method has been established for the rail tracks only, not for other railway related infrastructure such as railway=station. For railway stations use a lifecycle prefix such as abandoned:railway=station

Another problem of this method is that it is not possible to map more detailed information about the disused tracks. Although the same solution like for highways can be used (eg railway=disused+disused=narrow_gauge) this isn't universally accepted. Another possible solution is to use a combination with a lifecycle prefix such as railway=disused + disused:railway=narrow_gauge.

Date namespace suffix as "keyname:DATESPEC=.."

The date namespace can be added to any tag to indicate a period of validity for the tag.

• key:date-date = value
• key:date--date = value
• key:date- = value
• key:-date = value

This tagging is most useful to describe the history of a feature rather than its current status. Can be also combined with "status:key..." lifecycle prefix style mapping mentioned above.

The ISO 8601 standard suggests using a slash ("/") for separating dates in simple date ranges (and backwards compatibility), but a single hyphen ("-") should be used in OSM, as there's no risk of confusion if both dates are in the recommended ISO 8601 format (always starting with a year and with every date components left-padded with zeroes to a fixed number of digits, i.e. in forms: YYYY-MM-DD or YYYY-MM or YYYY).

An older version of ISO 8601 used the double hyphen ("--") to replace omitted years in partial dates; some users have used "--" instead as an alternate separator for date ranges (but it is only useful for yearly or monthly recurrent date ranges that specify dates omitting years, i.e. in non-ISO 8601 formats: MM-DD or DD).

Examples

• To map a school that became disused and was then converted into a house with the complete history

 building = house
 building:1971-12-18- = house       (or alternatively, building:1971-12-18-- = house)
 amenity:1835-1965 = school
 amenity:1965-1971-12-18 = school   (or alternatively, amenity:1965--1971-12-18 = school)
 name = The Old School
 name:1835-1965 = St Cakes Primary School
 name:1971-12-18- = The Old School  (or alternatively, name:1971-12-18-- = The Old School)

• A highway with a long history, changes in name, classification, reference and surface etc

 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

• A highway that's planned to change the oneway direction in two months (say the current date is 2015-03-01)

 highway = residential
 oneway = yes
 oneway:2015-03-01- = -1

• A highway that's planned to be under construction between 2015-06-01 and 2015-10-01, but which will be restored (more or less) to its original state (Note that two schemas are combined here)

 highway = residential
 highway:2015-06-01--2015-10-01 = construction
 construction = residential

(Dis)advantages

Advantages:

• Will not confuse existing applications.
• Allows complete history record with per-tag distinctions.
• Can be combined with other tags.
• Can be combined with "status:tag" style life cycle tagging.
• Supports adding historical/future information to currently used features if desired.
• Can be used to tag roadworks or planned features without using the complicated access conditionals and without harming slightly outdated maps.

Disadvantages:

• Difficult to search for objects by year (range) or objects using this tagging scheme.
• Duplication when current and past use overlap (eg building:1930-=house + building=house ought to be used).
• Datespec needs to be added to most tags separately where it applies to several tags. This does increase flexibility but also means some data duplication and more work when editing.
• For a single object with various tags affixed with dateranges it is difficult to ascertain whether equal dateranges refer to exactly identical periods of time or just happen to be identical strings which might have been slightly differing time periods in reality but resulted in identical daterange strings because of lack of precision or missing exact dates.
• This type of mapping might result into mapping historical data that's not locally verifiable anymore, this shouldn't be in OSM.
• Date suffix (calling it "a namespace" is incorrect) doesn't have a qualifier (common string, usable for simple pattern matching), so there is no way to select all tags with date suffix using a simple query. Complex regular expressions must me used.
• Storing a date range together with a key (not with a value of tag) could likely require applications, based on OSM data, to be redesigned, because date range is a value itself and it doesn't match the common way of parsing tags.
• It is impossible to directly query date ranges (for example, to select all names effective for a specific year or a specific period of time.

Opening_hours time range and Temporary namespace and Conditional restrictions

Opening hours

The opening_hours format also allows to specify time ranges:

• Simple, weekly repeating time range: Mo-Fr 08:00-17:30
• Non-repeating time ranges: 2015 - 2025, 2015 May 01 08:00 - 2025 Jun 30 16:00

Conditional Restrictions

From the Wiki Page Conditional Restrictions:

Simple unconditional restriction tags such as access=private or maxspeed=60 are widely used to tag basic restrictions like a 60 kph speed limit. (…) In some cases, restrictions are only valid when certain conditions are fulfilled. An example may be a different speed limit of 60 kph applicable between 06:00 and 20:00. According to the present scheme, this example may be tagged as maxspeed:conditional=60 @ (06:00-20:00).

Temporary Namespace

The opening hours format is adopted in the proposed temporary namespace:

 temporary:key = value @ (time-range) [; additional-value @ (additional-time-range)]

Examples

• Reduced speed limit due to construction work

 highway=primary
 maxspeed=80
 temporary:maxspeed=50 @ (2015 Dec 01 - 2015 Dec 15)

• Road closed due to demonstration

 highway=tertiary
 temporary:access=no @ (2016 May 01 08:00-14:00)
 temporary:foot=yes @ (2016 May 01 08:00-14:00)

Note that, unlike in the above example, the temporary modification introduces a new tag rather than overwriting an existing one (as the road here does not have a regular access tag).

• Temporary name for an exhibition pavilion

 building=yes
 name=Pavilion 5
 temporary:name=Security Area @ (2015 Oct 25 - 2015 Oct 30)

start_date and opening_date

start_date=* is intended to be used to indicate when an existing and functional feature was completed. Dates in future must be avoided. Originally end_date=* was also envisioned but is discouraged as it is likely to cause backward compatibility problems.

opening_date=* is intended on features which will open in future, those must be additionally tagged so that confusion with real-existing features can not happen - for example with the "construction:" namespace prefix.

Advantages:

• simple tagging of complex objects
• easy to interpret data

Disadvantages:

• very easy to break existing applications if not done very carefully
• no way to apply to different tags of an object separately
• no way to specify more complex history of objects

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

life_cycle = <status> (REJECTED)

Main article: Proposed_Features/Status

For example: amenity=pub, life_cycle=construction

Also: life_cycle=disused, life_cycle=proposed

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:

• rejected
• 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

<status> = yes

For example: building=church + disused=yes - a disused church building, but the building is still in good condition

or man_made=adit + abandoned=yes - an abandoned adit (horizontal mine entrance)

Similar: vacant=*, demolished=*, construction=yes, empty=yes, ruins=yes

Advantages:

• disused=yes and abandoned=yes are well established for use with man-made physical features like buildings or objects which are visible in the landscape, whether or not they are disused or functional.
• All other tags can be added as usual to describe the current properties of the object.

Disadvantages:

• If an application does not interpret the tagging then the feature will be treated as being in operation. Therefore these tags should not be used for features such as those found in amenity=*, shop=* or leisure=*, which are no longer of interest to a general map user when they are not functional.
• This flaw can be addressed by 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 here in more detail (Lifecycle prefixes).
• The tag demolished=* always implies that the feature no longer exists, so it should not be tagged in this way. demolished: as a namespace would be preferred, but only temporarily if the object is still visible in aerial imagery for example

What can be tagged in OSM

While it is accepted that features that no longer exists may not be tagged in OSM there are differences in what is considered "no longer exists".

There are some clear case - for example mapping historic borders of Roman Empire has no places in OSM, there are more complicated situations with railways as a good example. To quote

Where do you draw the line between "there" and "not there" for a former railroad?

1. A railroad, still with tracks, with grass growing between the rails. You can't tell if it's been used recently or not.
2. A railroad, still with tracks, that's been overgrown by brush and small trees. It clearly hasn't been used in the past few years.
3. A gravel railbed with occasional maintenance debris (discarded spikes, cracked signal footings, rotted ties).
4. A railroad right-of-way that has had the ballast removed and replaced by asphalt, turning it into a bicycle route.
5. A cutting through a rock outcropping leading to a collapsed tunnel. Any residual ballast has been buried by wind-blown dirt and overgrown by trees.
6. A curved line stretching two miles through a city without a single building crossing it.
7. A railroad whose only remnant is a line on a topographic map dating from 1901.

See also

• Lifecycle_prefix - The lifecycle/status namespace prefix can be used to tag objects with a status such as proposed, planned, construction, disused, abandoned, demolished, historic.
• abandoned=* - A man-made feature abandoned and no longer maintained.
• disused=* - Specifies if feature is disused but in a reasonable state of repair.
• demolished=* - Namespace for features that have been demolished, without any traces left.
• Proposed_features/Tag:operational_status
• Taginfo for removed:
• Multilingual names
• Open Historical Map
• OSM-4D#Time
• start_date=*
• not approved and discouraged - end_date=*
• rejected Proposed features/Status
• abandoned Proposed features/Construction
• temporary=*