[Tagging] highway=primary/secondary/tertiary - tag according to quality or usage?

Paul Johnson baloo at ursamundi.org
Tue Dec 6 20:36:22 UTC 2016

On Mon, Nov 28, 2016 at 7:36 AM, Greg Troxel <gdt at lexort.com> wrote:

> Michael Tsang <miklcct at gmail.com> writes:
> > There are some highways which the quality isn't up to the usage,
> resulting in
> > congestion. Those highways connects high-quality motorway/trunk/primary
> > highways together for long distance traffic, but they only have a single
> lane
> > per direction, with lots of traffic lights, junctions, driveways, etc.,
> > resulting in slow traffic. Because the absence of roads of proper
> quality, those
> > low quality roads become bottlenecks in the whole network.
> >
> > A while ago, I tagged them all with highway=tertiary, consistent with the
> > quality of highways around the region, disregarding the actual kinds of
> traffic
> > on the highway, and someone retagged them as highway=primary reflecting
> the
> > actual usage for long-distance inter-town traffic, and send a message to
> me
> > about that.
> First, primary/secondary/tertiary is a UK notion.  In the US, we have
> more or less used that for US highway, state highway, and other
> important road between towns.

Which makes for some frustrating situations when someone decides to mass
retag entire counties to remove primary from undeniably massively major
(and often even moreso than motorways in the vicinity!) roadways to
secondary or less.

Unless being a surface expressway (trunk) or fully controlled freeway
(motorway), I tend to qualify anything that averages 7+ lanes as primary,
5-6 lanes as secondary or primary, 4-5 lanes as secondary, 2-3 lanes as
tertiary, when otherwise not otherwise being a state (secondary) or federal
(primary) highway.

Overall, I think if people really care about which tag is used, then
> other than arguing about formal road networks, that's a clue that
> routing or rendering is being done based on just the type, rather than
> the other attributes.
> If it is one lane in each direction, then tag the lanes value.  If there
> are stop signs ro lights, tag them.   Then, a router can make routes
> that correspond to the physical experience of driving.

I agree with this, and I tend to refine tagging to this end, within the
limits of what I think would be useful for vehicles I tend to have driven.
Exception being trains, where OSM is *entirely* irrelevant except for
simulation purposes, as railroads have their own train handling manuals (of
which I somehow don't have one for the Washington Park and Zoo Railroad
anymore, which I have driven for, but inexplicably and quite mysteriously
have a Burlington Northern one, which is vastly different) and as such,
traffic rules are more or less by necessity, proprietary, inconsistent, and
overridable by a railroad controller (which is why I keep undoing one-way
tagging on Portland's MAX lines that run in reserved lanes, for example,
since I am personally aware of the rules there and even on one-way streets,
they've strategically placed the trains in the left lane so they're
operating on the right side of the street when running in opposite the
usual direction by design, which happens on nearly a daily basis at the
start and end of service).

> Also, one lane in each direction is pretty normal for long-distance
> roads that really are primary, at least around me (US, outside of
> cities, not Interstates).    Most highway=secondary are only one lane
> each way.

If it's a state highway, sure.  In absence of it being a state highway, I'd
probably tag that as a tertiary in most cases.  The US is somewhat
problematic in that there's been an upward crawl on tagging ways leaving
lower levels unnecessarily underutilized and higher levels a bit bunched.
Another overload in the US would be residential versus unclassified (the
difference I make there being whether or not people live on it or it just
being a street of nonresidential nature but not large enough to warrant
regular pavement markings).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20161206/746462b5/attachment.html>

More information about the Tagging mailing list