[Talk-us] Complex intersection mapping
Tod Fitch
tod at fitchdesign.com
Tue Oct 15 20:59:01 UTC 2013
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>
More information about the Talk-us
mailing list