Talk:Key:state

Use Lifecycle prefix instead of state=proposed

While state=proposed has been used in past, its use has also revealed some drawbacks. Nowadays, the concept of Lifecycle prefix became available, witch is much more versatile and reliable. The use of state=proposed should not be recommended for future use. -- Roland5 11 October 2019

I've added mention of Lifecycle_prefix tagging and the proposed:route=* prefix --Jeisenbe (talk) 00:54, 29 October 2019 (UTC)

Richard, could you respond here? The lifecycle prefix proposed=: has been used over 8000 times (overpass-turbo) and it has the advantage that it clearly distinguishes a proposed feature from a real, current feature. Hopefully my recent edit was less misleading. --Jeisenbe (talk) 02:54, 16 January 2020 (UTC)

Not really, I'm afraid! You say "A common alternative to state=proposed is to use the prefix proposed:*=*". But it isn't. state=proposed is only used on route relations; this page is talking about route relations; and proposed:* isn't used on route relations. It might be a common alternative when you're tagging _other_ proposed things, but it isn't a "common alternative" here at all, as taginfo demonstrates.

The bit about database users isn't really true either - OpenCycleMap, for example, renders state=proposed distinctly but I'm not aware that it renders proposed:* in any way. Plenty of other clients (e.g. Waymarked Trails, cycle.travel) parse state=proposed without trouble.

Finally, it's not actually clear what you're proposing - you say proposed:route=*, but I guess that means you're suggesting (say) type=route, proposed:route=bicycle, which is surely also misleading because it's not actually a "type=route" yet either.

I can see where you're coming from (it's the whole Trolltag thing), but the suggestion needs more thought and to be expressed more clearly. In my ever-so-humble opinion of course :) --Richard (talk) 11:18, 16 January 2020 (UTC)

The main point of using the proposed=: is that most database users will not find the tag. A proposed route isn't a real, verifiable route, so it shouldn't be tagged as a route=* at all. Many proposals are abandoned and never constructed or signed. But I suppose it is true that 8000 uses is not yet very common compared to the potential number of proposed features, so I'll remove that. --Jeisenbe (talk) 12:06, 16 January 2020 (UTC)

You keep adding datapoints about database users. Could I ask that you get some evidence about this? You've said "this makes it clearer to database users that this route is not yet in existence". I'm honestly not sure where you get this from. I use route relations at cycle.travel. proposed:route does not make it clearer to me; it's a minority usage that I now have to cope with because you're encouraging people to use the tag. If you can get corroboration from other "database users" who use route relations (say, Andy at OpenCycleMap, Sarah at WaymarkedTrails, Martin at CycleStreets) that this does indeed make it clearer then that's cool, but you can't just say "this makes it clearer to database users" without asking any database users. --Richard (talk) 00:12, 28 January 2020 (UTC)

Re: "usage that I now have to cope with" - a map or routing app doesn't have to consider proposed:route, because a proposed route is not a route. It does not yet exist, and might never exist if the funding does not go through. Yes, if you do want to show proposed or planned routes on map you will need to interpret state=proposed and proposed:route and perhaps other options. But if users tag a proposed/planned route, which does not yet exist, as route=* + state=proposed, then any map or routing app which wants to show or use real routes will need to exclude those with this tag. This sort of tagging has been called a "troll tag", since it takes a tag which has a certain meaning ("a signed bicycle route") and changes it completely ("a planned or proposed bicycle route which does not currently have any signs or markings"). --Jeisenbe (talk) 00:49, 28 January 2020 (UTC)

State=proposed implications on node networks

This node is part of a node network that is still in state=proposed. Some data users think it is correct to not add anything to the node itself to make it clear it does not exist yet. Other data users are blisfully unaware. What is the best option here?

1. do nothing, data consumers have to take in account the relation the Node belongs to before rendering
   
2. add a state=proposed tag to the node (the "normal" way for route relations)
   
3. change rcn_ref to proposed:rcn_ref (the "normal lifecycle-tagging style")
   
4. use rcn_ref=proposed + proposed=the future value for rcn_ref (the "normal" logic as used for roads, as suggested by Pelderson below)

Note: a node network might be "in the process of being implemented". A simple solution would then be to remove state=proposed from the network, and add a tag to the nodes to indicate their status. But it might make more sense to split the network in two relations, one with the operational part and one with the proposed part.

Joost schouppe (talk) 07:47, 30 June 2021 (UTC)

