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

Greg Troxel gdt at lexort.com
Wed Mar 22 12:37:30 UTC 2017

Dave Swarthout <daveswarthout at gmail.com> writes:

> This is embarrassing but relevant to this conversation. I've been mapping
> intensely for several years but adding stop signs was something I rarely
> did.

I only started adding stop signs within the last year.  Probably I
started because OsmAnd will give a warning, and that's good, as long as
there is no one else in the car :-)

> In hindsight, it's perfectly obvious when one considers routing engines
> that any highway=stop node must affect traffic in both directions unless
> made explicit in some fashion, or else ignored as OSMand seems to do. So
> far, I've only added 45 highway=stop nodes in Alaska and 18 in Thailand.
> I'll be revisiting them to add the appropriate direction tags in the not
> too distant future.

I don't think it's obvious...

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).

Stop signs, on the other hand, are for the most part sort of properties
of intereections, except that the normal cases are that some ways have
them and some don't, or that all ways have them.  (Around me, some is
much more common than all, but all isn't odd.)

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.

I had the impression that there was supposed to be a relation with the
intersection node, which seems somewhat awkward.

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.

> As to an opinion about how to implement their tagging, I would tend to go
> with the ones that resemble the directionality tags already in use for
> lanes, i.e., lanes:forward=* and lanes:backward=* except that it's awfully
> verbose. I automate much of my tagging with custom presets in JOSM so
> adding complicated, long tags to them isn't difficult but asking casual
> mappers to enter these very long tags like
> "traffic_signals:direction=forward" is going to be problematical IMO.
> Consequently, I would lean towards keeping it simple and
> using direction:forward/backward to indicate directionality, at least for
> nodes.

That sounds ok to me too, but it seems that it should be mostly
unnecessary.   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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170322/04d07db2/attachment.sig>

More information about the Tagging mailing list