[Talk-us] Shaped highway shields - trying to revive

Kevin Kenny kevin.b.kenny at gmail.com
Wed Aug 22 21:21:13 UTC 2018

(I apologize in advance to the tile-serving community if this message
is inappropriate. I see that traffic on that list is largely limited
to highly specific technical discussions, but couldn't see a more
appropriate forum.)

For several years now, I've been using the support code for shaped
shields in OSM, originally developed by Phil! Gold and Richard Weait,
to render North American-style maps. A typical example can be found at
In that view, you can see distinct shields for Interstate, US, New
York, and county routes, and at least one concurrence (New York 17M
aligned with US 6). Incidentally, Phil's is the only renderer that
I've seen that can make sense of cases like West Virginia's bizarre
double route numbers, as seen in

The visual distinction among highway shields is really necessary in
North America, where there are so many different route networks

In the course of working with the code, I've made a number of changes
and become seriously out of sync with the main development line, which
appears to be moribund. (Phil! and Richard have not answered recent
queries; I suspect that I have obsolete contact information, but the
messages also have not been returned undelivered.)

Accordingly, I've (quite reluctantly) created my own repository -
https://github.com/kennykb/osm-shields - with material from the
project. The shield templates to be found there are mostly those of
Phil! (I added only a handful), but the code to manage shields is
almost entirely new. Some significant changes are:

The list of shields to be rendered is obtained from the database
itself, rather than being predetermined by a configuration file for
each network. This has the disadvantage that refs that are known to be
problematic may be rendered (but in most cases they ought to be
unsigned_ref). On the other hand, it has the distinct advantage that
as mappers continue to create the route relations, the corresponding
shields appear virtually automatically.

The composition of shield clusters, rather than being handled by a
stored procedure in the database, is done using a GroupSymbolizer in
Mapnik. I suspect, given the dearth of discussion that I find in a
Google query, that I'm the first user to attempt to use
GroupSymbolizer with actual open-ended shield clusters, and therefore
that I've trodden new ground in the path from database to renderer. I
encourage developers who are interested in the GroupSymbolizer to read
at least https://github.com/kennykb/osm-shields/wiki/Using-the-GroupSymbolizer
- it has a number of tricks to structure the results in a way that the
GroupSymbolizer can consume and that renders well. The disadvantage to
using the GroupSymbolizer is that Phil!'s shield clusters were rather
more attractive visually, since they were aligned to lie in the
direction of a way. The advantage is that the current approach can run
on an unpatched Mapnik, as opposed to Phil!'s original, which requires
at least patching Mapnik to use a read/write connection to the

Managing, reliably, the association between ways and the routes in
which they participate requires a couple of database tables that a
stock osm2pgsql does not produce. I would very much appreciate any
commentary from developers of osm2pgsql and Mapnik, particularly,
about the issues discussed in
What I'm currently doing works well for my own use, which is driven by
daily updates to extracts at Geofabrik, but will obviously not scale
to a whole planet and minutely updates.

Finally, I'd really like to invite anyone with the necessary SVG
skills to contribute shield graphics for the missing networks. If
you're also a programmer and want to take a whack at the rest of the
procedure in https://github.com/kennykb/osm-shields/wiki/Adding-new-networks,
and give me a pull request or ask for help, that would be even better,
but even the artwork would be a time-saver.

If you've got this far in reading, thanks! I know this was a long
message, and I hope that I've not wasted too much of anyone's time.

More information about the Talk-us mailing list