[Talk-us] Complex intersection mapping

[Saikrishna Arcot]

Just to check, in the case of number 3, if a traffic signal was present 
at the above direction, would there have to be two traffic signal for 
the up-and-down two-way road?

Saikrishna Arcot

On Tue 15 Oct 2013 03:14:13 PM EDT, Tod Fitch wrote:
> 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.
>
> Tod
> --
> 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.  Th
>      is 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 underlyin
>      g data
>     not all they can be
>     (i.e. well-formed and as correct as we are able to observe and enter
>     them).
>
>     I seem to be echoing what Minh said near the end of his reply:
>     "handle both." (or more).
>
>     Good discussion.
>
>     SteveA
>     California
>
>     ------------------------------------------------------------------------
>
>     Talk-us mailing list
>     Talk-us at openstreetmap.org
>     https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us