[EuroVelo] Improving EuroVelo routes tagging

As announced in this thread, we’re creating sub-discussions to better focus on the main issues at hand, and avoid discussions to become too mixed up.

Here was my summary on current tagging issues, to which I am adding more comments, aiming to kick off this thread:

  1. How to organise long routes? This proposal from Najita looks very relevant for EuroVelo routes. I see that it is still a draft proposal. I would suggest to follow how it goes and to aligh with it. When the proposal is approved, we can edit the EuroVelo wiki page accordingly. Any comments, or do you see any issues with this proposal?
    Maybe something to mention is a potential unclarity between OSM and EuroVelo.com. On the EuroVelo website, some routes (not all) are divided into touristic transnational “stages” (such as this one), while the route tracks are divided into “daily sections”, as can be seen upon download of the GPX. But I think that the “stage” tag used for EuroVelo routes on OSM corresponds to daily sections, right? These are of more practical use anyway.

  2. How to tag / whether to tag at all undeveloped EuroVelo routes + distinction between developed as a cycle route but not signed as EuroVelo, and not developed at all. This is where there will likely be unresolved discussions, but we can try to agree on something logical and clear.
    As discussed in the other thread, here we should use specific tags, such as the proposed tag. Here there is also mention of a planned tag. This distinction would potentially allow to differentiate between EuroVelo routes that are actually under constructions, and those that are a proposal of the best option but where no development works are ongoing. I would also suggest not to overdo it and add to OSM routes that don’t exist, as it may be worse than doing nothing. But for the bad routes that are already mapped, it would allow to clarify their status and lower users’ expectations.
    But I believe that we should have a different solution for routes that are well-developed, but just not signed with EuroVelo signs, as is the case a lot in UK and Germany, for instance. Would it is an option to use some kind of “sign=no” tag? But how to do when it is signed at national level (signed as UK NCN or German D-route) but not as EuroVelo? I am not very familiar with the usual OSM logic so I’d like your opinions here.

  3. Clarifying forward/backward issues (mostly cycle routes, but also applies to some hiking routes). I am afraid I cannot help much on this one because on the EuroVelo website, I don’t have the possibility currently to upload different tracks for “forward” and “backward” itineraries. So I cannot provide tracks for the other, “non-official” direction of the route and there will likely be differences between EuroVelo.com and OSM that remain. If someone wishes to work on this, however, and is looking for missing tracks in another direction, feel free to contact me and I can ask our national partners.

Action point: Reaching conclusions within the thread, updating the wiki page accordingly, and starting to make changes to OSM relations where needed.

I feel grateful to @Nadjita for putting together this proposal, and it makes a lot of sense. However, there are a couple of angles that I’d like to see addressed more:

  • diversity of points of view. The proposal is mostly influenced by the needs of people who work on indexing and search engines. We also need to take into account the needs of contributors (making it easy and clear to create such routes), of renderers, and of QA maintainers. For instance, I have observed that so-called simplifications of name tags make life easier for one of these categories using one specific tool, but create a mess for the others.

  • consistency with other types of routes, particularly node networks. I understand that Nadjita has deliberately left them aside, but I fear that this will make our life more complex at the end of the day. Even when disregarding general questions of mental workload (“should I use network:type in this context?”, “in what case do I use the network tag to store the network name?”), there are practical issues that appear when a national or international route is “implemented on top of” node network connections or when it has so many alternatives or access routes that it looks like a node network itself.

  • consistency across practices and even internal consistency. Why are forward/backward sections handled differently for buses and for bicycle? can the solution account for hiking routes that double back on themselves? Can we use the alternative role (or is it alternate?) in the same fashion as forward/backward? Is route_master the same as superroute, or the same as network?

If we don’t give consideration to these questions, we may find that our favorite routes do not receive proper support in applications.

1 Like

I propose to raise questions through practical examples, and to check what we need to add to the proposal and/or other wiki pages once there is consensus on a given example.

As a first practical example I propose EV17:

  • it has two branches in southern France. How do we tag them?
  • it goes through France, Switzerland, France again, Switzerland again. How do we tag this?
1 Like

Second practical example: EV8 stage 24 between Le Perthus and Argelès (6621587) has two alternative routes (9202451 and 16010984) that are currently represented as members of the EV8 France relation (721730) with role alternative. How do we want to represent this?

It is correct that it seems to be influenced by the needs of a search engine, but this is, because the main goal was to find a way to move everything that is currently stored in name=* that doesn’t belong there into proper tags, in order to be able to search for routes via Nominatim.

Everything else that you mentioned, like the controversy between forward/backward, is not related to this goal, so I deliberately left it out of this proposal. My feeling is that if I add too many changes into a single proposal, then the chances of people actually understanding the implications and voting yes is going to be very low. While I fully agree that these things need to be addressed, I feel like it should go into a separate proposal, because it touches more than just walking/hiking/bicycle routes.

That said, I don’t think moving things from name=* into proper tags is going to cause a mess with other tools. Actually quite the opposite. But if you know of any issues that could come from this, feel free to bring them up. I’ll gladly investigate if and how these issues can be avoided and what their actual impact might be. The reason the proposal is still in draft phase not only in my personal space is that I currently don’t have a lot of time to invest into this, but the next weeks should be better for me time-wise.

