[EuroVelo] EV17

[StC]

@Richard

EuroVelo 17 - Rhône Cycle Route” isn’t a name, any more than “A34 - Stratford Road” is a name.

Who are we to decide this, when the operator says otherwise? I am weary of editorial choices that are not prompted by necessity.

[Vinzenz_Mai]

Hi @Idrizza , thank you for your great information.

@Idrizza

At V&T we use those short codes for national and european routes (V66, V80, EV17, EV3) as labels in our maps

@Florange_Grimoire proposed to use the proposal draft of @Nadjita. This would provide the aptly named tag label

@Richard, what do you think about that new for the future?

@Idrizza

I think stages should be cut at borders if there is discrepancies between the two national operators

I second that gladly.

@Richard

ref=17
name=Rhône Cycle Route
cycle_network=EuroVelo
network=icn

What about

ref=17
name=Rhône Cycle Route
cycle_network=EuroVelo
network=icn
label=EV17

cycle_network + ' ' + ref would provide the “EuroVelo 17”

[Florange_Grimoire (Florence Grégoire)]

Hey!

Thanks Idrissa for your contributions

I have not had the time to read this whole thread yet, but I just wanted to answer/comment on the ref & names discussion.

Regarding the code “EVXX”, indeed we use it only internally. It is not used anywhere on www.EuroVelo.com (except in the route pages urls) and it is not used on signs, as Idrissa pointed out. So following the proposal from @Nadjita , I think what @Vinzenz_Mai just wrote makes the most sense. Ref should be “17” because that’s what’s written on signs, and “label” should be “EV17”.

Regarding names, official names of EuroVelo routes are the full names (with 3 official versions in English, French and German, as can be found on the website):

• EuroVelo 1 - Atlantic Coast Route
• EuroVelo 2 - Capitals Route
• EuroVelo 3 - Pilgrims Route
• etc.

However, I am fine with the proposal from @Vinzenz_Mai since, indeed, “cycle_nework + ref” would provide the “EuroVelo 17”. This way, we don’t duplicate information.

[Richard (Richard Fairhurst)]

@Vinzenz_Mai

What about

ref=17
name=Rhône Cycle Route
cycle_network=EuroVelo
network=icn
label=EV17

cycle_network + ' ' + ref would provide the “EuroVelo 17”

I think that would be excellent.

[StC]

Working on it, keep posted

[Vinzenz_Mai]

@StC

Given this, I believe it is the responsibility of the database to provide data users with a human-designed short name either the one provided by the operator or one that is designed with some knowledge of the context.

I created a new topic and turned it into wiki to document the conclusions to tagging and structuring the EuroVelo routes: [EuroVelo] Conclusions - Action point "tagging and organising" EuroVelo routes

Incidentally @SomeoneElse proposed to use short_name instead of label

[StC]

OK, I have tried to apply what seems to produce a consensus so far (or something like it), to the ‘French’ part of EV17. If it suits everybody, I’ll do the same to the ‘Swiss’ part. (I use quotes because there is a Swiss section in the ‘French’ part).

Here are a few snapshots of the result.

JOSM (Note that the actual routes in OSM do not look like what follows in JOSM: I have not saved after removing the ‘note’ tags and the ‘superroute’ tag.)

JOSM relation editor

OpenStreetMap

ID

Waymarkedtrails

Waymarkedtrails, subrelations

[Peter_Elderson]

@Richard

(cycle_network isn’t a great tag, but it’s what’s currently used.)

I would prefer a more generic key or system, to allow one naming system across routes for all transport modes: foot/walking/hiking; bicycle/cycling/mtb; horse riding; motorboat; canoe, and whatever else is or comes around.

There are already too many transport-specific keys as it is, while basically the routes are not that different. From an informational standpoint, that is. They are all strings of ways, grouped together in all kinds of ways.

How about something like operator_network=EuroVelo? That would work across all routes and transport modes, doesn’t repeat information already present (route=bicycle, network=*cn, hence no need to stress again that it’s about cycling).

[StC]

@Peter_Elderson

How about something like operator_network=EuroVelo? That would work across all routes and transport modes, doesn’t repeat information already present (route=bicycle, network=*cn, hence no need to stress again that it’s about cycling).

Why not network=EuroVelo, like seen in other transportation modes?

[Richard (Richard Fairhurst)]

You can’t use network= because it’s already taken for the ncn/rcn/icn values, sadly. One of those accidents of OSM tagging history.

system= would work as a synonym (i.e. meaning “part of the EuroVelo route system”, “part of the London Cycle Network system”, that sort of thing).

[Vinzenz_Mai]

@StC

OK, I have tried to apply what seems to produce a consensus so far (or something like it), to the ‘French’ part of EV17.

I’m not fully convinced, even if it is the lowest count of layers in the hierarchy of the superrelation (that is needed).

Do you really want to remove all segments? What about the two different start parts (Rhone Route and ViaRhôna), what about the two different end parts from Beaucaire to the Mediterranean? What about stage information (be it ViaRhôna or EuroVelo 17)?

