Highway shields, state by state

Posted by Minh Nguyen on 25 July 2016 in English (English). Last updated on 22 July 2022.

With State of the Map U.S. still fresh on everyone’s mind, let’s revisit a favorite topic among many U.S. mappers: highway shields. We’ve been talking about ways to improve the sorry state of route shield support across the OSM ecosystem since at least 2011. We haven’t yet reached the vision outlined by Richard Weait in that SotM talk, but things aren’t as bleak as the renderers may let on.

In America, things are complicated

The national standard for U.S. state route markers is black numerals in a white oval. But almost every state eschews this oval in favor of its own design. (Some states have several, depending on the type of road.)

State highway shields by state (Chris-T)

In most states, the marker consists of a number in a distinctive shape, possibly with color:

Kansas state highways, such as K-10, are indicated on signage by a yellow sunflower, the state’s official flower. (Steve Alpert)

By adopting these various designs, maps can optimize usability for motorists. While driving, one should be able to compare the route shield the navigation application is displaying with guide signage up ahead, without having to know the ins and outs of the local road network. Getting the iconography correct is important because the same route number on a different shape may lead you in a different direction.

SR 562
Ohio state highways, such as SR 562, are indicated by the state’s simplified shape. (allen, CC BY-SA 4.0)

Regular expressions to the rescue?

Unlike most OSM-based maps, the recently departed MapQuest Open layer included different route shield designs for each state. But it relied on a fragile assumption that the way’s ref tag had to begin with the state’s postal abbreviation, e.g. ref=KS 10 in the example above. Parsing a way’s ref tag is suboptimal for various reasons:

  • There are known conflicts with other countries and other countries’ political subdivisions. For example, ref=CA… occurs in both California and the Cantabria region in Spain. ref=NH… occurs both in New Hampshire and throughout India.
  • Some states have multiple statewide route networks. Texas famously uses 12 distinct shield designs for state-level routes, and several of these networks overlap numerically. The postal abbreviation isn’t enough to distinguish one network from another.
  • Many states have county, township, or even city routes with distinct markers. In Ohio, each county has its own design, and within many of those counties, there are a variety of township route marker designs. A generic prefix like CR or TR is insufficient for selecting a suitable marker image, yet fully qualifying the jurisdiction on every way (ref=US:OH:MRW:SouthBloomfield 190) would also be tedious and error-prone.

In some states, the highway department doesn’t use the state’s postal abbreviation when abbreviating route numbers, nor do most residents in writing:

Ohio uses “SR” on variable message boards where a pictograph would be infeasible. (ODOT)

In Ohio, the consensus has been to tag ways with the “SR” prefix and rely on route relations for disambiguation. Some other states have similar practices. Unfortunately, this approach caused the state’s routes to be marked with the generic oval instead of the state’s shape. MapQuest Open is no longer available on, but the need to choose state-specific shields remains common among renderers.

For years, members of the U.S. OSM community have promoted an alternative, more flexible tagging scheme for highway routes: the ref and network tags on route relations. In 2013, Phil Gold developed an experimental “shield renderer” to demonstrate how a renderer might make use of this data:

The OSMUS shield renderer supports a variety of shield designs as well as route concurrencies.

But making use of route relations is a difficult problem for production-level consumers of OSM data, so parsing ways’ ref tags remains the most common approach to selecting route shields, despite the disadvantages above.

“Perl Problems”, xkcd (Randall Munroe)

A baby step using spatial queries

When I’m not mapping speed bumps and backyard swimming pools for fun, I work at Mapbox on the open-source Mapbox iOS SDK and the Mapbox GL renderer that powers it. Mapbox GL renders Mapbox Streets vector tiles, applying a stylesheet designed in Mapbox Studio.

The style language used by these tools doesn’t yet support regular expressions, so the vector tiles can’t include the raw way refs for the renderer to parse. Instead, when an OSM way is baked into a vector tile, a spatial query determines the relevant ISO 3166-2 code (the country code plus the postal abbreviation), which goes into an iso_3166_2 field.

This field makes it possible for anyone to create a map that includes state-specific route shields. To prove it, I used Studio to create a custom style, Interstate, based on the default Streets style:

With a regular expression–based filter, a conventional renderer would be unable to distinguish between Ohio and Indiana state route refs.

I wanted to get back to armchair mapping, so I only customized the shields for Ohio, Kentucky, and Indiana rather crudely. But with a bit of effort and more graphics design chops than I possess, the other states could receive similar treatment.

