User:Lightsider/Sandbox1

From OpenStreetMap Wiki
Jump to navigation Jump to search
  • Taginfo
  • Render support
  • Mechanics advantages/disadvantages
  • Should always map what's on the ground first. Tagging former uses (or, even worse, objects which no longer exist) is fairly controversial in the OSM community, as OSM exists to map the world as it is now.
  • A tagging scheme should "fail gracefully" if a render doesn't support all keys/values (also: what harm could come from a tag being misinterpreted?)
  • Ease of tagging
  • Basic schemes and advanced schemes?
  • Don't mix up tagging the current status of an object, and tagging what it was/will be. The former should have priority.
  • <key> = <status>
  • related keys: former, historic, disused, abandoned, demolished, ruins, ruined, removed, operational_status
  • related proposals (both passed and rejected)
  • state of documentation
  • state of rendering
  • construction=yes is a different tagging scheme!
  • Will not deal with date-specific tagging (tagging the properties of an object in the past or future). The difference is that we tag based on what we know now (and, particularly, don't concern ourselves with dates).
    • Nonetheless, discuss the overlap between the two approaches, and see if they can be compatible.
  • General disadvantage of non-date-tagging: users of outdated data may see incorrect features
    • This is different from the usual problem of OSM users, which is "no data"
    • Although OSM has many other errors...

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. Its aim is to collect information about them, with the aim to reach a consensus about how life-cycles should be tagged. Some methods are common, others are less widely used.

The discussion around life-cycle tagging is separate from (but, in some cases, related to) the discussion around date tagging. Therefore, some tagging schemes dealing primarily with dates (such as date namespace, start_date=*, or opening_date=*) will only be considered for interoperability with the proposals, but not as solutions in and of themselves.

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

Example

Current use

This scheme is fairly well established for roads and railways.

Roads

highway=construction and highway=proposed are fairly widely used. highway=abandoned sees some use, while other lifecycle-related values for highway=* (e.g. disused, unbuilt, planned, razed, dismantled) are only used very rarely (less than 300 uses each). The main highway page on the Wiki recommends that highway=construction and highway=proposed be used.

highway=construction highway=proposed highway=abandoned

The corresponding construction=* and proposed=* tags are well-matched:

Railways

railway=abandoned, railway=disused, and railway=construction are widely used, and are all well-documented on the Wiki.

railway=abandoned railway=disused railway=construction

There is no clear correspondence with the respective abandoned=*, disused=*, and construction=* tags:

Land use

landuse=construction is a fairly common tag; however land use tagging works differently and will not be considered here.

Conclusions

Advantages

  • Fairly well established and documented for highway=* and railway=*
  • Reasonably simple to use

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
    • <value> values are not unique amongst features (for instance, construction=residential (about 15,000 objects in the database) could refer to a residential road or a residential building)
  • Differing and inconsistent conventions for highways and railroads.
  • Cannot be easily extended to other types of features
  • 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>)

Main page: Lifecycle prefix

The lifecycle/status namespace prefix can be used to tag objects with a status such as "proposed", "planned", "construction", "disused", "abandoned", "demolished", or "historic". The idea is to ensure that applications which are unaware of this tagging scheme ignore features which are anything other than "operating normally" (in which case they would have no prefix).

See also date namespace for a related proposal to include dates for historic tags, for example amenity:1932-1974=school (to tag a building which was a school between 1932 and 1974). The two tagging schemes can be combined.

Examples

Current use

Prefixes like proposed:, disused:, and abandoned: are moderately commonly used, with about 20,000 tagged objects each. For details of other prefixes, see see lifecycle prefix.

Conclusions

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 or future 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).

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

It should be considered that this would be most likely be rejected if ever voted because of same concerns as life_cycle=status.

For example: amenity=pub + disused=yes
Also: abandoned=*, vacant=*, demolished=*, construction=yes, empty=yes, ruins=yes

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 interpret the tagging then the feature will be treated as being in operation. 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?)

See also

[[Category:Tagging_guidelines]] [[Category:History]] [[Category:Lifecycle]]

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:Lightsider/Sandbox1&oldid=1307230"