Washington State Route name and ref tag changes

For what it’s worth, I think the standard should be what the public uses formally rather than conversationally. In any state where numeric conflicts are rare, people will tend to drop the qualifiers in conversation, because that extra context is unnecessary. I don’t think this should necessarily dictate our tagging. By analogy, people habitually refer to “Main Street” to just “Main”, but we still tag “Main Street”.

Thanks. :+1: The reason I brought up public usage is because some state transportation departments have their own internal designations, or their official designations haven’t caught on with the public at all. A good example is California’s “SR”, which is official but probably confuses motorists whenever they see it on a rare sign. Few Californians even know they’re called “State Routes” as opposed to “Highways”.

These photos of dynamic message signs show that WSDOT expects motorists to understand “SR” in situations where they must post the route number as plain text.

Although MapQuest Open was the main driver of the state postal abbreviation adoption in OSM, some other data consumers later introduced dependencies on these specific abbreviations. Here are the ones I know of:

  • Mapzen’s house styles chose state-specific shields based on these abbreviations. Mapzen itself is defunct.

  • The Mapbox Directions API can optionally return a state-specific image based on parsing a prefix out of a way ref. This image is meant to be displayed in the UI alongside the name of the upcoming exit. Generic prefixes like “SR” are supported, at least in some states. Anyways, Mapbox has introduced a newer API that no longer distinguishes between states. Only the iOS version of the Mapbox Navigation SDK still uses the old API, as a workaround for the lack of state-specific shields in the new one.

  • Valhalla expands postal abbreviations into full state names in guidance instructions meant to be read aloud by a text-to-speech engine. Fortunately, it also supports the generic “SR” abbreviation. If you think “state route five twenty-seven” sounds better than “Washington five twenty-seven”, then “SR” is your prefix.

Some other data consumers like OsmAnd and Mapbox Streets also match known way ref prefixes to choose shields, but they don’t care whether state routes are tagged with state abbreviations or something generic like “SR”, because ultimately all the state routes get the same generic shield.

Indiana’s experience makes me optimistic about a smooth transition. Usage of “IN” went from zero around 2012 to 65% in 2014 to 91% in 2019, but “SR” never completely went away, especially in the southeastern corner of the state. A given route would switch back and forth repeatedly, which was bad for everyone. With an admitted bias for “SR”, I manually fixed all the inconsistencies in southeastern Indiana by changing “IN” to “SR”. I tried to start a conversation about aligning on a single prefix across the state, posting on this forum, the wiki, and Slack, but the only response I got was that, soon enough, another local mapper finished off the rest of the state while I wasn’t looking.

I’m unaware of any serious fallout in Indiana over the past five years, other than the occasional out-of-state mapper getting confused and reintroducing “IN” haphazardly on some exit ramps. We’d need to update the route shield field guide, which mapping teams rely on as training and reference material, and a few other pages around the wiki. Otherwise, I don’t think there’s a great deal of risk compared to other kinds of tagging changes. After all, just about every renderer that varies shields by state already supports route relations. But moving off the postal abbreviations would send a clear signal to developers that they shouldn’t create something new that tries to parse way refs, even for something more predictable like an Interstate or U.S. Route.

5 Likes