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
