A few hours ago, while editing around the junction of Historic US 101 and La Jolla Parkway. Some portions of Torrey Pines Road were shown to me as “US 101 Hist: Torrey Pines Road.” Turns out that these portions (and many others) were tagged with name=Torrey Pines Road and ref=US 101 Hist. I immediately thought that iD got a new update, but my browser showed it as 2.37.3. I even tried the sandbox, but that name label format didn’t appear again. I even checked GitHub if a new version (e.g., 2.37.4, 2.38.0) was in development, but no: it displayed the latest version as 2.37.3. Does anyone know what might be going on? Thanks.
(Side note: If this does turn out to be just a bug, I would actually like this to be implemented into iD because it would be useful to know which highways are tagged with a ref tag, such as for filling in gaps.)
Edit: It turns out that this only happened for highways tagged with route=bicycle and type=route, both of which are reserved for relations. Now my question is this: Why should a highway’s ref tag appear alongside its name if it’s tagged as a bike route? This confused me, unless it has something to do with route=via_ferrata tagging.
I don’t think that’s it. Those other tags appear if a relation’s name=*, from=*, via=*, and to=* tags are filled out. For example, if a route gets tagged like this:
name=A Route
ref=67I’m so sorry
network=US:I
from=Panama Canal
to=Nuuk
via=I 35;I 35W;I 35E;Trans-Canada Highway
type=route
route=road
direction=north
…Then iD will display this in the relation toolbar:
Road Route US:I 67: A Route north from Panama Canal to Nuuk via I 35;I 35W;I 35E;Trans-Canada Highway
In iD, the map labels have some commonalities with the labels in the sidebar (such as in the relation list or change list). In general, only routes are supposed to have tags like ref=* and via=* tacked on. If it’s a nonroute and it’s named, it’s supposed to only show the name. If the way was incorrectly tagged route=road, then the way ends up getting those extra bits.
In principle, the code could also short-circuit the route labeling code if it’s a nonrelation too. But route=ferry is generally tagged on ways.
This is similar to the request for labeling both refs and names together on golf holes and bus stops:
By the way, way refs are essentially deprecated in the U.S. where you primarily map. They’re there only for backwards compatibility, other than on very minor roads like forest service roads. There’s no problem with trying to plug gaps in a particular route’s way ref coverage, but the route relations themselves are more important.
There’s a longstanding idea to render route shields on the map, based on route relations and data stored in route network presets:
As a stopgap, it might be feasible to label roadways based on the associated route relations. I think the developers have previously shied away from a simple patch to this labeling code, because the number would appear to be coming from nowhere unless you know to look for a relation.
