[Tagging] Feature Proposal - RFC - junction=intersection
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” 
> 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