[Talk-us] Complex intersection mapping

Tod Fitch tod at fitchdesign.com
Tue Oct 15 19:14:13 UTC 2013

People will map as they see fit and, as pointed out elsewhere in this thread, it is not possible to "correct" all instances of all variations.

That said, the wiki is replete with guidance on preferred tagging for various features so it is not out of line to work toward a preferred method of mapping complex intersections. The data consumers will, of course, need to handle as many of the non-preferred variations as they can.

That said, it seems to me that the tagging of intersections where a way splits into dual carriage ways at an intersection can be broken into three general approaches. Please forgive the ASCII art:

1. Splitting/combining the way before the intersection.


2. Splitting/combining the way in the intersection.


3. Splitting/combining the way after the intersection.


("Before" and "after" based in this case on approaching the intersection from the dual carriageway.)

In my mapping I have generally followed number 2 as it just seemed natural to me.

But one thing that has been bothering me since I started adding traffic signals is the requirement of putting a traffic_signal:direction=* tag on bidirectional ways leading into an intersection. The syntax and semantics of that seems awkward to me. And I see proposals for putting things like yield (give way) and stop signs into relations to show which travel directions the sign applies to which is a similar problem with a different proposed solution. I doubt that we'd be able to do away with all need for the traffic signal direction tagging or for turn restriction style relations for stop and yield signs, but if we have a convention that ways are split outside of an intersection (number 3 above) it would reduce the need for those types of additional tagging as the traffic control sign or sign would be on a one way carriage way.

Sent from my mobile device. Please excuse my brevity.

stevea <steveaOSM at softworkers.com> wrote:
>I just want to emphasize that there are (at least) two separate but 
>related issues here:
>1)  Whether the "before" or "after" style is preferred or more correct,
>2)  What a routing algorithm (potentially yet-to-be-coded or 
>now-actually coded) does with either or both.
>Regarding 1), it appears that we have proponents for both styles.  In 
>OSM, I submit "that's just gonna happen."  While consensus is a 
>beautiful thing, it is not always perfectly achievable.  I don't 
>believe it (entirely) reasonable to, say, have a bot go through 
>thousands of intersections and "make them" one flavor or another, 
>simply to make a routing algorithm more happy or easier/faster to 
>complete.  Maybe a case could be made for that, but I'd like to hear 
>it.  (I think of it as a BIG maybe).
>Regarding 2), be smart about (algorithmically handle) both flavors of 
>intersections.  Or even more.  This is a "tip of the iceberg" problem 
>that likely requires more research and a classification into more 
>than simply two flavors of intersections.  I think it possible that 
>given the universe of possibilities, there are smart and clever ways 
>to apply a routing algorithm:  this is just geometry and computer 
>science after all (points, vertices, and an executive that rides 
>along the geometry which probes around, backs out, and yields 
>results).  Research the entirety of the problem domain, invest 
>(substantially, if necessary) in the algorithm to handle most/all 
>cases, and all can be well.
>While it is fine to discuss "better methods" (note that is plural) of 
>creating complex intersection geometry, I find it stifling to do so 
>in the context of "for a particular routing algorithm."  That leans 
>heavily towards "coding for the routing algorithm," and I think we've 
>learned that such coding make the underlying data not all they can be 
>(i.e. well-formed and as correct as we are able to observe and enter 
>I seem to be echoing what Minh said near the end of his reply: 
>"handle both." (or more).
>Good discussion.
>Talk-us mailing list
>Talk-us at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20131015/f955a31e/attachment.html>

More information about the Talk-us mailing list