Migrating proposed routes to a lifecycle prefix

General talk Tagging general discussion
, ,
1

state=proposed is the original tagging scheme for a proposed cycling route designation. It has spread to some other recreational route types but little beyond that. Lifecycle prefixes have since emerged as a more foolproof mechanism, allowing data consumers to opt into proposed routes instead of having to opt out of them. I’m wondering how much appetite we have for migrating route relations from state=proposed to the proposed:*=* namespace.

state=proposed requires data consumers to specifically special-case it to avoid prematurely treating a proposed route as a current, usable route. The tag could surprise other data consumers, especially routing engines and vector tile schemas that strive to handle route relations in general so that routing profiles and stylesheets can refine the output further. It’s a classic troll tag, though it predates that term by quite a bit. The risk isn’t limited to proposed infrastructure like highway=proposed; proposed routes often traverse already completed thoroughfares.

Concerns about state=proposed arose on the tagging mailing list back in 2011 and on the talk page in 2020. That year, some U.S. mappers considered retagging proposed U.S. Bicycle Route relations as proposed:route=bicycle, leaving state=proposed in place for emphasis, but there was an objection to changing the tagging scheme at the time, so we mostly stuck to route=bicycle state=proposed. I’m unsure if there has been any other debate about this tag.

As of February 2, route=bicycle state=proposed is the predominant tagging for a proposed bike route designation:

Tags Prevalence Distance Geographical distribution
route=bicycle state=proposed 6,731 65 035 km Europe (especially Ireland), United States (especially Alabama, Florida, Tennessee)
proposed:route=bicycle 821 7 830 km Europe (EuroVelo), Russia, United States (GART)
route=bicycle proposed:cycle_network=* 556 871 km United Kingdom (London), United States (Santa Cruz, California)
route=bicycle proposed=yes 68 1 429 km Belgium, Germany, United States (Washington)
route=proposed proposed=bicycle 22 199 km Austria (Vienna), France, Germany (Leipzig)

state=proposed is much more prevalent among recreational route types than among public transportation route types:

Feature state=proposed proposed=* proposed:*=*
route=bicycle 6,731 68 821
route=hiking 619 6 30
route=mtb 42 4 3
route=road 34 13 17
route=railway 19 10 4
route=foot 17 5 4
route=tracks 3 1 2
route=subway 1 2 39
route=bus 10 1 32
route=light_rail 1 2 14
route=ferry 0 3 8
route=train 4 4 8
route=tram 0 1 1

With PTNA throwing its weight behind proposed:route=* Based on current trends, I suspect public transportation routes would naturally shift toward proposed:route=* without any active effort anyways, but we can migrate them anyways to resolve any existing compatibility issues.

I’m more interested in migrating highway route relations to proposed:route=road. Even though route=road state=proposed is slightly more common than proposed:route=road, it’s close enough that a tagging change to unify tagging wouldn’t be very disruptive. We definitely wouldn’t be able to consolidate highway route relations under route=road state=proposed. It would break compatibility with a number of existing renderers and routers, which would start to show them as usable routes, misleading users. On the other hand, we could consolidate them under proposed:route=road without much fuss. Few renderers intentionally depict highway=proposed, let alone proposed highway routes. At a glance, some route=road state=proposed ref=* relations contain extant roadways, like D 304 in Chalon-sur-Saône, but it seems like outdated tagging. Many more relations rely on fut_ref=* to hide the route number from renderers such as OsmAnd and OSM Americana. This would no longer be necessary with proposed:route=road.

Retagging recreational route relations would be more disruptive. The most popular trail renderers do recognize state=proposed, but only to deemphasize or hide the route entirely. It seems that the consensus among data consumers is to treat the routes as noncritical for wayfinding purposes. After all, proposed routes don’t manifest in the field. If state=proposed were a fresh proposal today, I’m confident we would reject it out of hand because this usage would be far outweighed by the risk of unaware data consumers treating the routes as real routes. Even with so many years of history behind state=proposed, the tradeoff is still unfortunate. Anomalies like state=proposed and cycle_network=* would probably discourage more data consumers from making use of cycling route relations.

Would folks have any concern about shifting public transit and highway routes away from the tagging scheme that recreational routes use? Would we be willing to go further and migrate some recreational route networks to the proposed:*=* namespace, as we’ve started to see with EuroVelo?

11 Likes
2

I am highly dubious about mapping such proposed stuff, but lifecycle prefix is clearly much better idea than state=proposed.

10 Likes
3

Thanks for picking this up!

I see the ‘weight’ here, but I (PTNA) never had and have the intention to push some “standards” forward outside of the standards procedures.

