(cycle_network isn’t a great tag, but it’s what’s currently used.)
“EuroVelo 17 - Rhône Cycle Route” isn’t a name, any more than “A34 - Stratford Road” is a name. Refs and names are both public-facing information and it is absolutely expected that a map or routing app will read both.
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.
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.)
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).
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.
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.
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.
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.
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.
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”
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).
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.