The more I learned about EuroVelo 17 the more I am convinced that it’s a really special one, the combination of two national routes.

[StC]

That is why I experimented: to get a real feel of what the results look like.

Experience (particularly on E* routes) shows that EV17 is not very special. For instance E2 and E5 have the same structure. That is why I proposed it as a first example

As for the removal of the national segments, favored by @Idrizza and others, I personally see good points and points that need more exploration:

• as @Idrizza proposed, when there is a ‘real’ national route it can exist on its own. Here, ViaRhôna continues to exist, just not in EV17
• the question of how to handle national borders wrt daily sections disappears or is shifted elsewhere
• we probably need to have an operator tag in each daily section, to better represent who is in charge of what
• QA tools would definitely need some work, e.g. on Overpass queries based on geography and/or the operator tag, to split the work between maintainers

As for the two branches at the south end, I believe we have several options, including letting data users sort the situation based on geometry, and using roles like currently done with forward/backward.

[Minh_Nguyen (Minh Nguyễn)]

@StC

short of embedding AI engines in apps, it is not easy to produce a relevant short name from the long name

Oh boy, the last thing we need is RefGPT! Some routers are already maintaining their own lookup tables to convert way ref prefixes to spelled-out names more suitable for text-to-speech engines, so it isn’t a stretch to imagine something similar for cycle_network. A more data-driven approach could be based on a shared library, or Wikidata’s road number formatter statements, or even (ugh) scraping a table on the OSM Wiki.

@Peter_Elderson

There are already too many transport-specific keys as it is, while basically the routes are not that different. From an informational standpoint, that is. They are all strings of ways, grouped together in all kinds of ways.

How about something like operator_network=EuroVelo? That would work across all routes and transport modes, doesn’t repeat information already present (route=bicycle, network=*cn, hence no need to stress again that it’s about cycling).

This would be worth a separate thread too. (We’re on a roll!) cycle_network was clearly a short-sighted key name, essentially borne out of exasperation at the extremely limited network=lcn/rcn/ncn/icn scheme. The U.S. was just starting to develop its national cycle route system and we knew we’d need much more flexibility, because the authorities were planning to mimic highway route designations. At the time, no one wanted to extend the three-letter scheme, because doing so would break OpenCycleMap and Waymarked Trails, so here we are.

This wiki discussion floated some other possibilities, such as network:name in combination with the already common network:wikidata. It’s important to distinguish networks from operators, because many entities manage multiple networks and some networks have no centralized operating entity.

[Peter_Elderson]

@Minh_Nguyen

It’s important to distinguish networks from operators, because many entities manage multiple networks and some networks have no centralized operating entity.

That is managed by using separate keys for operators and *networks.
An operator_network with a name but (currently?) without a formal central operator, just leave out the operator key. Think of the operator of the network as ‘the cloud’. I think, when there is a name, there is some entity which has given it a name.
Operator on the network level doesn’t have to be an active party on the road. That is usually left to country-wide operators, whoalso may delegate the actual work to other entities. Assign the operator tag at the level that the (super)route relation represents.

[Richard (Richard Fairhurst)]

@Minh_Nguyen

Oh boy, the last thing we need is RefGPT! Some routers are already maintaining their own lookup tables to convert way ref prefixes to spelled-out names more suitable for text-to-speech engines, so it isn’t a stretch to imagine something similar for cycle_network.

No need to imagine it - cycle.travel is full of that sort of thing already. It has a lookup table to rewrite all the EuroVelo route names, for example, and processes the refs to remove “EV” before putting them in a blue-with-yellow-stars shield.

[StC]

OK. As I understand it, you all are saying “no need for intelligence, whether human or artificiel, to reduce a long name to a short name: we can build a short name from tiny bits such as ref and cycle_network, going through a dedicated tabulation system if necessary”.

To this I reply: “you are obviously right for EuroVelo, so maybe we can leave it like this; this might reemerge later though, e.g. for less important (and more numerous) routes with no obvious reference system”

[StC]

@Minh_Nguyen

This would be worth a separate thread too.

Done: [EuroVelo] What to do with cycle_network

[StC]

Back to practical issues in EV17. Something I did not say yesterday is that a subrelation distinguished itself from the others: La Drôme à Vélo 91 : Le Pouzin - Ancône. This may or may not involve an analysis of how we manage sections that are common with local routes (another possibility being that this is an alternative route that should not be in EV17).

[Vinzenz_Mai]

If it’s signed as EuroVelo it would be an alternative part. There’s the need of local knowledge, because it’s not mentioned in the ViaRhôna stages. It’s not included in the GPX files, so I would not include it.

There was a second one, shorter that you seem to have integrated into Tournon-sur-Rhône -Valence (the part on both sides of the Rhône). It was a separate relation before, about 8 km long.

[StC]

Something I learned from @Idrizza: the charter of EuroVelo discourages branches and alternative routes. It would definitely be an argument for removing.