Note that this is only a stopgap solution to the problem of choosing state-specific shields: Mapbox GL doesn’t support grouped icons for route concurrencies yet, and ISO 3166-2 codes don’t identify counties, townships, or the myriad route networks in Texas. But it’s still better than seeing homogeneous white ovals everywhere.

Build your own Interstate

It takes a certain amount of roadgeekery to care about state-specific route shields on a map, but it doesn’t take any programming skills to design and publish a style like Interstate:

  1. Sign up for a free Mapbox account and open Studio.
  2. Click New Style and choose a template. (Other than Satellite and Empty, each of the templates is based on the Mapbox Streets source and thus OSM data.) For this style, I chose the Streets template: Templates
  3. Zoom the map in to level 10 or beyond and center it somewhere in the U.S., so that the generic oval state route shields are visible.
  4. The left sidebar lists the style’s layers, which are akin to layers in a vector graphics tool like Inkscape or Adobe Illustrator. Expand the “Highway shields” folder. Layers
  5. Two layers of interest are “road-shields-white” and “road-shields-black”. The former is for shields that have white text, such as for Interstate highways and California state highways, while the latter is for shields that have black text, including most states’ highway shields. For this style, select “road-shields-black”. (You can also click on the roads on the map to select these layers.)
  6. In the flyout for this layer, switch to the Icon tab and note that the Image property is set to {shield}-{reflen}. Mapbox GL fills in the shield and reflen tokens so that a three-digit state route gets the us-state-3 shield. Now switch to the “Select data” tab. The lengthy filter ensures that the layer doesn’t rope in any roads whose shields should have white text. The map highlights the ways that remain. These are the state routes you want to style. The filters beforehand Data on the map
  7. At the top of the layer list, click the Duplicate button and name the new layer “road-shields-state-black”. Duplicate
  8. In the new layer’s “Select data” tab, delete the existing shield filter. Replace it with one that includes a shield that “is any of” us-state. Then add another filter for an iso_3166_2 that “is any of” US-OH, US-KY, or US-IN. The resulting filters
  9. Back in the Style tab, in the Icon tab, change {shield}-{reflen} to {shield}-{reflen}-{iso_3166_2}. You’ll be adding icons with names like us-state-3-US-OH. (Alternatively, you could create a separate layer for each state, but more layers means more maintenance overhead and possibly worse performance.)
  10. Uh-oh: where previously there were generic state route shields on the map, now there are only numbers. Missing shields Click the “{}” button on this text field to open the icon manager flyout. The style already has a lot of icons, including highway shields for many countries. Icon manager flyout Click the “Add SVG Images” button and upload a roughly 20×20 SVG image for each state-reflen combination you want to support. If you’re looking for inspiration, here are some existing SVG route shield sets that you could adapt in Inkscape or Adobe Illustrator (MUTCD-compliant iconography is in the public domain, but note that some designs may be trademarked):
    • Shield templates from the 2013 shield renderer – Remove the text span from each image before use. Mapbox GL will superimpose the route number onto the shield. You can customize the number’s styling in Studio.
    • Shield blanks from Wikimedia Commons – You may want to remove the black background from many of these images. The black background improves visibility for reassurance markers, but it’s unnecessary when the shield is merely a “sticker” on a map.
    • Some crude images I made based on a few of the Wikimedia Commons images above
  11. After uploading the images, you should see them in the flyout, and the map should now show state-specific shields. Uploaded icons Shields fixed Finally, click the Publish button at the top of the left sidebar to make your changes public.

As seen on TV

I encourage you to check out Interstate. The map starts out at the Ohio-Kentucky-Indiana tripoint, so you can see the special style rules in action. Unlike the 2013 shield renderer, Interstate is the real deal: it’s served from production servers, ready to be embedded in a Web, desktop, or mobile application. (But please create your own copy using the instructions above instead of hotlinking this demonstration style.)

An example of what an iOS navigation application would look like using the Interstate style, the Mapbox iOS SDK, and the OSRM-powered Mapbox Directions API.

It’s worth noting that the ref tag isn’t just for renderers: OSRM includes the ref of each way along the route, so that a turn-by-turn navigation application can announce “Turn left onto SR 4.” If locals don’t refer to the highway as “OH 4”, neither should the voice announcement.

The ISO 3166-2 codes exposed by Mapbox Streets partly decouple the ref tag’s format from the visual output. This frees up the ref tag to reflect the notation that’s used by humans and verifiable “on the ground”, rather than some arbitrary standard enforced for the benefit of renderers. The sooner we wean renderers off their dependence on specific ref tag patterns, the sooner we can expect renderers to support route relations. I can’t wait for that day to arrive.

