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):
A sticker from the first stage of marking the EuroVelo 5 route (in France just over the border, please mark the text “Eurovelo” instead of “EuroVelo”)
… and new signs including the EV5 logo.
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):
- EuroVelo 17 (short name, useable in tools and in some maps?)
- Rhône Cycle Route, and its translations in various languages
- EuroVelo 17 - Rhône Cycle Route
- 17 (used in shields?)
- :blue:yellow_circle:17:white
- EV17
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:
- the part between Le Bouveret and Saint-Gingolph is not part of the ViaRhôna (the website doesn’t display it, and we don’t have any data on this section), therefore it shouldn’t be part of any ViaRhôna stage or relation ;
- this same part doesn’t seem to be part of the swiss Route du Rhône (it’s not displayed on the official website, and no stage stops in Le Bouveret), I don’t think it should be part of Route du Rhône stages or relations ;
- I think stages should be cut at borders if there is discrepancies between the two national operators. Here, we have the Route du Rhône website which displays the last stage from Genève to the border. The ViaRhôna website displays a stage from Thonon to Genève, and then Genève to Vulbens. Here is my proposition about it:
- stage Thonon - Genève: part of ViaRhôna relation and part of EuroVelo 17 relation + french operator
- stage Genève - border: part of Route du Rhône relation, part of “Stage Genève - Vulbens of EuroVelo 17” relation
- stage border - Vulbens: part of “stage Genève - Vulbens of EuroVelo 17” relation
- Stage Genève - Vulbens of EuroVelo 17: part of EuroVelo 17 relation and part of ViaRhôna relation
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:
- you are not alone with the need of labels that are not too long (e.g. Waymarkedtrails, OsmAnd)
- short of embedding AI engines in apps, it is not easy to produce a relevant short name from the long name
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?
From my point of view, it’s pretty clear:
ref=17
name=Rhône Cycle Route
cycle_network=EuroVelo
network=icn
(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.
Who are we to decide this, when the operator says otherwise? I am weary of editorial choices that are not prompted by necessity.
Hi @Idrizza , thank you for your great information.
@Florange_Grimoire proposed to use the proposal draft of @Nadjita. This would provide the aptly named tag label
@Richard, what do you think about that new for the future?
I second that gladly.
What about
ref=17
name=Rhône Cycle Route
cycle_network=EuroVelo
network=icn
label=EV17
cycle_network + ' ' + ref would provide the “EuroVelo 17”
Hey!
Thanks Idrissa for your contributions
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.
I think that would be excellent.
Working on it, keep posted
I created a new topic and turned it into wiki to document the conclusions to tagging and structuring the EuroVelo routes: [EuroVelo] Conclusions - Action point "tagging and organising" EuroVelo routes
Incidentally @SomeoneElse proposed to use short_name instead of label
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.)
JOSM relation editor
ID
Waymarkedtrails
Waymarkedtrails, subrelations
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).