Badges? Badges?

rweait's picture

Come on. The new highway shields are nice, but the map in North America just isn't "there" yet. Our continental cousins may be satisfied with generic oval highway markers, but that just doesn't measure up in the New World.

The new markers, shown above, turned up on mapnik recently. They seem more refined than the rectangular signs used previously and they are very pretty. But they just aren't right for North America.

North Americans are still in love with their cars and with their highways. And highway shields are an important and ubiquitous landmark. The main OpenStreetMap® map style tells you that you "don't need no stinking badges" but that is clearly incorrect.

We want OpenStreetMap to be the best map of world. And North America is part of the World. So we must fix the highway shields.

This is what OpenStreetMap highway shields look like when hacked on to my local OpenStreetMap tile server. And this is closer to what OpenStreetMap highway shields should look like for all of us.

first custom shield tile server

Much nicer, I say.

Here we see I-190, highway 405 and the Queen Elizabeth Way each honoured with their correct shield. The way it should be. Correct shield rendering is as simple as adding the correct network tag to the highway way.
So how do we fix this?

There are so many highway networks in North America with so many distinctive shields. A good looking map needs to support this wide range of shields. And we want OpenStreetMap to be able to do this in a sane a simple way.

Currently Highway Shields are created for the OpenStreetMap mapnik layer by the mapnik ShieldSymbolizer. Here is how the ~/mapnik/osm-template.xml file instructs mapnik to create shields.

<Style name="roads-text">
    <Filter>[highway] = 'motorway' and [length] = 1</Filter>
    <MaxScaleDenominator> 1000000 </MaxScaleDenominator>
    <MinScaleDenominator> 100 </MinScaleDenominator>
    <ShieldSymbolizer name="ref" face_name="DejaVu Sans Bold" size="11" fill="#809bc0" placement="line" file= "%SYMBOLS_DIR%/motorway_shield1.png" type="png" width="17" height="17" min_distance="120" />

Fine. It works. This section is repeated six times for highway=motorway, once for each length, one through six. It is then repeated eight times each for highway=trunk, highway=primary, highway=secondary and highway=tertiary at their respective lengths of one through eight characters. Thirty-eight paragraphs of XML to deliver a single style of highway shield. This is the one rendered for a four-digit reference. In this case "I 90".

Scaling this for the US Interstate shields would increase the size of this area of the XML file from six paragraphs to eight. It might look something like this.

<Style name="roads-text">
<Filter>[highway] = 'motorway' and [length] = 1</Filter>
... details
<Filter>[highway] = 'motorway' and [network] = 'us_i' and ([length] = 2 or [length] = 1 )</Filter>
... details
<Filter>[highway] = 'motorway' and [network] = 'us_i' and [length] = 3</Filter>
< ... details

This works for US Interstate shields because the Interstate system by definition matches the OpenStreetMap expectation for highway=motorway. That is, controlled access, grade separated junctions and a minimum or 2 lanes in each direction. There are only two basic shield designs, one for single-digit and two-digit highway numbers and a wider version for three-digit highway numbers.

The scaling problem gets much worse when we add U.S. Routes. U.S. Route highway numbers, like Interstates may be one-, two-, or three-digits long. Like Interstates, single- and two-digit U.S. Routes share a square sign while three-digit U.S.Routes have a wider sign. That nominally adds two more XML paragraphs for highway=motorway, but U.S. Routes do not always conform to OpenStreetMap Motorway standards. U.S. Routes are also be configured as highway=trunk, highway=primary and highway=secondary. So with the current osm-template.xml file adding Interstates and U.S. Routes expands this section of the file from 38 paragraphs to 48 paragraphs.

Now what happens if we add the state routes? Ohio and New York state shields for 2-digit highways are shown here. State highways may also be configured as at least trunk, primary and secondary, and will also have two different signs. Presuming each state has an unique state route sign for 2- and 3-digit signs, this will add three-hundred ( 50 states * 2 sign widths * 3 highway classifications ) more paragraphs to the XML.

If this isn't enough to make you reconsider how we render highway shields, let's consider county roads... Thousands of extra paragraphs. Insane. And it just get worse if we consider autoroutes, historic routes, and Canada. This means even thousands more paragraphs.
Let's make a better way

And let's imagine that the "better way" will make things easy for mappers and those using mapnik, but perhaps a challenge for mapnik developers. We're adding network tags to ways and relations. Let's use the network to find the right icon for the shield.

# I-190 as above

Why not allow ShieldSymbolizer to create a filename and path for the shield image from network and other k:v pairs? A simple implementation might allow a default path for all symbols, then append file=[network] and type="png" to make a reasonable shield image path/name. A hardier implementation might default back to a known image if the generated filename is not found.

An advanced implementation might allow the appending of network:suffix for "BUS", "BYP" or "TRUCK" routes or even adding direction flags for visualizing on-ramps or turn instructions.

Please, mapnik developers, please make this happen?

# King's Highway 405

Special signs get network tags with increasing specificity, like Ontario's King's Highways. Exits for these Primary roads are indicated with the highway number inside a stylized crown. They are black on white, except for the Queen Elizabeth Way (aka 451). Named for the Queen Mother during a Royal Visit in 1939 with King George VI, special signs for QEW are royal blue on gold.

# Queen Elizabeth Way is a King's highway with a special sign

Fixing highway shields in North America will require user support, renderer support and editor support.

Users will need to fix the broken ref tags that exceed the digits. "Interstate 90" is not a ref tag, and neither is "I-90". The correct tag is just the digits, "90". Nor should the direction be included in the ref. Westbound I-90 is not
ref=I-90 West

So we users in North America have some cleaning up to do on our highway tags.

Which brings us to relations. With full support for relations and super-relations we can tag highways in a contextual way that is very useful.

For example, all eastbound ways of I-90 can be collected in a relation
# I-90 eastbound relation

The I-90 eastbound and I-90 westbound relations can be collected into an overall I-90 relation
# All I-90 relation

So full support for network and other highway tags in relations and super-relations would be a good thing.

Editor support for these tags would be nice as well. Perhaps with tips to get the ref tag right and suggest values for network tags.

You can find a very limited demo of what highway shields will look like here. [Umm, no you can't. Demo removed. -r]

And a plea to mappers in USA

Please use the correct ref value when tagging highways. The ref is most often, just the number. The network is the alphabetic portion of what we say. "I 90 or I-90" is not a ref value. "90" is the ref. "I, or US, or OH" is the network for Interstate, US Route or Ohio State Route. We need to add a country code for USA so that our network initials don't get confused with those in other parts of the world. -- Thanks


This article from the archives was originally published on 27 March 2009.


OpenStreetMap is a registered trade mark of the OpenStreetMap Foundation in the United States, Europe and elsewhere.

Maps and map data within this article are licensed CC-By-SA v2.0 because they were captured in 2009. The newer header image is also licensed CC-By-SA, and is created from ODbL v1.0 data.

Photos are © Richard Weait

Highway shield graphics are from Wikipedia and licensed CC-By-SA v3.0