RU:Жизненный цикл объектов
Вы можете закончить перевод.
Если вы знаете английский, то можете помочь нам, переведя часть оригинальной статьи. Общие сведения о переводе статей на русский язык можно найти здесь.
На этой странице собраны способы тегировния жизненного цикла объектов, от предложения и строительства, периода действия, до заброшенного состояния и разрушения. Некоторые из приведенных методов повсеместны, другие менее популярны. Когда-нибудь один из этих методов будет рекомендованным.
<status> = yes
- Established... badly, and to varying degrees of usefulness.
- All other tags can be added as usual to describe the current properties of the object.
- 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?)
<key> = <status> + <status> = <value>
- Will not confuse applications (unless they use a highway=* catch-all solution)
- Well established for highway=* and railway=*
- 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>
- For example: disused:amenity=pub
- Also: construction:amenity=parking, proposed:lanes=2, abandoned:railway=narrow_gauge
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.
This syntax is now documented on Key:disused and produces tags such as disused:amenity=pub. Other proposed tagging syntax formats for this approach include amenity-disused=pub, railway:historic=station etc. See below for a related proposal to include dates for historic tags, for example name:-1965:name=Kings Place. In this example 'historic' has been replaced by a date range and the order of the key elements has been reversed.
- Proposed prefix values
- proposed: (planned, with a high likelihood of being constructed)
- construction: (being constructed at this time)
- disused: (not current available for use, but could be reinstated easily)
- historic: (a previously valid characteristic)
- ruined: (the prefix ruined=* is a recent addition attempting to replace ruins=*)
- A1 (Leeming Bar and Barton)
- A30 Temple to High Carblake
- A11 Fiveways to Thetford Improvement
- SEMMMs in Manchester
- name=Blar road
- proposed:name=<null> (a secondary decision is to agree how to tag a key which no longer has a value)
- historic:name=Blar to blar railway
- 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.
- 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 = <status>
Основная статья: Proposed_Features/Status
- 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
- 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
Основная статья: 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'.
- 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
- Requires use of relations
- Might cause mappers to erroneously ad tags to the apparently “untagged” way
- <tag> : <year> - <year>
This tagging is used to describe the history of a feature rather than its current status.
- A school that became disused and was then converted into a house
- building = house
- building:1971- = house
- amenity:1835-1965 = school
- disused:amenity:1965-1971 = school
- name = The Old School
- name:1835-1965 = St Cakes Primary School
- name:1971- = The Old School
- A highway with a long history, changes in name, classification, reference and surfac 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