For stages this is true, but whole segments, I just don’t know. But it’s not impossible.
Maybe ref=EV6;EV15
Looking at a ViaRhôna stage that is identical to a EV stage. I wouldn’t modifiy the ViaRhôna stage and create a stage for EV17 with the EV-tagging and the ViaRhôna relation as single member.
Another option could be to avoid using ref in segments and stages, and leave it to superrelations.
We could see in WMT that “EV1” is displayed twice (in ref and in osmc:symbol) for each stage.
If we remove “EV1” from ref in stages we should logically remove it from osmc:symbol ?
Also if we search “EV1” in WMT, it display 21 stages and not the main relation itself.
If we keep it from osmc:symbol, we should have two values for this tag in the EV6 / EV15 example ?
osmc:symbol=:blue:blue:EV6:white;:blue:blue:EV15:white
No software support multi values yet for osmc:symbol key 
Either a name or a ref is needed to have a display name, see
If using a name (for stages or segments) no stage information should be included. If I understand @pyrog correctly we should only tag the stages and segments with ref but not with name.
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
