[Tagging] Adding directionality to stop signs

Paul Johnson baloo at ursamundi.org
Sun Mar 26 12:48:01 UTC 2017

On Wed, Mar 22, 2017 at 6:45 PM, yo paseopor <yopaseopor at gmail.com> wrote:

> On Wed, Mar 22, 2017 at 11:31 AM, Paul Johnson <baloo at ursamundi.org>
> wrote:
>> Turn restrictions are extremely common and managed using relations, so we
>> know relations don't have to be hard.  It's possible for the editors to
>> adapt to make this easy.  There's no real reason enforcement and similar
>> from/to/device/force type relations can't be made easy at the editor level.
> I ask why we need a relation to put a traffic sign if it is in a way (not
> at intersection), and with the information of the correspondence of the
> direction of the way it is with a relation . Is duplicate work?

I'm not sure why there's such an aversion for relation primitives since the
whole concept of relations was introduced to OSM to cover data like this
that doesn't fit the simple point-and-vector scheme employed by nodes and

Nodes do not have a direction.  Vectors do, and thus the simple node-way
combination works great for simple examples.  Such examples would be an
all-way stop, a yield sign on a one-way freeway on-ramp, and similar
scenarios where all movements to the traffic control node (ie, a node
tagged highway=traffic_signals, highway=stop or highway=give_way)  is going
to be subject to that traffic control device for all possible movements.
No relation would be necessary.

Relations would greatly simplify the burden on data consumers for
situations that can't be as readily captured by simple point-and-vector
data as it eliminates any need for guesswork.  For example, a four way
intersection with stop signs facing (for example) north and south only,
with east and west facing a priority sign or no sign.  Currently, just
plopping highway=stop on a node that is a part of the north and south way
adjacent to the ground truth location of the stop sign is common practice,
but will sound an alarm or get  assigned a movement penalty for people
turning from east or west to north or south.  North to south or vice versa
through movements, doubly so, because nodes are not vectors and thus lack
direction.  A traffic control relation could have the actual intersection
node as having the role "to", and the north and south way assigned the role

Let's take another common situation:  Let's assume traffic coming from the
north and west face a stop sign, traffic from the east has no sign/a
priority sign, and traffic from the south has a stop sign over an "except
right turns" sign.  One relation can cover the traffic from the north and
west, similar to the two-way example as above.  A second relation would
handle the traffic from the south:  With the south leg as a "from" and the
north and west legs as a "to" with the intersecting node as "via".  Data
consumers could then take the stop sign into account when routing movements
from the north or west, and from the south if turning west or north, while
assuming all traffic from the east, and from the south turning east, is
free flowing.

It would also be able to model situations where traffic by different modes
has different traffic controls.  This is a common situation in North
America when it comes to bicycle infrastructure (and I can go on about how
stupid it is from a multitude of engineering and layman standpoints), where
one direction (usually the cross street) faces traffic signals, while
bicyclists or a school entrance face a stop sign.  I'll use 21st and
Midland Valley <http://www.openstreetmap.org/node/148323708> in Tulsa as an
example (I go through this intersection daily, this Google Street View
is accurate).  21st street faces traffic signals, pedestrians crossing 21st
on Midland Valley get a traffic light, bicycles get a stop sign.  The two
directions for Midland Valley could be "from" for a stop sign traffic
control relation tagged except=foot.  The traffic signal relation for the
same direction would be tagged except=bicycle, both with the crossing node
as "to".  21st wouldn't need to be part of a relation at all, as far as
those two approaches are concerned, it's the same as any other signalized
intersection (save for a high potential for jaywalking across the cycleway
on a red given the necessarily strange intersection geometry).

I'm all ears if anyone has another scheme that doesn't over-rely on context
or attempting to invent a direction for a node.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170326/f4386ab3/attachment.html>

More information about the Tagging mailing list