I was wrong.
Even if two EV routes are using the same stages for one part, the stage information, i.e. the stage number of the stage in the segment will be different. So it would make sense to map a relation containing the ways (or other relations) and create two EV stages as superroutes with the appropriate stage and ref information just like using a ViaRhôna stage as base for the corresponding EV17 stage.
Additional information from the draft:
Yes, cycle.travel parses the cycle_network tag to help it decide whether a given cycle route deserves a routing uplift. For example, a lot of US state bike routes follow genuinely terrible roads and don’t deserve any uplift: if cycle_network=US:NY (as one example) then c.t is much more cautious about applying the uplift.
Thx. Pity it’s a specific tag, not usable for e.g. hiking.
Do you believe it would be useful to define standard values in Europe? Or maybe there already are?
Edit: and we need to decide whether it must be in stages/segments or can be factored in the superrelation
same in France. But then this raises the question of what osmc:symbol means exactly: what markers are found along the route? what should be on maps? what operators use in their communication materials?
osmc:symbol is only for hiking-routes. Have a look on hiking.waymarkedtrails.org
Some mappers missuse it for other route-types.
If I look at both pictures it is the Logo of the Rhone Route with a small additional EV17 logo in the picture of @nurdafur and that of ViaRhôna with a small additional EV17 logo in that of @StC.
The Rhone Route page states clearly:
At the ViaRhôna page and stage descriptions I did miss such a reference, but I saw that they referenced the R-1 for the Swiss parts
And there’s the need of local knowledge about the small part between Le Bouveret and Saint-Gingolph (6.4 km) too. I’m sure this will be the final form of the EV17 signs, a bit different from other EV routes that I’ve seen, i.e. EV4, EV5, EV6, EV15.
Will it have an impact of the mapping? What do we do with that?
cycle_network=EuroVelo is even documented 
I would use it not only for the complete EV superrelation but also for EV segments and EV stages too.
Back to other questions of EV tagging at the example of EV17:
name
Current mapping for the superrelation of the EV17 is
name=EuroVelo 17 - Rhone Cycle Route
and that is consistent for the other EV routes too. I wouldn’t dream of changing that.
But what about the name-tag of the segments and stages.
@Pyrog is in favour of not using the name-tag, only a ref-tag
The proposal of @Nadjita is using name=EuroVelo xx
ref
That’s the next one. The documented value is
ref=EV17
A value of this form is needed if we don’t use a name-tag.
@Minh_Nguyen has raised a question in the discussion page to that format.
I propose not to change the format, that is well used.
It was designed for hiking routes and horse routes. The same format of description works for other route symbols as well, and was soon used for cycling routes as well. It works fine for other routes as well. No problem. It’s just a format.
iD already displays labels in the form “network ref directionbound from from to to via via”. This format is localizable and may differ slightly in other languages. Do users need the punctuation to match the proposed formula specifically for this one network, or would the existing format suffice?
Currently, iD only generates this label if there isn’t already an explicit name, based on the assumption that a name is already specific enough for the user to roughly identify the relation, even if it isn’t unique among relations in the area.
It looks like you’re all taking on a lot of issues at once. As someone from halfway around the world, I wouldn’t want to scope-creep this effort for something as pedantic as ref formatting, especially if the community is open to refining tags in the future.
For what it’s worth, I do think it’s worth distinguishing between the “core” part of the route number and the overall abbreviation that refers to the route. This enables data consumers to do more with ref than if the value bakes certain assumptions in. The calculus is quite different from way refs, because network normally doesn’t get tagged on ways, and way refs aren’t necessarily machine-readable anyways.
In this case, is it appropriate to call the route “EuroVelo EV17”, or is it just “EuroVelo 17”? If a renderer wants to display a heavily simplified shield for the route due to space constraints, would “17” in a blue rectangle be misleading? If you expect data consumers to include the “EV” prefix in some contexts but not others, then I think it should be omitted from ref so that data consumers can decide to prepend it when appropriate.
That’s very true. I would be content to get the tagging scheme done.
It’s just EuroVelo 17 or the official name is EuroVelo 17 - Rhone Cycle Route, see the official EuroVelo website. All EuroVelo routes have such a name as documented in the EuroVelo wiki page.
Using EV17 as ref could be seen as tagging for the renderer, please have a look at Waymarked Trails - Cycling with EV5, two main branches of EV15 and some local routes including a visible 15. But it’s possible to interpret the symbol of the flag of the European Union around the EuroVelo number as EV part of the ref.
Two pictures from EuroVelo 5 (and I’ve seen the same ones at EV4, EV6 and EV15):
Who knows, this might be a good opportunity to clarify things and converge on a common vision. Here is a tentative list of the “names, references and symbols” that data users may wish to reuse or compute for the superroute (leaving segments/stages aside for now):
Where and how would you say they can obtain them?
A systematic name seems like something that a data consumer could generate in the absence of an explicit tag. This might be useful for the EuroVelo network as a whole, which extends into countries like Serbia and Greece that don’t necessarily spell it as “EuroVelo”. (Edit: Apparently they do, go figure.) If a data consumer can piece together “EuroVelo 17”, it certainly can come up with the abbreviation “EV17” if space constraints require it.
As I mentioned earlier, iD is already concatenating the network and ref into a human-readable label. Currently it’s only including the raw tag value EuroVelo verbatim, but a preset for EuroVelo routes could be added to id-tagging-schema or name-suggestion-index, which would not only make it easier to tag these routes but also enable iD’s translators to provide localized equivalents – even in languages that aren’t spoken locally. You can see the prettified labels today with public transportation routes.
I think the 17 in isolation would prove to be more versatile than the OSMC syntax in the long run, though I recognize that there’s a lot of enthusiasm for OSMC based on the tools that already support it. OSMC’s main problem is that it mixes semantic and presentational details in the same complex tag value, forcing data consumers into a one-size-fits-all situation and sometimes forcing mappers to tag for the renderer en masse.
For example, you’ve chosen here to surround the number in a yellow_circle, which might be the best we can do for some renderers. But what if the renderer happens to display shields at a size that can accommodate a few stars, or even the full complement of 12 stars seen on these signs?
Renderers such as OsmAnd and OSM Americana are drawing highway route shields based on the semantics in network/cycle_network and ref. Turn-by-turn navigation software like the Mapbox Navigation SDK display shields very large on screen. While the renderer can decide when to encircle the number in yellow stars, it ideally shouldn’t also be required to know how to parse a ref key that should’ve been atomic to begin with. (Plenty of routes have letters as a core part of their refs.)
I have no objection to including osmc:symbol for backwards compatibility, but I suggest also tagging the route-specific details on the feature, isolating them into separate tags. This will serve not only some fancier renderers but also editors and potentially assistive technology.
This might be worth a separate thread, but just for your awareness: type=superroute is probably a misunderstanding that took on a life of its own. Currently, superroute relations are common among EuroVelo routes, but it’s always been more common for a type=route to contain other type=routes, particularly with highway routes. Last I checked, there was more software support for “route superrelations” than “superroute relations” (and of course much more support for type=route_master, but that’s limited to public transportation).
I’ll very deliberately not reply to the superroute thing although my fingers itch to do it
Yes, we probably would ideally need something like a matrix of threads: one per EV and one per issue raised. That would probably be a dozen threads for issues and three or four threads per EV example before we address all issues and can generalize to other EVs. The question is whether we can reach consensus on this and makeit work.
Anyway, with the 17 EVs that represent something like 50-100 thousand kilometers altogether, plus the 12 Es that represent an additional 30-50 thousand kilometers, we may have a critical mass for fixing a few historical glitches, can’t we?
Edit: see this new topic about superroute
Hello!
I’m one of the two GIS specialists from the french NECC, Vélo & Territoires (V&T). I took this position at the start of October, so I may make mistakes and not know everything 
I’m rather used to OSM topics though, as I contributed myself and developed some presets for JOSM.
On the topic of EV17/Route du Rhône/ViaRhôna, I won’t react to everything that’s been said here as it’s already a lot. Here are my opinions:
Name:
I believe the full name is “EuroVelo 17 - Rhone Cycle Route”, as stated on the EuroVelo website. I didn’t find any reference to a short code like “EV17” in official ECF/EuroVelo documentation. @Florange_Grimoire could you tell us if short codes like this are used or/and official?
At V&T we use those short codes for national and european routes (V66, V80, EV17, EV3) as labels in our maps (https://www.velo-territoires.org/wp-content/uploads/2023/03/carte-SNV-2023_web_21032023.pdf).
ViaRhôna/Route du Rhône/EuroVelo 17:
Ref:
if Florence confirms that code “EV17” is not used or official, I think that “17” is the way to go. The wiki definition seems to confirm this choice:
Numerical part of reference code of the route. (This formal limit was introduced originally to cater for a certain renderer, so using the full code should be fine too, as long as it can be read from signs along the route.) The network or cycle_network tag already distinguishes the type, so just use “ref” and not “ncn_ref” or similar.
=> 17 is numerical, and the only code found on signs (cf. page 50 of this document: https://www.velo-territoires.org/wp-content/uploads/2022/04/JALRIC-IDD.pdf)
I read two things in this sentence: 1) “short names” or short codes" are needed for labels. Remain to define how short. 2) your choice as a short name or short code would be EV17 rather than EuroVelo 17. Remains to discuss whether these “short names” or “short codes” are better provided by us or computed (from what?) by data users.
I am afraid this sentence is ambiguous Is this a cascading inclusion (the daily section is part of ViaRhôna which is part of EV17)? or is it two parallel inclusions (the daily section is part of ViaRhona on one hand, part of EV17 on the other hand)?
Don’t we need something to tell data users what the ‘17’ is relative to? Someone explained that cycle_network=EuroVelo is documented, does it provide the reference framework?
Corrected! I meant two parallel inclusions.
If a code is not used officially by an organisation, I don’t see why we would provide it. The only instance of “EVXX” in Vélo & Territoires is as a label in soem of our maps, where it graphically and esthetically would be complicated to use the full name “EuroVelo XX”. In all our map legends, articles and communication, we use the full names (mistakes excepted).
If a renderer wants to use a short code or name for graphic reasons, I think it should be their responsibilty to do so with the data provided by OSM.
I think the relationship between the cycle_network and ref tags is the best way to interpret OSM data. Not every network has a prefix, and it is expected that refs aren’t unique database-wise. We shouldn’t put a reference that is not used by the organization itself just so it’s more readable by contributers or end-users.
My point is that:
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.
It makes sense to me. What bothers me though is the ‘cycle_network’ tag name: shall we create a ‘hiking_network’ tag and a ‘riding_network’ tag? Wouldn’t it be better to have a more standard tag name?
