Talk:Route directions

Rewrite and reversal

I started a rewrite at User:Minh Nguyen/Directional road routes that incorporates lessons learned over the past several years, in particular the debates I've rightfully lost against developers of routers and editor plugins. 😅 The immediate motivation is some of the concurrency work that ZeLonewolf is undertaking for United States/Map style. Unlike this current article, the draft rewrite recommends sub/superrelations with direction=* and only describes relation roles as a historical convenience. For better or worse, the relation roles only gained traction in the database itself but not in any editor or QA tools and only barely in routers. The draft also addresses cardinal directions in highway entrance and exit ramp destinations, which were still largely untagged by the time the original article was written. – Minh Nguyễn ^💬 10:53, 6 July 2021 (UTC)

After receiving no feedback on the talk-us list but some positive feedback in OSMUS Slack, I've gone ahead and replaced the article with the rewritten version. Please consider it just one more iteration of the article; further improvements are of course welcome. – Minh Nguyễn ^💬 06:32, 31 July 2021 (UTC)

Is there any explanation on how direction=* came to be used? Especially using lowercase words, instead of the usual abbreviations.

As a further note, carriageway_ref=* is inappropriate for quadruple carriageways (US "dual-divided") as local-express when the same direction has multiple carriageways.

I don't like encouraging Tagging For Editor by inserting descriptive name=*. I know you have made https://github.com/openstreetmap/iD/pull/8276, so the solution is for JOSM to add this. Otherwise the name is cluttered.

---- Kovposch (talk) 11:51, 31 July 2021 (UTC)

@Kovposch: The spelled-out keywords have always been around, going back to the key's approved proposal. But I'm unsure how the spelled-out keywords came to be much more common than the abbreviations. [1] U.S.-specific wiki articles have never specified the format of direction=*, only that it could be used. Some of the original directional route relations were using abbreviations, such as NB/SB I-5. (At the time, I was advocating for the role-based method but have since soured on it.) My guess is that people were already using the same spelled-out keywords as roles and kept them when migrating to unidirectional route relations, since they look more like normal tags than the uppercase abbreviations.

OSRM and Valhalla, possibly the only consumers of route directions, only recognize the spelled-out keywords when tagged in direction=* on a route relation. [2][3] There are also some examples of inner and outer directions in the U.S., which are incompatible with a single-character format.

I only mentioned carriageway_ref=* for disambiguation, but it's confusing, so I've relegated it to the "See also" section.

I'd love for JOSM (and openstreetmap-website) to incorporate more fields into relation labels. I've been testing the waters with iD first, waiting to receive feedback before moving on to other tools. Power mappers don't use iD as much for relation editing, so the stakes are lower. Apparently JOSM has a relation template feature intended to solve this problem, but I'm unfamiliar with it and uncertain that a mapper would likely set one up. [4] In the meantime, the article brings up the idea of redundant name=* tags so that mappers don't get complaints from JOSM users if they start creating unnamed unidirectional relations.

 – Minh Nguyễn ^💬 00:58, 1 August 2021 (UTC)

Huh, the original proposal limits "A simple cardinal direction can also be stated as a single English word in lower case: direction=north/east/south/west. It should be treated the same as the usual cardinal direction, looking only at the first letter of the word. No complex directions (north-east and such) are allowed in this form. ". So this is not entirely reliable. I see there are some objects and members non-compliant by using diagonal direction in words.

I worry the "abuse" of name=* for labels will become a liability when applications try to display the name. They may not be incentivized to support the proper tags on top of the already lengthy name=* for redundancy and UI reasons.

For editing, recently I became irked when JOSM shows the note=* in the absence of name=*. This makes me think whether it is easy to show these other tags, or at least the description=*. Would it be acceptable to abuse note=* as a label to satisfy JOSM users?

Ideally there should be a eg label=* tag to store this to help applications not supporting new tags. But then this is akin to a chicken-and-egg situation.

Should the proper name be put in short_name=* or official_name=* in the mean time if you want to do this?

---- Kovposch (talk) 09:10, 1 August 2021 (UTC)

I've seen some examples of description=* being used to disambiguate relations, but the overwhelming practice in the database is to make name=* descriptive. You aren't the only one concerned about the practice. This rewrite by itself wasn't intended to change existing tagging practice, so I nodded to descriptive names but look forward to deleting that bit in the near future. I think descriptive names were being tagged on U.S. route relations even before they became codified as part of the public transportation tagging scheme, a situation we're only beginning to reverse now. It's probably best not to recommend other tags for the proper name: the more we insist on proper names going in name=*, the easier it is to argue for the removal of descriptive names as we move away from these editor-centric workarounds. I like the idea of an editor-centric "label" tag, though it should only be a last resort for relations that are difficult to describe with other tags. (For example, this subrelation almost required is_in:township=*, which would be very unlikely to be supported by any editor.) A label-like key should probably be named something else to keep people from thinking of it as a sanctioned outlet for tagging for the renderer (also a problem with label). – Minh Nguyễn ^💬 17:36, 1 August 2021 (UTC)