Some thoughts on the matter.

1. I would prefer a method that is generic for all node networks.

2. I think the best lifecycle tagging method in this case is rcn_ref=proposed, proposed=<ref>. With prefixes, you in fact introduce lots of extra main keys for data users to process. In this case, proposed:XYn_ref where X is scope: l, r, n or i, and Y is transport mode: w, c, h, p, m, and the transport list is growing, so potentially at least 20 new keys and no upper limit! Since named nodes are introduced, another at least 20 new proposed:XYn_name keys are introduced.

rcn_ref=proposed says exactly what is proposed and what not. This is necessary because many network nodes have multiple XYn_ref values. 2 is very common, 3 regularly occurs too, e.g. for cycling, walking and horseriding on one logical node. Tagging state=proposed for one transport mode would then disable the node for others.

3. Advantage of generic lifecycle tagging with <main key>=proposed, proposed=<value> is that data users do not need to adapt their software to display or suppress anything. Only the proposing party has to use an adapted tool for develoment and testing, and that is how it should be! Then they can decide who can use their tool to see or test the plan.

4. The node network relations are not relevant to nor supported by data users, they are only processed in Knooppuntnet Analysis for maintenance. I think it is best not to base anything on them. The issue is about a lifecycle stage of objects: routes and nodes, so the solution is to add an attribute to each specific object involved.

If you would nevertheless want to use the network relations, I would say: add a role to the members to indicate the state of the member in the network. That would record the information neatly, but I think any solution involving a network relation would require much more adaptations on the data user end, starting with that they should start to consider the network relation in the first place.

--Peter Elderson (talk) 10:32, 30 June 2021 (UTC)

Peter, I added your suggestion to my original post, however doens't that only work for a single key? Would you not want to do the same with cycle_network=srfn_gent? Or is it always enough to do this with just the XYn_ref key? I don't know if that happens, but maybe there's more than one XYn_ref?

Also: do data consumers need to care about all those potential proposed:*=* tags? I'd assume most would simply and rightly ignore them.

Joost schouppe (talk) 08:27, 1 July 2021 (UTC)

Re the second point, I think it is conceptionally better to put variations into values, not keys. That makes your data model (and the maintenance work for mappers) more generic and IMO easier to understand.

Re the first point, the XYn_ref key (combined with the network:type=node_network) defines the node as a junction for the XY node network, while at the same time the same node may have a different **n_ref for another network. So you need to mark this specific attribute (key) as proposed, while leaving the others operational. If another **n_ref for a different network is also proposed (or any other lifecycle stage) it also needs to be marked as such. The name of the cycle network is not relevant to this, I think? Whether the node is proposed or operational does not change the fact that it is part of that cycle_network, which doesn't even need to be tagged on each individual node.

In any case, state=proposed disables the whole node for all networks it is part of, so that is not the best way to handle it!

Edit: Ah, I see where my logic potentially fails. If more than one **n_ref on the same node has the value 'proposed', where do you put the future value of each if you only have a single proposed=* tag? I have never encountered this situation yet, though.

Relation Roles

What's the difference between this & Relation Roles? If 'abandoned' ie it doesn't exist any more, it should be removed from the OSM database. If 'proposed' then it's not a current route. So many of those 'proposed' never come to fruition but get left in the database, cluttering it up.--DaveF63 (talk) 12:44, 6 November 2021 (UTC)

Putting aside answering "the difference between..." I must object to the assertion that state=proposed "clutters up the database." National bicycle routes in the USA (called USBRs) use this tag while they are "on ballot" (being considered by AASHTO, the body that formally adopts national highway numbers in the USA), allowing them to be "constructed" in OSM, so some renderers choose to display these with dashed lines for the route during this duration. (As some are hundreds of miles/kilometers long, this can take "days to weeks"). As the routes "on ballot" become Approved (AASHTO votes majority Yes), OSM simply removes the tag, allowing renderers to make them go from dashed lines to solid lines. See USBRS to discover that not "so many of these never come to fruition..." or that this is a "cluttering" tag, but rather 100% of USBRs that go to ballot have come to fruition over the course of the last decade. So, this isn't a useless tag at all, it is well-documented, well-used and well-rendered (well, in the case of USBRS, which is "enough"). Please be careful with blanket assertions about tags state=proposed and abandoned: (as a prefix tag, as a value for tags like railway=*...) that simply are not true. Stevea (talk) 22:32, 6 November 2021 (UTC)