[Tagging] traffic_signals:direction=* vs. direction=*

Tod Fitch tod at fitchdesign.com
Wed Mar 22 14:16:25 UTC 2017


Quoted sections have been edited down to only show parts I am responding to:

> On Mar 22, 2017, at 5:37 AM, Greg Troxel <gdt at lexort.com> wrote:
> 
> For highway=traffic_signals, the normal situation is that it's on a
> node, and affects all ways entering the node.  Or it's on a way and
> affects both directions -- in my experience, when there are traffic
> lights not at an intersection, they are always for both directions (even
> though in theory they could be set up for one direction only).

CalTrans has used semi-permanent traffic signals to control traffic flow over damaged road sections. A light at each side of the damaged area controls the sequentially one-way traffic through the damaged area that has been reduced to one lane operation. I’ve seen these in the Santa Cruz mountains, but the longest section of road I’ve seen controlled this way was on the main road to Yosemite Valley where the side of the mountain came down on the main roadway and the work around, in place for several years, was to put some pavement on the old single track railway grade on the other side of the river and put two bridges in place to get traffic across and back. It maybe still in place while but I’ve not been through there in several years. I know they took a long time to decide what to do about the still unstable mountain above the covered section of highway.

So there are places with traffic signals away any intersections that control traffic going into a one lane section. I guess a smart router could guess that the transition of a road from two lanes to one lane would count as an intersection but that seems an error prone algorithm. Having a direction tag of some sort available does make tagging this situation possible.

> As a human, if I see a highway=stop on a way about 3-10m from an
> intersection, it's obvious that it applies to travel on the way towards
> the intersection, but not leaving the intersection.  However, I think
> OsmAnd sometimes falses on these.

OsmAnd always seems to “false on” these. To the point where I ignore the stop warning it gives.

> I would suggest a definition that associates the stop sign with the
> nearest intersection if it's less than 25m away, and there are no
> intersections in the other direction within 3x that closest intersection
> distance.  And then to use relations to label which intersection, if the
> above doesn't work.

Sounds like a reasonable thing to add some distances to the wiki where it describes that algorithm but without specific distance numbers.

> . . .   I view this whole exercise as designing tagging rules
> that are good for human editors and acceptable (semantically non-kludgy
> and reasonably easily implementable) for data consumers.

+1 on that.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1861 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170322/17692599/attachment.bin>


More information about the Tagging mailing list