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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-us >> >> >> >> _______________________________________________ >> Talk-us mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-us > >_______________________________________________ >Talk-us mailing list >[email protected] >https://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
