Render `network` value in the label of route relations

[SomeoneElseOSM]

URL

No response

How to reproduce the issue?

Edit https://www.openstreetmap.org/edit?node=6501780798#map=20/53.63343/-2.33433 in both iD and P3. Note that one provides rlevant information (ref, route type etc.), the other does not. Note that this is in addition to the non-display of relation object IDs in iD, but there are numerous other issues for that. The first screenshot is iD, the second P3. The iD picture takes up far more space on screen but most of it is wasted by long words such as "Bicycle Route" and the name (which isn't unique). Omitted from the iD display are useful information such as "what sort of route is this - local, regional, national?" and "what is the reference number?".

Screenshot(s) or anything else?

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.29.0

Which browsers are you seeing this problem on?

Firefox

[1ec5]

• A bus route is labeled “Bus Route” when there isn’t a more specific preset to display. 472 and B1 are tagged network=Bury. This doesn’t correspond to any entry in the name suggestion index. In fact, if I’m not mistaken, there’s no such network as “Bury”, only the Bee Network. Please open an issue in the osmlab/name-suggestion-index repository about adding this network.
• 6 and 91 are labeled “Bicycle Route” because NSI doesn’t have any presets for specific cycle_networks yet. This would be a natural outcome of osmlab/name-suggestion-index#4768. Once that happens, cycle_network=UK:National Cycle Network would result in “National Cycle Network” replacing “Bicycle Route” in bold, leaving some room for the route number. In the meantime, maybe the three-letter acronym network values could have their own presets, such as “Regional Bicycle Route” for network=rcn. If you agree, please open an issue in the openstreetmap/id-tagging-schema repository.
• Additionally, 91 has a name tag, so the feature label uses that tag alone without considering any other tags. #8559 tracks including other keys like network and ref as well. #8707 would’ve implemented this enhancement, but it got flamed by devotees of PTv2 ASCII art.

[tyrasd]

@SomeoneElseOSM You linked this issue in https://www.openstreetmap.org/changeset/155217400, but I don't really see how this would have helped in that case: Both relations are tagged essentially equally: type=route + route=bicycle + ref=13 + colour=red + network=ncn, and notably, the "superroute" is not tagged as type=superroute, but just type=route. Yes, iD could label route relations a bit better (starting with #8559), but I don't necessarily see how that would have helped in this case. If the routes in question would have been tagged according to the documented practices, there would have likely been less confusion:

[tyrasd]

Omitted from the iD display are useful information such as "what sort of route is this - local, regional, national?" and "what is the reference number?".

For the ref, there is already issue #8559, so the remaining suggestion is to also show the network tag, which should also be possible. (I'm changing the issue title to make the scope of this feature request a bit clearer.)

[1ec5]

If the routes in question would have been tagged according to the documented practices, there would have likely been less confusion:

The page you linked is about the practice of nesting relations inside other relations, originally about nesting route relations inside a route relation. superroute is the result of some confusion in a JOSM ticket but has taken hold for European cycling routes; that convention is documented elsewhere. The only reason there would’ve been “less confusion” with superroute is that we don’t have a dedicated preset for superroute, but @SomeoneElseOSM has noted elsewhere that the generic “Relation” preset is also confusing to inexperienced mappers.

[SomeoneElseOSM]

On naming of route relations - people really shouldn't be making up descriptive names to satisfy iD, or JOSM, or anything else. https://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only should apply. As an example, I'd suggest that the names of https://www.openstreetmap.org/relation/4087636 and https://www.openstreetmap.org/relation/4080347 are correct and https://www.openstreetmap.org/relation/4086931 is wrong. The first of those has "from" and "to" in it so it's perfectly clear which part of the whole relation we're talking about. See also https://community.openstreetmap.org/t/proposal-use-description-instead-of-name-for-route-relations/104656 , from which I think the consensus broadly was to follow "name is the name only", with the possibly exception of PTv2 routes (see https://wiki.openstreetmap.org/w/index.php?oldid=625726 , which has some made-up stuff in some name fields).

[tyrasd]

The only reason there would’ve been “less confusion” with superroute is that we don’t have a dedicated preset for superroute

Well, ideally we would also add a preset for type=superroute relation, then they would be shown in iD as e.g. Route Collection 🔴 NCN National Route 13.

superroute is the result of some confusion in a JOSM ticket

Oh, I wasn't aware that there is some backstory here… :see_no_evil:

From my point of view, tagging these "super" relations also as type=route is quite a bad practice, as it leads to situations where an editor cannot easily (i.e. without falling back to fragile heuristics) distinguish them from "regular" route relations.

people really shouldn't be making up descriptive names

Agree :relaxed:

---

Ok, should we try to summarize what could be the best for iD to do:

• Basic routes: what we currently do is probably fine, maybe add ref inside the color circle for consistency: <route-type> (<ref>) <name>
• superroute relations would not be offered in the membership editor dropdown of a way or node entity
• when there are two route relations with the same route type and name (which would for example be the case for consecutive sections of a very long route): add from/to or direction tags to distinguish them: <route-type> (<ref>) <name> (<from> → <to>) or <route-type> (<ref>) <name> (<direction>)
• when there are still two equally labeled relations: append their OSM id to disambiguate: <route-type> (<ref>) <name> … (<osm-id>)

I'm not quite sure yet how we could best incorporate the network tag into this approach, for example to distinguish a local from a potentially similarly named national route. Creating dedicated presets for each value would technically be possible, but would also lead to quite long prefixes (e.g. International Bicycle Route …), which would be somewhat counterproductive. :thinking:

What do you think?