[Tagging] Feature Proposal - RFC - junction=intersection

Matthew Woehlke mwoehlke.floss at gmail.com
Fri Jul 10 17:18:39 UTC 2020

On 10/07/2020 12.57, Tod Fitch wrote:
> 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's... interestingly ironic. The problem is you *cannot* correctly 
tag a direction on such entities where assigned to the intersection 
nodes of a dual carriageway. My proposal would not only fix that, it 
would obviate the need for specifying a direction.

Going back to relations, is it even *possible* to correctly tag a 
relation on a way that isn't split at the 'via' node? (How does the 
relation otherwise know to which side of the way it applies?) If the way 
already *must* be split at the 'via' node, I don't think splitting it 
downstream will break the relation unless the editor is dumb as rocks. 
(That is, I think the editor can reliably repair the relation 

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

Heh... I missed (or had forgotten about) that. Yes, that's what I'm 
doing, also. It solves the signals/signage issue (and likewise makes it 
sometimes unnecessary to add directionality), but not other issues with 
tools not recognizing intersections as single logical entities.

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

Broken, I would expect, if the meeting ways don't have the same 
direction :-). (Fortunately, it should be easy for tools to flag this...)

If they're in the _same_ direction, it would apply to the way that is 
"entering" (or "exiting") the node, i.e. it's well 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.

I think I've already done that? One of the proposed semantics is that 
"signals do not apply to a way which is tagged junction=intersection". 
That is, it is well defined to which edge a signal/signage/etc. applies 
*without* needing to specify a direction. (This is implicit, because 
AFAIK signals/signs never apply *inside* of intersections, but to the 
*boundaries* of intersections. Once you're *in* an intersection, the 
intent is that you *get out ASAP*.)


More information about the Tagging mailing list