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. This 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 underlying 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
