[Talk-us] Complex intersection mapping

[Tod Fitch]

It would be tagged as described at http://wiki.openstreetmaps.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways

Tod

-- 
Sent from my mobile device. Please excuse my brevity.

Saikrishna Arcot <saiarcot895 at gmail.com> wrote:
>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
>
>_______________________________________________
>Talk-us mailing list
>Talk-us at openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20131015/9decbb65/attachment-0001.html>