Comment from BushmanK on 25 July 2016 at 20:10

I think it’s some curious coincident: two consequent diary entries (this entry and previous one) are talking about literal strings as values and bad sides of regular expressions.

Comment from MikeN on 27 July 2016 at 10:53

I wonder which technique the MapQuest @ Mapbox tile layer (which shows state and Interstate shields) uses?

Comment from Minh Nguyen on 27 July 2016 at 15:13

Are you referring to the map at At a glance, the U.S. portion of that map appears to use a proprietary data set rather than OSM. Due to how OSM route data is formatted, OSM renderers require regular expressions or spatial queries to select shields half decently, at least until relations are fully supported. But it’s entirely possible for other data sources to be formatted in a way that OSM mappers would balk at but that renderers would find more straightforward.

Comment from ElliottPlack on 27 July 2016 at 18:30

Any best practice suggestions for US State refs? In Maryland we’re doing MD xx on refs, as well as most relations.

Also, I’ve never fully understood the reasoning to have the tagging on both the ref and relation. Do any major renders / routers use the route relation tagging over the segment refs?

Comment from MikeN on 27 July 2016 at 18:39

Re: Tiles @ MapQuest - I see that you are correct, it is a proprietary dataset. I chose that as part of the changeover from their shield-ed tiles, and didn’t even look closely enough to realize that it was proprietary. Off to fix that problem!

Comment from Minh Nguyen on 27 July 2016 at 23:50

Elliott, using the postal abbreviation as you describe is the most common approach, in part because of (in my opinion shortsighted) concerns about renderers being able to choose the right state shield without using spatial queries or route relations. In a few states, such as Ohio as I mentioned above, the convention is to use the SR prefix instead to reflect the facts on the ground. I don’t know what the right answer is for Maryland.

Tagging refs on both the relations and their member ways may seem redundant, but both types of ref tag serve a purpose: route relations allow us to unambiguously indicate the network, signposted cardinal direction, and other information about a route, and it’s a cleaner way to indicate that multiple routes travel over the same way (known as concurrency or multiplexing). Meanwhile, for concurrencies, the ref tag on a way can say the order in which the routes are signposted (because one of the routes on a given way is the primary one that influences the mile markers).

For now, no mainstream renderer or router knows how to process road route relations. (OpenCycleMap and Lonvia’s map do process cycle route relations.) For that reason, we’re kind of stuck in limbo, having to tag in both places, one to ensure that the map is still usable, the other as a sounder long-term strategy.

Comment from pnorman on 28 July 2016 at 04:44

For now, no mainstream renderer or router knows how to process road route relations

They are certainly processable in Mapnik with SQL. The problem with OpenStreetMap Carto is the need to support more than just the US and the need to by default colour the way’s highway tag. If you are only worried about supporting route relations it’s fairly trivial, and route relations + way ref tags isn’t too hard if you don’t care about the way’s highway tag.

Instead, when an OSM way is baked into a vector tile, a spatial query determines the relevant ISO 3166-2 code (the country code plus the postal abbreviation), which goes into an iso_3166_2 field

Where can we see this logic?

Comment from Minh Nguyen on 3 August 2016 at 11:11

@pnorman, if it’s indeed fairly trivial to support route relations, then that’s really encouraging to hear! I was rather commenting on the fact that none of the mainstream stylesheets depict pictoral route shields or even badges based on route relations. If pictoral route shields are out of scope for openstreetmap-carto, what would it take to get the OSMUS Shield Renderer or a more robust successor onto as an alternative layer?

Comment from Minh Nguyen on 3 August 2016 at 11:13

none of the mainstream stylesheets depict pictoral route shields or even badges based on route relations

Just to be clear, I’m referring to road route relations here. I’m aware that OpenCycleMap uses route relations to badge cycle route numbers, but for roads there’s a lot more to consider than three network values.

Comment from Eric Geiler - A&B Courier on 22 July 2022 at 14:01

Thank you for the diary entry!

Comment from Minh Nguyen on 22 July 2022 at 19:59

If you’re looking for inspiration, here are some existing SVG route shield sets that you could adapt in Inkscape or Adobe Illustrator

By way of an update, the OpenStreetMap Americana project has developed a much better collection of SVG images you can use as shield backgrounds. These images are in the public domain, so you can use them freely. Another resource is Rebusurance, which is designed for user interfaces rather than maps but may be suitable if you need something at a larger size.

Login to leave a comment