[Talk-us] Scrubbing route relations (attn: Richard Welty, etc.)

Chris Lawrence lordsutch at gmail.com
Thu Oct 25 00:01:43 GMT 2012

On Wed, Oct 24, 2012 at 12:28 PM, Michal Migurski <mike at stamen.com> wrote:
> I applied these changes to OSM last night, in a series of five changesets:
>         http://www.openstreetmap.org/browse/changeset/13611326
>         http://www.openstreetmap.org/browse/changeset/13612265
>         http://www.openstreetmap.org/browse/changeset/13612825
>         http://www.openstreetmap.org/browse/changeset/13612736
>         http://www.openstreetmap.org/browse/changeset/13613023
> Offlist, I've been talking to NE2 about the edits, and he pointed out this morning that they negatively affect shield rendering on Aperiodic:
>         http://elrond.aperiodic.net/shields/?zoom=15&lat=38.7166&lon=-77.79472&layers=B
> "Whereas formerly relations with network=US:US and the modifier in the ref failed somewhat gracefully if a bit pigheadedly (by not displaying shields at all), they now show up incorrectly as mainline routes." - NE2
> NE2 asked me to revert the changes, because he's unhappy with me moving the route variant information from the ref tags to the modifier tags, e.g. turning "ref=80 Business" into "ref=80 modifier=Business". According to the supported tagging guidelines on Aperiodic, my interpretation should be correct: "The value of the ref tag on the relation must contain just the route number, without any network information." http://elrond.aperiodic.net/shields/supported.html

This is not surprising.  To give you a little bit of background... the
original idea (when I drafted the material on route relation tagging)
was basically to follow the convention that you followed in the
remapping that got uploaded.  For example, Bypass US 129 would be:


Somewhere along the way, it was decided that all the US networks
(including the US and I networks) should start with US:, giving us:


Then there was some concern that people editing relations might
"forget" the modifier - i.e. accidentally use a "US 129 Bypass"
relation when tagging "US 129."  Or renderers would Do The Wrong Thing
if they were modifier-unaware.  So two potential solutions emerged:

ref=129 Bypass



with or without the modifier tag.

There are technical and aesthetic arguments for and against both.  The
first solution correctly notes that these "modifier" networks aren't
really true, distinct networks; they are local spurs or loops off the
main network, so at the very least the tag "network" is a misnomer.
ref is the only other tag that most mappers and data consumers will
look at, so it's the logical place to put the modifier.  (Using
another tag instead just brings us back to the original problem that
consumers or mappers might forget to set or look for it.)

The second solution points out that ref was originally designed to be
parsing-free for consumers - you put the content of "ref" on the
shield selected from network and (optionally) modifier - and even
though "network" may not be a good name for the tag, data consumers
can use it as an index for the correct route marker to select without
consulting other tags.

Anyway, NE2 (and seemingly only NE2) favor(ed/s) the first one.
Everyone else seems to have gravitated toward the second one.  NE2
points to this lack of consensus and continues to do what he does.
Everyone else continues to do what they do.  As people go around and
edit things, they get switched from one to the other (in a form of
low-level guerrilla edit warfare).  (Same thing has happened with ref
tags on ways... same person versus the world.)

Since the two forms aren't that different data consumers could
preprocess data from one form to the other form.  Then again having
everybody do the same thing simplifies the lives of data consumers.
The shield rendering team has decided to only accept the second form,
for whatever reason (presumably because it makes their lives easier).

As far as what to do from here... damned if I know.  I don't think
anyone wants NE2 banned (he's a dedicated armchair mapper and
contributes a lot to OSM, even if he's somewhat pigheaded in applying
his own particular approaches in places where it's not as clear he has
a lot of local knowledge), but at the same time he doesn't seem to be
willing to concede on this point which IMO has become an obstacle to
improving the map as-used by Skobbler, Mapbox, Stamen, Cloudmade,
Mapquest etc downstream.  I guess my advice would be to proceed but be
cautious of blowback.


More information about the Talk-us mailing list