Utah State Highway Ref Tagging

How should Utah’s state highways be tagged? (ref=*)

  • UT 123 - Someone out of state would consider it a Utah state highway. This wiki page says UT. The vast majority of Utah’s highways are tagged this way.
  • SR 123 - The state of Utah refers to them as “state route” or “SR”. Requested by a couple of notes
  • SR-123 - This wiki page says it should have a hyphen.

As far as I know, physical signage doesn’t say either. Just the number in a beehive. (image)

Overpass Queries for stats

(counts in meters)

This discussion is probably better categorized in the US regional subforum: United States - OpenStreetMap Community Forum

2 Likes

Like most states, Utah doesn’t include any prefix on its state route shields. However, the format “SR-123”, with a hyphen, is the norm on signs in plain text and also in published documents. UDOT is very consistent in this matter, and I’m pretty sure that using “UT 123” would reliably mark you as an out-of-stater among longtime residents.

Cedar Breaks Road / SR-148 (148 in a beehive) Open to Brian Head; SR-148: Cedar Breaks Road Closed To Vehicles Over 26,000 G.V.W. 18 Miles Ahead

SR-92: Narrow Switchback Road Next 20 Miles, Not Recommended For Vehicles Over 20 Feet

Minutes To Park City Via SR-224: 10, Via SR-248: 12

Originally, the U.S. community tended to format ref=* on roadways according to the DOT’s preferred abbreviation, such as on signs, except that hyphens were replaced by spaces to match British tagging norms. State routes in Utah were tagged ref=SR *. However, some mappers preferred a uniform national format of ref=XY *, where XY is the state’s USPS abbreviation. Traditional GPS vendors such as Garmin and TomTom had long used the “XY-123” format. Some in the roadgeek community also prefer this format in writing, for consistency and to avoid having to clarify the state separately when remarking on new road construction or bragging about the roads they’ve traveled.

After the OSM-based MapQuest Open map was released in 2010, there was a push to institute postal abbreviations nationwide. At the time, MapQuest was the most prominent commercial user of OSM data in the U.S. Their renderer was the first to display realistic state route shields in each state, but to do so, it required each way ref=* to begin with the state’s postal abbreviation. By contrast, other data consumers such as Mapbox geocoded roads to distinguish between different states’ route networks.

Mappers in most states went along with the postal abbreviation format, but there were a few holdouts in some states with active local communities, especially Michigan and Ohio, based on real-world usage. (Indiana later went back to the “SR” format.) Tennessee and Virginia also distinguished their primary and secondary state route systems using the postal abbreviation and “SR”, respectively, but out-of-staters usually missed this nuance.

MapQuest Open was discontinued in 2016. By then, the U.S. community had reached a clear consensus that route relations are the preferred representation of a highway route, since the network=* tag on a route relation allows us to encode the route network without any ambiguity. Unfortunately, it wasn’t until 2022 that the OSM Americana project released the first viable reference implementation of realistic state route shields based on route relations. In the meantime, the MapQuest-influenced format has become entrenched in the database. Out-of-state mappers sometimes haphazardly insert postal abbreviations in states that don’t use them, thinking there was an oversight.

On the talk-us mailing list and OSMUS Slack, mappers have often argued that we should do more to encourage data consumers to choose route shields based on route relations instead of parsing way refs. In my opinion, an effective way to nudge data consumers would be to restore way refs that match real-world usage – e.g., ref=SR-* in Utah. This would make it clear that way refs are meant for human readability in plain text, not machine readability. Eventually, we could eliminate way refs altogether, but I think this approach would do more to communicate “deprecated” to mappers and data consumers than any documentation on the wiki ever could.

7 Likes

Thank you for that context! As you might guess (since I composed the two notes that Xvtn cites) I think the displayed thing in the openstreetmap.org map should be “State Route” and “SR,” whether that’s the name tag or the ref or short_name or other. That’s the terminology in Utah Code, and on street signage, and what UDOT always uses. In general, I don’t think OSM should make up different names for stuff (and I also agree with the more elegant rationale of the previous poster).

1 Like

Oh hi @keithalleman !

