<html><head></head><body>It would be tagged as described at <a href="http://wiki.openstreetmaps.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways">http://wiki.openstreetmaps.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways</a><br>
<br>
Tod<br>
<br>
-- <br>
Sent from my mobile device. Please excuse my brevity.<br><br><div class="gmail_quote">Saikrishna Arcot <saiarcot895@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Just to check, in the case of number 3, if a traffic signal was present <br />at the above direction, would there have to be two traffic signal for <br />the up-and-down two-way road?<br /><br />Saikrishna Arcot<br /><br />On Tue 15 Oct 2013 03:14:13 PM EDT, Tod Fitch wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">People will map as they see fit and, as pointed out elsewhere in this<br />thread, it is not possible to "correct" all instances of all variations.<br /><br />That said, the wiki is replete with guidance on preferred tagging for<br />various features so it is not out of line to work toward a preferred<br />method of mapping complex intersections. The data consumers will, of<br />course, need to handle as many of the non-preferred variations as they<br />can.<br /><br />That said, it seems to me that the tagging of intersections where a<br />way splits into dual car
riage
ways at an intersection can be broken<br />into three general approaches. Please forgive the ASCII art:<br /><br />1. Splitting/combining the way before the intersection.<br /><br />====>-+----<br /><br />2. Splitting/combining the way in the intersection.<br /><br />======>----<br /><br />3. Splitting/combining the way after the intersection.<br /><br />======+=>----<br /><br />("Before" and "after" based in this case on approaching the<br />intersection from the dual carriageway.)<br /><br />In my mapping I have generally followed number 2 as it just seemed<br />natural to me.<br /><br />But one thing that has been bothering me since I started adding<br />traffic signals is the requirement of putting a<br />traffic_signal:direction=* tag on bidirectional ways leading into an<br />intersection. The syntax and semantics of that seems awkward to me.<br />And I see proposals for putting things like yield (give way) and stop<br />signs into relations to show which trave
l
directions the sign applies<br />to which is a similar problem with a different proposed solution. I<br />doubt that we'd be able to do away with all need for the traffic<br />signal direction tagging or for turn restriction style relations for<br />stop and yield signs, but if we have a convention that ways are split<br />outside of an intersection (number 3 above) it would reduce the need<br />for those types of additional tagging as the traffic control sign or<br />sign would be on a one way carriage way.<br /><br />Tod<br />--<br />Sent from my mobile device. Please excuse my brevity.<br /><br />stevea <steveaOSM@softworkers.com> wrote:<br /><br />I just want to emphasize that there are (at least) two separate but<br />related issues here:<br /><br />1) Whether the "before" or "after" style is preferred or more correct,<br />2) What a routing algorithm (potentially yet-to-be-coded or<br />now-actually coded) does with either or both.<br /><br />Regarding 1), it ap
pears
that we have proponents for both styles. In<br />OSM, I submit "that's just gonna happen." While consensus is a<br />beautiful thing, it is not always perfectly achievable. I don't<br />believe it (entirely) reasonable to, say, have a bot go through<br />thousands of intersections and "make them" one flavor or another,<br />simply to make a routing algorithm more happy or easier/faster to<br />complete. Maybe a case could be made for that, but I'd like to hear<br />it. (I think of it as a BIG maybe).<br /><br />Regarding 2), be smart about (algorithmically handle) both flavors of<br />intersections. Or even more. Th<br />is is a<br />"tip of the iceberg" problem<br />that likely requires more research and a classification into more<br />than simply two flavors of intersections. I think it possible that<br />given the universe of possibilities, there are smart and clever ways<br />to apply a routing algorithm: this is just geometry and computer<br />science after all
(points, vertices, and an executive that rides<br />along the geometry which probes around, backs out, and yields<br />results). Research the entirety of the problem domain, invest<br />(substantially, if necessary) in the algorithm to handle most/all<br />cases, and all can be well.<br /><br />While it is fine to discuss "better methods" (note that is plural) of<br />creating complex intersection geometry, I find it stifling to do so<br />in the context of "for a particular routing algorithm." That leans<br />heavily towards "coding for the routing algorithm," and I think we've<br />learned that such coding make the underlyin<br />g data<br />not all they can be<br />(i.e. well-formed and as correct as we are able to observe and enter<br />them).<br /><br />I seem to be echoing what Minh said near the end of his reply:<br />"handle both." (or more).<br /><br />Good discussion.<br /><br />SteveA<br />California<br /><br /><hr /><br /><br />Talk-us mailing list<br
/>Talk-us@openstreetmap.org<br /><a href="https://lists.openstreetmap.org/listinfo/talk-us">https://lists.openstreetmap.org/listinfo/talk-us</a><br /><br /><br /><br /><hr /><br />Talk-us mailing list<br />Talk-us@openstreetmap.org<br /><a href="https://lists.openstreetmap.org/listinfo/talk-us">https://lists.openstreetmap.org/listinfo/talk-us</a></blockquote><br /><hr /><br />Talk-us mailing list<br />Talk-us@openstreetmap.org<br /><a href="https://lists.openstreetmap.org/listinfo/talk-us">https://lists.openstreetmap.org/listinfo/talk-us</a><br /></pre></blockquote></div></body></html>