Yes, that’s what @Minh_Nguyen and @ZeLonewolf are saying and I would honestly agree with them, since that’s not the name in OSM-terms of what should be filled in name.
If you can get some mileage (improve a downstream use-case) with this sort of tagging, I have no problem with it. Though again, do note how all completed USBRs (so denoted in our wiki) have rather carefully-tagged from=*, to=* and via=* tagging. I don’t think this is inconsistent with that, though we may simply “get out of this endeavor” better overall results (of mapping, perhaps of routing, perhaps of display of routes or in a table of routes…) with that additional tagging, regardless of the completeness of any particular single USBR in the grand scheme of the completion of the System.
One thing I have noticed that this “naming convention” does is to present lists or tables of routes (for example, Lonvia’s cycling.waymarkedtrails.org route list when the “Routes” button is clicked) with completely unambiguous route list presentation.
If you have a way to “make that happen” in a similar way (or an argument against the convention helping this, like “that’s not how the name=* tag should be used”), I’m listening. Otherwise, we’re back to “how do we disambiguate a USBR numbered 50 in California from one in Nevada?” (In a list of relations with, say, ref=50).
I think what is being proposed is a newer convention to replace one we’ve used for 13 years.
Exactly, this is what this discussion is about. How can we formalize the “state” and the “(super)” in a way, that tools can make sense out of it. Eg. by not showing 10+ entries for USBR 50.
The approved formal tag for (super) is type=superroute, though it turned out in this discussion, that it might be not a good fit and is causing troubles.
For the state, it seems in the US road routes, is_in:state is used. See: Planned edit to re-tag descriptive names in road route relations in the United States
Yet, that’s what it is. It is syntactic sugar that is a (relatively long-standing) convention in OSM’s implementation of the USBRS.
As you have stated, others agree that it isn’t “strictly Kosher.” Yet it is an existing, documented, long-standing convention.
I don’t want to sound antagonistic by saying this, but “your move.” By that, I mean that I hear (loud and clear) that you might like to see something different than this convention going forward. And by “your,” I mean “the wider community, you, me, all of us.” So, really, “our move.”
Yet, I’m not sure what that next move might be. But I think we have at least better-characterized some of the shape of what some people don’t seem to like or want to see changed. That’s progress, I’ll take it. Steady ahead, fellow mappers.
The original usage of is_in=* as a geocoding crutch is obsolete and I would never try to revive it. I reached for is_in:state=* because it’s extremely common, appearing on 7,673 route relations in the U.S., typically as a disambiguator. But now that you mention it, pages such as “Interstate Highway relations” have always recommended addr:state=* instead, yet only 56 route relations have that tag. I wonder if that was a mistake, or if usage shifted at some point but we never updated the documentation.
In my opinion, address tags don’t belong on roadways. At least is_in:state=* is more accurately named. It’s like how streets are still routinely tagged with postal_code=*, not addr:postcode=*.
That said, a good chunk of USBR 95 in Alaska is not actually in Alaska – it’s in British Columbia! But I could imagine addr:state=AK confusing a geocoder all over Vancouver Island even more than is_in:state=AK would.
I’m aware, but public opinion has definitely soured on stuffing disambiguators and other supplementary details into the name=* of any kind of route relation. I’d think this would be especially relevant to bike routes, since so many bike routes have real-world names.
@lonvia has repeatedly pleaded for the community to stop putting descriptions in the name=* tags of route relations. She’s not alone. Until we clean up the names, Nominatim and other geocoders won’t index route relations. There’s too much of a risk that the disambiguators would interfere with searches qualified by state name and so on.
1 Like
Awesome, Minh. I’d like to nod my head (and largely do), but I’m not sure “at what” (I would be nodding, right now).
If/as we have an outdated convention regarding putting the name of a state (parenthesized) in addition to the USBR # into the name=# tag of a USBR, again, I’m listening to any proposal that aims to solve this.
And in my own defense, I pedal as fast as I can — and did so as I started the convention of using the name=* tag like this back in 2011 or so, though when something better comes along, I’m happy to “switch seats.” Though, I can’t quite see the other vehicle to jump to right now.
Edit (1): The linked proposal was last touched a couple of years ago, I’m taking a look now.
Edit (2): It seems a reasonable proposal, though remains a two-year-stalled draft. What’s next?
Mmm, were we to get technical (either with international-ness / maritime law / maritime boundaries OR the linguistic aspect of locative case), we might say certain portions of USBR 95 are on a ferry which is in, or better stated, through either British Columbia, US waters or international waters — I’m not precisely sure exactly which the whole way — traveling as an interstate common carrier between two US states, Washington and Alaska). Not in, through.
But, honestly, I don’t think being quite that pedantic really helps.
On the other hand, revamping how the USBRS uses name=* tags, I’m listening. If somebody were to put this into plain language for the specific case of how we might do that (differently than a 13-year-old convention that seems to be wheezing its later-years dying breaths), I think that would be helpful. Is it as simple as using description=*? What then becomes of name=*?
I would advocate moving these to description and removing the name tag. Similar to US Interstates, for example, I-95 in Maine.
See this post from January, when I took up arms against descriptive names for US Interstates, and the ensuing discussion thread.
OK, I’m sold. Do we have any volunteers to make these changes to the dozens (and dozens) of USBRs? Are there those who are requesting that I budget some time for this task? (I’m not saying that’s impossible, though I am saying it’s the holiday season and my December calendar would need to have some now-planned-and-scheduled tasks juggled around).
description=* already exists, so there’s nothing stopping us from using it. There’s also no general requirement to tag name=*. If the route is only known by its route number, then cycle_network=* and ref=* are sufficient. That said, some would apparently argue for a systematic name like name=U.S. Bicycle Route 50, which is a bit different than what we’ve been doing in these USBR relations.
I believe this is my personal record for # of posts on a single topic in a single day.
And, thanks to everyone else here who has posted with aplomb, patience and excellent persuasion, reasoning and top-cited references.
1 Like
I might be dumbing this down, but I think it’s as simple as a sparse overpass query into JOSM, and then editing the tag key to change them in bulk from name to description. Might have to deal with some corner cases but…seems straightforward?
Doesn’t seem dumbed-down, though…tricky word there: “seems.”
I can more thoroughly begin to take a look at this, mmm, say mid-week. If anyone else wants to throw a shoulder into this, please step right up (by saying so here and now or soon). Henning?
I might also want to toss a pebble into what Sarah / Lonvia does in waymarkedtrails and see how it more-widely ripples. There is also updating the wiki, but that isn’t usually difficult or tedious.
Just to be clear: it seems the community has prompted me / is prompting me to do a mechanical edit (as described).
If you (you, yourself) would like me to do this (and have been reading this topic, are a participant in this topic…), please offer me a thumbs-up to this post. Thank you (in advance).
Once the ink dries on this discussion, I can create the six statewide superrelations that are currently missing and help with retagging. Refactoring bidirectional relations is a bigger project that would take more time and care.
Maybe I missed “the six relations” (if they were specified earlier). Which six?
These are the six routes for which the nationwide superrelation contains multiple relations from the same state:
These are all routes which are either unidirectional (as noted in the wiki) and/or were edited (relatively recently) by @aighes (and had their name=* tag modified) and/or were (very recently) edited by @Minh_Nguyen. It concerns me that we got here because of @aighes’ editing (did or does he misunderstand something or not read existing wiki?) and that this is (largely) about unidirectional routes (like maybe we’re not communication very well how we should be doing those).
I can see what the intent is, I can see what the “more correct direction to tag according to the community” is (use description=*, not name=# (State) to describe the name of the state the segment is in) and I can see that for these six relations, that tagging is “underway already.” (“Breaking” the rule we have described in the wiki).
Minh, I’m not sure what you mean by “due to cardinal directions,” (as I don’t see any explicit north, east, south, west tagging anywhere on these).
Though, if I’m being asked or prompted to do something (like a moderate mechanical edit that changes 13 years of tagging precedent, which I now do agree is a good idea), I’d have to be quite clear on what that is. Brian has made it “seem easy,” and indeed it could be as simple as a JOSM-based OT query that migrates name=* values to description=* values. Yet, there also seems (something?) more to it than that. What am I missing?
I definitely feel my usual “if I’m going to do a mechanical edit, I really should give it my best, hard think about doing it exactly right and avoiding negative consequences.” (So I’m giving myself a couple days to think about it, in addition to finishing tasks I have already scheduled for myself in the next few days).
Minh, “the ink seems to be drying,” but I’m not sure what my role is. (Thanks for your continuing assistance).
This isn’t terribly technically difficult, though does feel a bit “socially / community difficult.” (At least for me, though as a community, we seem to be doing OK with this, if a bit tediously).
You guys might be interested in having a look at knooppuntnet as a QA tool for long routes. We have experimented it with Eurovelo and it helps, even though there are remaining glitches.