[Tagging] Feature Proposal - RFC - junction=intersection

Tod Fitch tod at fitchfamily.org
Fri Jul 10 16:57:39 UTC 2020

> On Jul 10, 2020, at 9:26 AM, Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:
> On 10/07/2020 11.24, Peter Elderson wrote:
>> Well, if you do a couple of intersections it's no big deal, but if every
>> intersection would need this and it breaks relations, no matter whose fault
>> it is, it is a problem. Then it's not just modeling, but forced repair
>> work.

In the old days the wiki said you could put a highway=stop or highway=give_way node on a way and the data consumer would determine the nearest intersection and just do the right thing. I mapped several thousand, yes thousand, stop signs that way. Later it was decided that each of those nodes should also have a direction=forward or direction=backward tag as well. Years later, I am still updating those highway=stop nodes as the various QA tools nag that I am responsible for miss tagging them. So I am pretty sensitive to changing tagging norms on intersections.

That change in tagging was also annoying because at the time the direction tag was defined and used for showing the bearing, in degrees, something (cave opening, adit, etc.) was facing. So we ended up with two separate semantics for the direction tag depending on the type of node. And an inconsistency between how stop and yield sign directions were specified (“direction=*”) and how traffic light directions were specified (“traffic_signals:direction=*”).

> Sure, but my point was that I don't think my proposal changes anything here, since someone (myself, for example) might already split ways at intersections for other reasons.
>> May be worth it, but I would like to know that at proposal time, not
>> by discovering all routes and turn restrictions are broken.
> That's fair. I'm not actually sure offhand what happens when you split a way at or near an intersection, although I would hope that editors can update the relations correctly. This is probably more of an issue with intersections where turn lanes are separately modeled, and I wonder how many of those aren't already split as they would need to be.
> That said, I think it makes sense to add a note asking editors to be mindful of such things. I'll add some wordage to the proposal.

With respect to what happens when a way is split near an intersection, I have been using the “tag all incoming ways” [1] method for mapping intersections. On two way roads leading into an intersection current tagging asks for a direction=* tag on stop and yield signs and for a traffic_signals:direction=* tag on traffic signals. I have seen a few intersections where the limit line (where you would place the stop sign or traffic light node) exactly on top of a the transition to a bridge. This leads me to wonder what the semantics of “direction=forward | backward” or “traffic_signals:direction=forward | backward” are if the node is at the change of ways, especially if the ways have different directions. I haven’t seen this defined.

But I think it is a situation that could be come more common if all ways are split where they enter an intersection so some thought should be given to that.


[1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200710/732dbeed/attachment.sig>

More information about the Tagging mailing list