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?

[SomeoneElseOSM]

This bug (and related issues) strikes again - the mapper of https://www.openstreetmap.org/changeset/166688235 added ways to the wrong relation because iD deliberately hid the information that was necessary for them - the relation id.

[tordans]

@SomeoneElseOSM all relations in this changeset have a unique name and list entry in the dropdown of relation options. Given that we already have enough information at hand to pick a unique value, I think we need to focus on improving the UI and flow to make it easier to pick the right, unique option.

[k-yle]

I think we need to focus on improving the UI and flow to make it easier to pick the right, unique option.

this is another reason why we need https://github.com/ideditor/schema-builder/pull/174 and https://github.com/openstreetmap/id-tagging-schema/pull/1538 . With that data, iD can prevent people from adding a member directly to a super route, and limit the relations in the drop-down to plausible values, plus many other benefits

[SomeoneElseOSM]

all relations in this changeset have a unique name

Actually, no.

https://www.openstreetmap.org/relation/5479815 is "EuroVelo 2 - Capitals Route - part United Kingdom 7". It has "from" and "to" information (which iD does not show) a relation id (likewise) and "type=route" (likewise).

https://www.openstreetmap.org/relation/9481976 is "EuroVelo 2 - Capitals Route - part United Kingdom". It doesn't have "from" and "to" information but it does have a relation id and is "type=superroute" (which id does not show).

How is a casual mapper supposed to know that they should be adding to "EuroVelo 2 - Capitals Route - part United Kingdom 7" not "EuroVelo 2 - Capitals Route - part United Kingdom"? The names are virtually identical and useless.

Show the network value. When someone adds a way to a superroute in error don't show the route as "complete".

Show the id so that people don't have to look it up externally and type it in (functionality that exists but is not discoverable - it's not actually discoverable that there is any sort of search there).

[SomeoneElseOSM]

Another example (same changeset, different relation). How do I know which relation I should pick here?

There are actually about 30 relations available. iD's little letterbox shows only a few at a time so scrolling up and down isn't feasible even for experienced mappers.

[1ec5]

this is another reason why we need ideditor/schema-builder#174 and openstreetmap/id-tagging-schema#1538 . With that data, iD can prevent people from adding a member directly to a super route, and limit the relations in the drop-down to plausible values, plus many other benefits

route superrelations aren’t going away anyways, since some kinds of routes legitimately contain other routes, where distinguishing the upper tier as “superroute” would be sort of misleading. For those situations, a Road Route preset needs to be able to express that it either contains relations or it contains ways but not a mix of the two. This should be no more fragile than expressing that a superroute relation can only contain relation members (as seen in this discussion).

Show the id so that people don't have to look it up externally and type it in (functionality that exists but is not discoverable - it's not actually discoverable that there is any sort of search there).

I’m confused about this comment. Can you narrate the envisioned workflow, including how the user would know ahead of time what the string of numbers means? For example, if this relation has “r17669598” at the end of the label, how does the user know it’s the one they want, if they still draw a blank after seeing a bunch of memorable names like “Little Snoring”? Wouldn’t they need to have the relation open externally, in another tab, in order to do that comparison?

There are actually about 30 relations available. iD's little letterbox shows only a few at a time so scrolling up and down isn't feasible even for experienced mappers.

Admittedly, as I worked on #8276, I did not anticipate a fully qualified Nominatim search query being stuffed in from=* and upwards of 21 values being crammed into via=*. I expected brief names like you’d find on wayfinding signs, and via=* only when conventionally included on those signs for disambiguation. This reads more like turn-by-turn directions or a prix fixe restaurant menu. I hope it isn’t the norm in your region.

(As an aside, as a Mac user, I’d love it if iD’s dropdown menus could drop up instead of down when the control is near the bottom of the screen, where it usually is in iD. This is how native dropdown menus work on macOS. But it would look really strange on other platforms.)

[1ec5]

I’m confused about this comment. Can you narrate the envisioned workflow, including how the user would know ahead of time what the string of numbers means? For example, if this relation has “r17669598” at the end of the label, how does the user know it’s the one they want, if they still draw a blank after seeing a bunch of memorable names like “Little Snoring”? Wouldn’t they need to have the relation open externally, in another tab, in order to do that comparison?

Discussion continues in https://community.openstreetmap.org/t/id-visibility-of-relations/138374/11