I have nothing to add other than that there’s stretches where a state route has street name signs like SR-24 or similar. In that case, and only in that case, I sometimes put what it says on the sign in the name tag but I don’t have a great heuristic when I do or don’t do this. And perhaps I shouldn’t do this?

Image from Mapillary

2 Likes

“SR 24” is either an abbreviated name, which some would write out as name=State Route 24, or it’s a route number, which belongs in ref=* rather than name=*. If you’d hesitate to put it in ref=* because of the UT prefix, I think that’s one more argument against the UT prefix.

I’ve been doing edits in Washington, ran into the same issue. All the signs here and listings on the WSDOT website use the SR prefix, but the roads are tagged with “WA”. Seems like the labels should match that format.

2 Likes

Sorry for the double reply, I just thought to try simulating some navigation with OSMAnd. The navigation instructions said to turn on to “WA XXX” which doesn’t match any real world signage. It makes more sense for the tags to match the real world names that are on the signs and state DOT websites.

1 Like

Some recent back-and-forth edits between “TX” and “SH” prompted a conversation about which one we should use going forward in Texas. If you think Washington would benefit from this kind of discussion too, a good first step would be to start a new topic and put together a few examples with links or photos.

1 Like

FYI I made a table to collect the results of all this discussion:
Feel free to update/edit as necessary.
User:SD Mapman/United States/State-Specific State Highway “ref” Tags - OpenStreetMap Wiki

1 Like

Good to have it collected! But what does “community accepted” mean? Perhaps a “current existing majority” column would be good too… I could add it tomorrow when I’m back at a computer.

1 Like

Fine by me, was just trying to make somewhere where we could dump the results of these discussions in one place.

Oh I use the local names as “name” all the time. I would never change the name tag for, like, State Street or 700 East to be “State Route NN.” But I put the “SR-NN” in the ref tag for those. My rule of thumb has been to make the name match what a traveler would most usefully want to know right as they were approaching the very thing being named.

To add my two cents here, as a local before getting involved with OSM, I recognized both SR XX and UT XX to refer to the same thing. Personally, I agree with the previously mentioned roadgeeks for preferring XY-123 for convenience in uniqueness, but I will concede that if UDOT is already consistent in using SR, we should switch to that.

I’ll also note that similar to the picture that mvexel shared, I’ve put similar values to ref= in name= thanks to usage on signs and addresses, such as ref=UT 117 name=Highway 117

Not to revive a dead topic after checks date a year (yikes), but since this thread was started I’ve been paying more attention, and have found like Minh originally said that if the beehive shield is not used, “SR” is consistently used (although the dash comes and goes).

It doesn’t really look like anyone was originally opposed to SR. Therefore, unless someone speaks up in the next week I’ll take JOSM and start converting them all to “SR XX”, one route per changeset

2 Likes

Thanks for following up. It’s so easy to lose track of discussions like this after the initial burst of activity. I don’t have a strong opinion on the hyphen – even if I did, the format for Interstates would be a bigger fish to fry.

Remember to update the wiki based on the new consensus. Here are the pages that come to mind, though there may be others:

Mapbox will be affected by this change. They do some custom processing to associate “UT” refs with Utah state routes in their vector tiles. The Mapbox Standard style will start showing a rectangle with the “SR” prefix instead of the beehive shield:

For reference, OSM Americana has no problem, because route relations don’t require ref=* content sniffing:

Mapbox correctly handles the “SR” prefix in Ohio but not in Indiana (which reverted to this prefix in 2018), so they have the capability to handle it in Utah too. There’s probably a regular expression buried somewhere in their SQL code that they’ll need to update.

At this point, if a renderer is selecting state-specific shields based on the old regular expression trick, we should consider it technical debt on their part and urge them to upgrade to route relations. But at least Mapbox is scoping their pattern matching to specific states, so I gave them a heads up in Slack to update their heuristics. Some other renderers may also be affected, but I couldn’t tell for sure.

It might also be worth taking a look at addr:street=* values along Utah’s state routes. Street addressing is famously more flexible than OSM tagging, but the the “UT” format in that key is probably influenced by the ref=* tags you’re changing more than by any particular adherence to on-the-ground or postal usage.

1 Like