I just found the threads mentioning this and many routes tagged like this (and suspended:route=*, disused:route=*, …) and wanted to support mappers by reporting them in a dedicated section. I could have done that with state=proposed (and still can) but it seems I wasn’t really aware of this tag.

2 Likes
4

Do these “proposed” reflect the same reality on the ground?

For public transport, the line is planed, along existing roads, but not active.
For cycling, it might just not be signed on the ground, but one could easily follow it, etc.
Other proposed need first to be built?

5

It probably depends. Some route networks go through a much more rigorous planning process than others. And funding realities can stretch the planning stage very long. But at least for the networks I’m familiar with here in the U.S., a proposed route would not be signposted on the ground, regardless of type. General-interest transportation maps might depict a long-planned, still unbuilt highway, but not a planned route designation over an existing highway. By contrast, the “Future” route networks in the U.S. are signposted and somewhat usable for wayfinding. Those get tagged as normal routes other than a network=*:Future tag.

As I see it, the proposed route relations are just placeholders for future routes, subject to change as the plans progress. They don’t satisfy the on-the-ground rule, but they could prevent overzealous or misinformed mappers from prematurely entering routes before they’re usable. I don’t think this justifies the risk of data consumers accidentally exposing them as usable routes. So if we must map them, I’d prefer a more obscure syntax than state=proposed that forces interested data consumers to opt into them. That said, a wholesale migration could be disruptive, so I’d like to gauge the community’s opinion about how to move forward if at all.

6

I was mostly wondering about the steps between the proposal and the live route.

Whether it’s just a matter of updating somebody’s daily route (public transportation) or if it implies actual work on the ground (construction or simply new signs).

7

Though maybe preferred option is to not map such things at all?

If bicycle route exists solely as paperwork (and is not recognizable as named route by people, unlike some hiking, pilgrimage and cycling routes), then it seems out of scope for OpenStreetMap.

1 Like
8

Again it depends. A proposed route over a proposed road or path requires significant capital investment to turn into a reality. This proposed route designation along an existing freeway would still cost up to $19 billion – not to change the shape of the route relation, but rather to build in all the safety features required by that designation. But in other cases, it’s just a matter of patching a few overhead signs or, in the case of a bus route concurrent with an existing bus route, slapping a sticker on the sign at each bus stop.

In principle, yes, but I’m more concerned about misleading data consumers and end users than keeping extra cruft around in the database. Whether it’s proposed route relations or fut_ref=* on the individual ways, we do need some ability to urge mappers to think twice before adding a future route to OSM as a current route, and we need that to be distinct from the current routes.

That said, I would encourage local communities to review their use of these tags, in case any proposed route has been finalized since it was first mapped. We wouldn’t want to keep this information from a relation-aware renderer like OSM Americana.

9

my main worry here, is that this thread may be constructed as accepting/supporting keeping this

(note: maybe elsewhere such proposed routes has more connection with reality but in Poland such routes are either nonsense, just-before-elections-promises, never built, not recognized by anyone, not treated seriously or multiple of these at once)

10

If you know of an effective technique for discouraging mappers from mapping not-yet-ready routes, more power to you. To me, this is like any lifecycle prefix. I’m glad we replaced building=demolished with demolished:building=*, even if it potentially gives a little cover to mappers who go out of their way to find demolished buildings to map. We can come up with guidelines on when and when not to map the feature with the lifecycle prefix, independently of ensuring that the out of scope features don’t create real-world problems.

1 Like
11

I looked at a few of the “proposed” bicycle ones. Their actual reality on the ground seems to vary a lot:

12

The U.S. examples you chose are a study in contrasts. I’ll regale you with a full explanation, which won’t be very satisfying, but I don’t think it has much bearing on the question of how to tag a planned route if it does get mapped for whatever reason.

Note the striking similarity between the operator=* tag and the user name on the first version. Despite the organization’s grandiose name, it has yet to grow beyond a personal effort in the Seattle area as far as I can tell.

Back when OSM was still a toddler, bike route systems were still a novelty in much of the U.S. Governments and official trail managers had no intention of designating routes systematically, so individuals and community groups took on the task of unofficially promoting their route numbering visions. Eventually, some of these ideas became the backbone of official route systems, which are reflected in OSM. Other proposals were less successful. In Santa Cruz, California, the local government declined to adopt the local OSM mapper’s proposal a decade ago, only considering the selection of routes for planning purposes, but the proposed route relations remain on the map, numbers and all.

A lot of this mapping comes from an earlier concept of OSM as a collaborative scratchpad for local enthusiast communities, back when the ecosystem of tools built atop OSM was not as vibrant as it is today. I think mappers really need to find somewhere else to memorialize these proposed-through-OSM routes.

