Talk:Comparison of life cycle concepts

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Comparison of life cycle concepts here

Following existing idioms

I think the first issue is to define a small, closed set of life-cycle stages that can be applied consistently in different idioms. "proposed", "construction", "vacant", "disused", "abandoned" seem to be generally recognised, perhaps "operational" is needed as a default status. However, I can't find a single definition of this set. Without a well-defined, widely used class users of the data will struggle to handle this, whatever different idioms are used.

Secondly, there are a variety of different idioms already in fairly widespread use, some of which are easier for contributors to apply than others, and some of which can't handle all cases. The variety, and range / complexity of alternative proposals are probably the root of the problem for renders handling life-cycle data

Using your formats, <key>=<status> is the easiest to apply, and the most widely used, with over 6,000 uses of "railway=abandoned" more than 1,000 uses of "ncn or rcn=proposed", almost 1,000 uses of "highway=construction" and hundreds of other variations that are widely in the UK alone. There seems to be good reason to retain this format. Whatever alternatives are proposed for handlnig the more subtle cases, these are no reason for preventing contributors from using a straightforward format where it is appropriate.

However this simple format doesn't handle all cases well, and doesn't handle some at all. For example, "amenity=disused" is pretty meaningless information. Worse, the simple format can only be used on "top level" features, such as "railway", "highway", "building". It cannot be used, for example for an abandoned "waterway=canal", or disused "railway=station". So there is also a need to support an additional status tag in some form for these cases.

I can find two idioms in use to handle these cases. of the two, "<status>=yes" is the most common - it appears nearly 5,000 times in the UK as "disused=yes", and a few hundred times for the other states. This format is used across a wide variety of different type of feature, including "railway=station", "aeroway=runway", "aeroway=taxiway", "building=yes", "amenity=pub", "landuse=quarry", "waterway=canal", etc. A render might chose whether or not to recognise these attributes, but it can't sensibly pretend they don't exist. I suspect that they are non-trivial to handle because they are additonal tags, but not too difficult to be completely impractical. I suspect renders would be more willing to tackle this if the issue was more contained.

The alternative "status=<status>" only appears a few hundred times. "state=<status>" and "use_status=<status>" are less common variants handling a few dozen examples in the UK. With "status=" it is possible to see other values which are used for status. Vacant, proposed, etc are not the most common. "locked", "desired" rank highest. "closed", "open" and lots of others also appear. These are also sometimes used as primary tags: "locked=yes", and (less common) "closed=yes", "closed=pub". It looks to me as though this variety, ambiguity, and overlapping usage is starting to get impractical for a render to handle, but it is also allowing contributors to express a wider range of status than the short closed list above.

Based on actual usage, I would therefore suggest that "<status>=yes" should be the preferred idiom for handling a well-defined, small and closed set of status values that have specific meanings that are standardised across a variety of different features, which renders and data handlers are encouraged / advised to recognise. "status=xxx" (or, better, your more specific alternative of "life_cycle=xxx") should be acknowledged as a more expressive alternative, for use where contributors feel the standard range of values is too restrictive, want to record a wider variety of different values, or where contributors and / or data users feel that particular features have a special requirement that cannot be used more widely.

So far we therefore have three useful idioms: <key>=<status> for simplicity, <status>=yes as a universal standard, life_cycle=<status> as a more expressive alternative.

But we still haven't handled the general case where there is a change of use. None of the above is very satisfactory for handling former uses. For example, consider a railway station that is now a house: "railway=station, disused=yes, building=house" is ambiguous because it is not clear whether it is the station or the house, or both that is disused. This isn't a problem for the most common case, of top-level features. "railway=abandoned, highway=cycleway" for example is perfectly clear, and used fairly commonly. But this is a potential problem for many buildings and other features that have had a change of use.

Although everyone recognises the importance of mapping what is on the ground, there is also a reality that people normally map what interests them. From the database content it seems that contributors are more interested in identifying former railway stations than in describing the houses that they were subsequently converted to. And who can blame them?

There doesn't seem to be a standard way of handling this situation. "historic=station" and the like seem to be used this way sometimes, but that approach loads "historic" with more than one meaning (historic significance and/or former uses), which is not a good idea. Adding "former" or <status> to the value is used sometimes ("former_pub", for example, or "abandoned_canal"). While it has some attractions, but this approach forces contributors to string multiple values into the main tag, which makes them difficult to process (hypothetically: "building=house;former_pub"). A more common approach is simply to add a comment, note or description to the effect that this feature is a "former whatever". These are free format, so highly unlikely to be processable. Your "<key>-<status> = <value>" model provides a more systematic mechanism, but as yet there is no agreement, or widespread use. A much less powerful, but simpler alternative would be "former=xxxx" in the same spirit as "historic=xxx", but without loading any other meanings. However, none of these are agreed or commonly used approaches.

Finally we come to the advanced forms, of using life-cycle relationships, and mechanisms to tag the detailed history of a feature. I can see that there may be a need for these at some point, but at this stage I'm afraid that I am unconvinced. As far as the usability of the documentation goes, I see the first priority as being to make it easy for contributors to add a bit more information in a consistent way, and the second priority to move towards more consistency in the way that core data can be organised and used. It is interesting to discuss these advanced forms of tagging, one day this may become important, and it would be a good thing to keep on top of this, but that all seems a bit far off (to me).

