[EuroVelo] EV17

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).

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

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).

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 :slight_smile:

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.

Oh boy, the last thing we need is RefGPT! :grin: 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.

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”

Done: [EuroVelo] What to do with cycle_network

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.

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

During years, EV17/ViaRhona between Valence and Avignon has been in a transitory state with interim itineraries on both sides of the Rhone, i.e. one on the right and one on the left side at the same time, and documented so on the ViaRhona website. Today, there is only one route in this section signposted both as ViaRhona and EV17. However, there may still subsist remains of the interim routes in OSM and on various websites.

I rode this section in June 2023 and if I remember well, the EV17 relations correspond to the signposted route except around Charmes where the track from the EV website is correct.

Well there you have it. My only quibble is that stripping out the prefix – in other words, parsing the number out of the ref – shouldn’t be something that data consumers are forced to do, since it leads to so many edge cases. For example, it shouldn’t be necessary to know that “EV” can be stripped from the beginning of a ref, but not the “K” in K2, the “Y” in Y1, the “EW” in EW5, or the “A” on either side of A1A. It would get even more complicated if, seeing the “EV” on EuroVelo routes, mappers decide to prepend network-based abbreviations to these routes too. In any case, it sounds like the “EV” will be omitted from the EuroVelo refs for multiple reasons anyhow. :+1:


I verified and corrected the sections Valence - Le Pouzin and Le Pouzin - Châteauneuf. Both stages are identical to the gpx tracks from ECF except some minor divergences due to recently constructed cycleways. I did not touch tagging and structuring of relations, just removed/added ways.

La Drôme à Vélo is an alternative route for the ViaRhôna route (according to Piste cyclable le long du Rhône en Ardèche : La Voulte / Viviers - ViaRhôna), but not for the EV17. ViaRhôna is only a european route, it doesn’t have a national ref number in our national bike routes scheme. Even though, it still has some freedom to publicize alternate routes on its national website, but they can’t be signed with EuroVelo signs, therefore can’t be part of EV17 relation or EuroVelo website.
I think they should be part of ViaRhôna relation with an alternate role.

On the ref topic, we will have a problem:
EuroVelo 17 : network = icn, ref = 17, cycle_network = EuroVelo
ViaRhôna : network = ncn, ref = ???, cycle_network = ???

According to the french national bike routes scheme (SNV), ViaRhôna ref should be 17, and cycle_network should be EuroVelo. It raises an issue, as it would mean that two different relations would have the same ref and cycle_network values, only being distinguished by their network tag. What can we do about it?

It won’t be an issue for the swiss Route du Rhône as it has a separate numbering in their national scheme.

Interesting. Each operator has a framework with one or more networks/systems, and references within these networks/systems?

If it can’t be signposted with EuroVelo signs, what makes it part of the EuroVelo network? Alternatively, could a more specific cycle_network value or an operator tag help to distinguish this route from the EuroVelo routes that are signposted as such?

The ViaRhôna is signposted with EuroVelo signs, it’s the alternate route La Drôme à Vélo that can’t be.
ViaRhôna could have cycle_network = Schéma National des Véloroutes (or “SNV”), but it would be redundant with network = ncn. I don’t know what would be the best solution.

@StC yes, each NECC has its own system. In France EuroVelo routes are by default part of the national scheme, under their european identifier (cf. https://www.velo-territoires.org/wp-content/uploads/2022/04/JALRIC-IDD.pdf page 16). I don’t know the swiss scheme, but according to swissmobile, it doesn’t seem to have an european category, only national, regional and local.