Even when routes have official support, they may not be particularly usable for navigation, or the officials expect cyclists to carry around guidebooks or maps like ours to follow the route. In my city, mappers copied a route numbering system from a 2008 planning document[1] even though it was only ever a planning concept, never implemented as a wayfinding system. It wasn’t until last month that we finally cleared out the numbers in order to make room for the completely different numbers that a different agency actually posted on the ground.

In the last decade or so, users in the U.S. have come to expect more from bike routes on maps. Enough local and long-distance bike routes have user-friendly signage that the old way of doing things via planning document is no longer good enough. A proposed route relation needs to be on track to become tangible on the ground.

This route is part of the U.S. Bicycle Route System. Proposed USBRs are initially based on a 2008 National Corridor Plan put out by the Adventure Cycling Association in partnership with state and national authorities. The plan designates 50-mile-wide corridors for the development of USBRs. Each corridor generally follows existing trails or highways. The state authority will eventually ask the national authority to approve the route designation, after seeking the support of each local government and trail manager along the route. By this time, portions of the final route may follow a newly built trail instead of a highway, but the overall route will largely use the same facilities that the 2008 plan was based on.

We don’t map proposed USBRs based on the corridor plan per se. The earliest that we map a USBR is when the state circulates a draft proposal for the city councils and trail managers to review. By this point, the process is already in motion and the route is generally fixed, other than some minor details within cities. However, this process can sometimes drag on for several years depending on the state’s priorities.

A month after this route relation was first created back in 2021, the state authorities submitted a successful application to the national authority for USBR 677. state=proposed should’ve been deleted, but instead it was replaced by proposed=yes by accident and no one noticed until just now. Setting aside this mistake, I think the in-progress USBRs are fine to map as proposed routes. Think of it as staging a relation that we’re reasonably confident about, doing the hard work ahead of time instead of waiting until the press release comes out and then rushing to get it done.

If the situation on the ground ever changes substantially, the state will have to submit an application to formally change the route. This is true of any nationally coordinated route. If State Route 68 gets upgraded or realigned, then this note serves as a reminder to double-check whether the state has gotten USBR 677 changed before assuming that it follows the new alignment.

  1. Revised in 2018. ↩︎

1 Like
13

Interesting. I agree with the proposal in general.

2 Likes
14

I agree with this proposal, if only to unify the folks who are tagging mostly from a windshield prospective with the rest of the map.

15

I was bracing myself for more controversy than what transpired. :sweat_smile: Retagging the cycling routes would be a daunting task at the outset, but maybe we can start with the public transit routes, which are already mostly using the lifecycle prefix. Then we can move on to the highway routes before considering any of the cycling routes, which would probably need coordination with data consumers. Any objection to staging the work in that order?

I’d appreciate help with retagging. It affects a bunch of countries where I don’t speak the local language or understand the local route designation scheme, so I may not be able to explain the tagging situation as well.

16

A nice thing about the proposal is that some of the ways that might be harder to implement illustrate why the proposal is a good idea (removal of proposed tag forgotten after implementation, proposed tag used the other way round - for parts already implemented).
Maybe a special solution needs to be found for the Belgian sample.

17

Looking at the Belgian cases with a proposed tag on the route relation, it seems like most of them are proposed=yes or even proposed=cycleway on relations that are also state=proposed, so don’t really need to be taken into account.

As for switching to a lifecycle prefix, I probably wouldn’t object. Tagging @Thierry1030 who’s more involved as well.

(Context in case it’s interesting to anyone: we use state=proposed for anything from “government has a vague idea of where the route should go” to “infrastructure is completely finished in its final state, but there are no direction signs yet”)

Wiki page for reference: Tag:cycle_network=BE-VLG:cycle_highway - OpenStreetMap Wiki

18

For a long time in OSM we had a V6 and a proposed V6. Regularly some parts where added to the V6 but not removed from the planned/proposed part. I can’t find the proposed V6 anymore, I think it’s fine (no problem with a planned/proposed part as long as it’s properly curated).
Yes, here it’s a cycling route.

19

To clarify, I’m highlighting that both status=proposed and proposed=* are effectively troll tags when applied to route relations. I’m proposing to replace them with proposed:route=*, starting with public transit routes, then highway routes, then eventually recreational routes.

1 Like
20

The sample I was referring is in my earlier comment at Migrating proposed routes to a lifecycle prefix - #11 by 9_tab . It doesn’t particularly matter which country it is in, but it refers to a route that is partially or mostly finished. There might be other similar ones elsewhere with varying percentages of completion.