The bottom line from all this is:

  • There is a need to acknowledge the existence of, and need for, more than one tagging idiom for lifecycles
  • To make appropriate rendering more practical there should be a (very) short list of universally recognised, well documented, life-cycle status values, and a couple of simple idioms where use of these is strongly encouraged, both by contributors and renders
  • Contributors should be encouraged to use a slightly different idiom when they want to be more expressive, and accept that the main renders cannot handle this
  • There seems to be an unmet need for an agreed idiom for recording former uses. A simple model would encourage primary tagging based on current use of the feature while accepting additional information. There is evidence that this is needed, and the various debates suggest that it would help both contributors and users
  • I think it is important to avoid the risk that basic guidance given to contributors gets confused by discussions of advanced forms of life-cycle tagging

-- User:Peter Reed 21:47, 7 May 2011

Recent developments: date-when pattern for ‹status›=* maybe?

I've been trying to rehabilitate disused=* and abandoned=* recently to fix up their data soundness issues. We'll see where that goes, fingers crossed. In doing do, I noticed an interesting idea from the proposed Key:Demolished: that of integrating a date when the demolition happened. I don't agree with representing demolished or otherwise obliterated objects, but there's no reason we couldn't steal the date notion for other tags using the current pattern. Perhaps something like this would make some sense?

building=parking
disused=1998-06
disused:amenity=parking
disused:capacity=49
disused:parking=multi_storey
abandoned=2001-10-19
sport=skateboard
note=Abandoned car purpose-build park now used as an ad-hoc skate park

Those would be reduced precision ISO 8601 date-time values. If we do that, we should specify that we always mean a date range:

‹date-range› := ‹iso8601-date-from-and-to› | ‹iso8601-date-from› ";" ‹iso8601-date-to›

with a reduced-precision date on its own indicating a range from the bottom of its possible values to the top. If two reduced-precision dates are specified, the first is evaluated low, and the second evaluated high. Tagging with ‹status›=‹date-range› would mean that the change to that status happened at some unknown point in the given date range.

Anyway, pure speculation for now.

--achadwick 11:08, 6 June 2011 (BST)

Here is my useless comment on the pages : disused=* and abandoned=* you have changed : That is perfect. We were running in circle on the Comparison of life cycle concepts without conclusion and you were brave enought to move forward. I fear you'll need more than fingers crossed for this, but I fully support the new proposed tagging for those two tags, and fully support extending it to other life cycle states (Maybe for ruins=* as well, but the subject is still too hot) sletuffe 14:48, 8 June 2011 (BST)

Cleanup of this page, and also of disused and abandoned

I have done some cleanup work on this article and also on disused=* and abandoned=*. Personally I am supportive of the highway=proposed + proposed=trunk tagging for simple road developments, augmented with secondary tags using the status:key=value format. Happy to have a conversation here on the matter :) PeterIto 13:38, 7 December 2012 (UTC)

But there's more!

Life cycles have quite a few more stages than are yet codified in OSM tags. For example:

  • Citizen concept (no landowner/government involvement yet)
  • Proposed
  • Planned
  • Under construction
  • Operating
  • Broken (but expected to be fixed)
  • Disused (not expected to be fixed). Shades of this include abandoned, vacant, empty.
  • Preserved (e.g. a stabilized ruin).
  • Converted (e.g. historic:railway=funicular).
  • Proposed for removal.
  • Under demolition.
  • Historic.
  • Rebuilt.

Brycenesbitt (talk) 05:55, 29 June 2013 (UTC)

<state>:<tag>=<value> for ruined feature

Is it a good idea to transport that scheme to ruined features ? Discussion is here ruined:=* sletuffe (talk) 14:25, 23 September 2014 (UTC)

Sorting what appears to be the most promising concepts

The page should be imho ordered so that the more promising concepts come first. For me the "top-runners" are

- with the benefits that those two can be neatly combined together and with other already approved features in a logical manner and seem to pose the least risk to break backward compatibility. I think "<key> = <status> + <status> = <value>" is also pretty good but combining it with "tag:DATE/PERIOD=.." would look inconsistent.

Other opinions? RicoZ (talk) 14:28, 19 December 2014 (UTC)

Sounds good to me! Lightsider 11:10, 2 April 2015 (UTC)
I think the recent edits only remove the page further from it's original topic: Mapping the current status of a feature. That does not include history mapping, which is why that was only under "Related concepts". That's one of the reasons why I'm not a fan of your changes to the page a few months ago. --Tordanik 16:56, 2 April 2015 (UTC)
# I am putting a disclaimer like "Historic objects with no relevance to current state of an object generally do not belong into the main database" on top of every page that I encounter.
# I was looking at the various "history mapping" related pages and found them in a rather unusable state - nothing where I could link to. Too many pages with too many problems.
# Life cycle does necessarily somehow relate to past and future states of an object. While per above disclaimer the history does not belong to the main database, my idea is that the tagging should be compatible between the two projects. So if someone decides to create a map using data from both databases, the data should be as far as possible compatible.
RicoZ (talk) 09:42, 3 April 2015 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Comparison_of_life_cycle_concepts&oldid=1283516"