It’s alternative, and no, this is not the same. I would actually discourage using role=alternative for ways, especially since there can be multiple alternative routes. Instead, I would use them only in super-routes in order to tag a part of the whole route as an alternative route to following the main route. So strictly speaking, I would only use it on relations, not ways. Why am I proposing this? Because a lot of times, these alternative routes are pretty long and a route of their own, and they can (and mostly have) different attributes, like a name of their own, different sac_scale than the main path, different signs, and so on. Personally, I also think it makes routes more manageable, if sections like these go into their own routes. But for shorter/simpler routes, this might seem overkill.

And if anyone feels like they want to help me with the proposal, please let me know. I’ll gladly take all the help I can.

My point on this topic is that it is difficult to talk about relation names without talking about their structure, and it is difficult to talk about relation structure without talking about roles. I don’t remember if was an EVs or an E, but last week we even encountered a route whose stage numbers were stored as role names :smiley:

That is why I proposed EV17 as a first example, because I hope that it will raise the right questions and help us find out if there are things to clarify in your proposal.

Well, that is what examples are made for. If I give you the whole list of issues I have encountered with names as a contributor, a maintainer or trying to customize a rendering, most people will just look away from such a long list, and the rest will ask for examples. Let’s just see what issues come out of concrete examples shared by the whole group, and discuss them as a group.

That is what we are trying to do here: share questions so as to make more informed contributions to the proposal. Sorry if it feels like a step back to you, but it is a necessary step for the rest of us and it will definitely help build a consensus that may last long.

It doesn’t feel like a step back, just approaching the problem from a different angle. Everything that leads to better tagging is good and welcome.

Concerning Relation: ‪EV8 France 01b‬ (‪16010984‬) | OpenStreetMap between Argelès and Le Boulou: For years, the cycleway north of the D618 highway was signposted as “temporary EV8” route while the final route further south was under planning and then construction. In summer 2023, the southern itinerary has been officially inaugurated as the final EV8 route. From my point of view, this means that Relation: ‪EV8 France 01b‬ (‪16010984‬) | OpenStreetMap should be integrated into Relation: ‪EV8 France 01, Le Perthus - Argelès-sur-Mer‬ (‪6621587‬) | OpenStreetMap and replace the temporary section.


Yes, we definitely need a thread about how to proceed with discrepancies, which data is authoritative over which, etc. I have already suggested this to @Florange_Grimoire in the original discussion about the EuroVelo working group.

I would consider those statements:

Don’t map for the renderer (or other data consumers),
relations shouldn’t be too big

I think we should take our time to find the matching pattern for EV routes (and other routes). Analyzing the EV routes will help as showed by your examples.

I try to compile these issues with the wording of the proposal of Nadjita:

  • Every EV route should be a super-relation
  • can have separate main segments at each end (like the end of EV17 from Beaucaire to the Mediterranean coast)
  • can have separate main segments between two points (like the EV17 north and south of the Lac Leman). These can be multinational
  • Main segments should typically be super-relation
  • can have alternative segments (can be multinational)
  • can have connections between two separate main segments (can be multinational) or to another EV route
  • Some segments can maybe classified as excursions or an approach to the main route
  • Segments should (or could) have stages matching the stage parts of the official GPX tracks.
  • The stages can use ways directly or use existing relations, especially if two or more EV routes are using the same ways, like the transition part from France over Germany to Switzerland of EV5, EV6 and EV15.

From my point of view the drafted proposal would cover these issues, if it’s possible to have two separate main segments.

Then there are the multinational branches. Would it be a problem, if some parts will be included two times in the EV super-relation, by the national super-relation and the super-relation of separate main segments? If it’s not, we could use this new structure.

1 Like

Can we try this on EV17?

Ground truth matters :slight_smile:

I propose to use separate topics for every EV* route. There can be EV*-specific discussions, current problems that Knooppuntnet shows and solutions like your post here for EV8.

Maybe we can separate two things: topics for resolving issues on each EV, and threads for addressing “theoretical questions” using practical examples taken from possibly any EV.

1 Like

Of course we can have a try.
I see two different approaches we can use.

  1. Cut and combine the existing relations (of the lowest level) to match the stages of the GPX files.
  2. Create new (duplicate) relations to match the stages without changing the existing ones

In either case the segments will be a new level of relations. We will see the impact when we include the segment relations to the EV17 super-relation.

We should document the tagging by creating the new wiki page of EV17, especially with the use of name and description.

That was my motivation to create separate topics for EV* routes.
If we try the new scheme for EV17, it would be a good idea to create such a topic for the EV17 issues.

I think that such routes should not be mapped or be deleted if mistakenly mapped (ones that exist solely in planning paperwork)

See [EuroVelo&OSM Working Group] EV17

Also see [EuroVelo&OSM Wrking Group] Superroute or not superroute?

See this topic dedicated to the EV8 example.

I have one worry: “Working Group” in OSM context typically means these: Working Groups - OpenStreetMap Foundation

Maybe a bit different name for threads would be better? [Mapping EuroVelo bicycle routes] not [EuroVelo&OSM Working Group] ?

1 Like

I’d vote for something shorter inside the brackets, not something longer :slight_smile:

1 Like