Re: [Talk-us] Complex intersection mapping

[Martijn van Exel]

Thanks, James.
By the way I was looking for a decent way to review the history for
this area and that reminded me of the excellent new History tab which
is currently live on one of the dev instances:
http://owl.apis.dev.openstreetmap.org/#map=17/40.43974/-79.75819
You should give it a try, it's really neat.
Martijn

On Sat, Nov 9, 2013 at 3:28 PM, James Mast  wrote:
>> From: marti...@telenav.com
>> Date: Sat, 9 Nov 2013 11:31:55 -0500
>> To: rickmastfa...@hotmail.com
>> CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com;
>> chr...@telenav.com; talk-us@openstreetmap.org
>
>> Subject: Re: [Talk-us] Complex intersection mapping
>>
>> James,
>>
>> Thanks for the feedback. This is of course not good. I will make sure
>> we will be more careful with both the lane counts and the relations
>> not getting broken! I apologize. Did you fix the relations? If not I
>> will.
>>
>
> I hadn't yet since I wanted to wait till you responded on the list first so
> you could see what I was talking about (Changeset 18789658).
>
>
>> The case you highlighted - I agree this one would be just fine as a
>> single node.
>
> That's how I'm going to repair that intersection & the relations that were
> effected, by just reverting Changeset 18789658 to return it to the way it
> was before yesterday.
>
>
>> The guidance I have been giving, based on previous
>> discussion in this thread, was to only 'dualize' the intersection when
>> the dual carriageway clearly continues past the intersection. Does
>> that make sense?
>
> Yep, that does make perfect sense to me.  That's how I've personally been
> doing it.
>
>
>>I will make sure we adhere to that guideline and not
>> overcomplexify situations that don't require it from a ground trouth
>> perspective.
>>
>> Martijn
>
> Sounds good Martijn.  Thanks again for responding back on this subject. :)
> I'll now go ahead and do the revert of Changeset 18789658.
>
> -James
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>



-- 
--
Martijn van Exel
OSM data specialist
Telenav
http://www.osm.org/user/mvexel
http://wiki.openstreetmap.org/wiki/User:Mvexel
http://hdyc.neis-one.org/?mvexel

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[James Mast]

> From: marti...@telenav.com
> Date: Sat, 9 Nov 2013 11:31:55 -0500
> To: rickmastfa...@hotmail.com
> CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com; 
> chr...@telenav.com; talk-us@openstreetmap.org
> Subject: Re: [Talk-us] Complex intersection mapping
> 
> James,
> 
> Thanks for the feedback. This is of course not good. I will make sure
> we will be more careful with both the lane counts and the relations
> not getting broken! I apologize. Did you fix the relations? If not I
> will.
> 

I hadn't yet since I wanted to wait till you responded on the list first so you 
could see what I was talking about (Changeset 18789658).

> The case you highlighted - I agree this one would be just fine as a
> single node.

That's how I'm going to repair that intersection & the relations that were 
effected, by just reverting Changeset 18789658 to return it to the way it was 
before yesterday.

> The guidance I have been giving, based on previous
> discussion in this thread, was to only 'dualize' the intersection when
> the dual carriageway clearly continues past the intersection. Does
> that make sense?

Yep, that does make perfect sense to me.  That's how I've personally been doing 
it.

>I will make sure we adhere to that guideline and not
> overcomplexify situations that don't require it from a ground trouth
> perspective.
> 
> Martijn

Sounds good Martijn.  Thanks again for responding back on this subject. :)  
I'll now go ahead and do the revert of Changeset 18789658.

-James

  ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martijn van Exel]

James,

Thanks for the feedback. This is of course not good. I will make sure
we will be more careful with both the lane counts and the relations
not getting broken! I apologize. Did you fix the relations? If not I
will.

The case you highlighted - I agree this one would be just fine as a
single node. The guidance I have been giving, based on previous
discussion in this thread, was to only 'dualize' the intersection when
the dual carriageway clearly continues past the intersection. Does
that make sense? I will make sure we adhere to that guideline and not
overcomplexify situations that don't require it from a ground trouth
perspective.

Martijn


On Fri, Nov 8, 2013 at 9:47 PM, James Mast  wrote:
> Martijn (and other telenav workers),
>
> I just happened to see some intersections in my area tweaked today.  If
> you're going to be changing the intersections, can you at least please
> update the lane count on said ways if it's already been added at the same
> time?  I mean, if a way is on one side 4 lanes, and you split it into two
> separate ways, odds are both of them are 2 lanes each.  Yet, the lane count
> on them is still "4", which can also play screwy with the routing engines.
>
> Also, can you please update any relations that are attached to the highways?
> I'm going to bring up Changeset 18789658 as an example, which is the
> intersection of US-22 Business, PA-48, & the Orange Belt in Monroeville, PA.
> The two numbered routes were "broken" today (amazingly the Orange Belt
> wasn't) with the change from a 1-point intersection to a 4-point
> intersection.  I personally think that a 1-point intersection was completely
> justified for this intersection because of only two directions being divided
> when exiting it.  Anyways, US-22 Business now has a gap because of the "new"
> ways for it, and PA-48 now doesn't end @ the intersection anymore because of
> the divided highway from the North being extended outside the main
> intersection.  And, to be honest, I'm also toying with the idea of reverting
> said changeset to repair the relations and make it a 1-point intersection
> again, but wanted to bring it up here on the list first before doing that to
> prevent an edit war.
>
> So, if you keep doing it that way, can you please keep the collateral damage
> to a minimum when it comes to lane counts and highway relations?  I would
> really appreciate it when stuff like that was already tagged correctly
> doesn't need to be fixed again. :)
>
>
> -James (rickmastfan67)
>
>
>> From: marti...@telenav.com
>> Date: Mon, 14 Oct 2013 11:42:53 -0600
>> To: talk-us@openstreetmap.org
>> CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com;
>> chr...@telenav.com
>> Subject: [Talk-us] Complex intersection mapping
>
>>
>> Hi all,
>>
>> Here at Telenav we have been looking at complex intersections and we
>> have set about editing some of these intersections in a way we feel
>> represents the situation on the ground better than their original
>> state, and because of that, works better for us. We have received some
>> feedback on our edits so we wanted to take a step back and see what we
>> (as the OSM community) think is the preferred way to map these
>> intersections.
>>
>> So what are we talking about? Intersections like this one, where one
>> or more dual carriageways come together at an at-grade intersection:
>>
>>
>> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>>
>> One of my colleagues at Telenav has remapped this intersection as follows:
>>
>>
>> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
>>
>> The main difference, and the source of some feedback we have received
>> over the past few days, is that the dual carriageway roads are
>> straightened out, creating multiple intersection nodes (4 in this
>> case) instead of the original single intersection node that connects
>> all the incoming and outgoing ways. That technique turns out to yield
>> more reliable and correct routing and guidance ('keep left, turn
>> right') through these intersections in our testing. But of course,
>> that cannot dictate how we map as a community, so let's discuss.
>>
>> Some of the feedback we have received about these edits points to a
>> statement on this wiki page:
>> https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
>> is a reasonable and well-used technique to bring the ways of dual
>> carriageways back to a single point at intersections to facilitate and
>> simplify the mapping of control devices and turn restrictions.' In my
>> mapping across the US, my personal experience has been that this
>> technique is in fact used, but the 'after' technique with straightened
>> out ways is actually much more common. I personally prefer that
>> technique as well - I think it is more pleasing to the eye, represents
>> what is on the ground better, and is and easier to read. So my feeling
>>

Re: [Talk-us] Complex intersection mapping

[Evin Fairchild]

Agreed, it's really important that when people make a road be
dual-carriageway that they change the lane count and make sure both
directions have the applicable route relations.

 

-Compdude

 

From: James Mast [mailto:rickmastfa...@hotmail.com] 
Sent: Friday, November 8, 2013 6:47 PM
To: Martijn van Exel; OSM US Talk
Cc: ste...@telenav.com; krist...@telenav.com; Stack, Robert;
chr...@telenav.com
Subject: Re: [Talk-us] Complex intersection mapping

 

Martijn (and other telenav workers),

I just happened to see some intersections in my area tweaked today.  If
you're going to be changing the intersections, can you at least please
update the lane count on said ways if it's already been added at the same
time?  I mean, if a way is on one side 4 lanes, and you split it into two
separate ways, odds are both of them are 2 lanes each.  Yet, the lane count
on them is still "4", which can also play screwy with the routing engines.

Also, can you please update any relations that are attached to the highways?
I'm going to bring up Changeset 18789658
<http://www.openstreetmap.org/browse/changeset/18789658>  as an example,
which is the intersection of US-22 Business, PA-48, & the Orange Belt in
Monroeville, PA.  The two numbered routes were "broken" today (amazingly the
Orange Belt wasn't) with the change from a 1-point intersection to a 4-point
intersection.  I personally think that a 1-point intersection was completely
justified for this intersection because of only two directions being divided
when exiting it.  Anyways, US-22 Business now has a gap because of the "new"
ways for it, and PA-48 now doesn't end @ the intersection anymore because of
the divided highway from the North being extended outside the main
intersection.  And, to be honest, I'm also toying with the idea of reverting
said changeset to repair the relations and make it a 1-point intersection
again, but wanted to bring it up here on the list first before doing that to
prevent an edit war.

So, if you keep doing it that way, can you please keep the collateral damage
to a minimum when it comes to lane counts and highway relations?  I would
really appreciate it when stuff like that was already tagged correctly
doesn't need to be fixed again. :)


-James (rickmastfan67)



> From: marti...@telenav.com
> Date: Mon, 14 Oct 2013 11:42:53 -0600
> To: talk-us@openstreetmap.org
> CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com;
chr...@telenav.com
> Subject: [Talk-us] Complex intersection mapping
> 
> Hi all,
> 
> Here at Telenav we have been looking at complex intersections and we
> have set about editing some of these intersections in a way we feel
> represents the situation on the ground better than their original
> state, and because of that, works better for us. We have received some
> feedback on our edits so we wanted to take a step back and see what we
> (as the OSM community) think is the preferred way to map these
> intersections.
> 
> So what are we talking about? Intersections like this one, where one
> or more dual carriageways come together at an at-grade intersection:
> 
>
https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e
8f07ff527c6a85c0dec426b9b79f1e
> 
> One of my colleagues at Telenav has remapped this intersection as follows:
> 
>
https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9d
d47d1445fdcf03d3f0bbd93b8e0f92
> 
> The main difference, and the source of some feedback we have received
> over the past few days, is that the dual carriageway roads are
> straightened out, creating multiple intersection nodes (4 in this
> case) instead of the original single intersection node that connects
> all the incoming and outgoing ways. That technique turns out to yield
> more reliable and correct routing and guidance ('keep left, turn
> right') through these intersections in our testing. But of course,
> that cannot dictate how we map as a community, so let's discuss.
> 
> Some of the feedback we have received about these edits points to a
> statement on this wiki page:
> https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
> is a reasonable and well-used technique to bring the ways of dual
> carriageways back to a single point at intersections to facilitate and
> simplify the mapping of control devices and turn restrictions.' In my
> mapping across the US, my personal experience has been that this
> technique is in fact used, but the 'after' technique with straightened
> out ways is actually much more common. I personally prefer that
> technique as well - I think it is more pleasing to the eye, represents
> what is on the ground better, and is and easier to read. So my feeling
> was that this mapping practice wo

Re: [Talk-us] Complex intersection mapping

[James Mast]

Martijn (and other telenav workers),

I just happened to see some intersections in my area tweaked today.  If you're 
going to be changing the intersections, can you at least please update the lane 
count on said ways if it's already been added at the same time?  I mean, if a 
way is on one side 4 lanes, and you split it into two separate ways, odds are 
both of them are 2 lanes each.  Yet, the lane count on them is still "4", which 
can also play screwy with the routing engines.

Also, can you please update any relations that are attached to the highways?  
I'm going to bring up Changeset 18789658 as an example, which is the 
intersection of US-22 Business, PA-48, & the Orange Belt in Monroeville, PA.  
The two numbered routes were "broken" today (amazingly the Orange Belt wasn't) 
with the change from a 1-point intersection to a 4-point intersection.  I 
personally think that a 1-point intersection was completely justified for this 
intersection because of only two directions being divided when exiting it.  
Anyways, US-22 Business now has a gap because of the "new" ways for it, and 
PA-48 now doesn't end @ the intersection anymore because of the divided highway 
from the North being extended outside the main intersection.  And, to be 
honest, I'm also toying with the idea of reverting said changeset to repair the 
relations and make it a 1-point intersection again, but wanted to bring it up 
here on the list first before doing that to prevent an edit war.

So, if you keep doing it that way, can you please keep the collateral damage to 
a minimum when it comes to lane counts and highway relations?  I would really 
appreciate it when stuff like that was already tagged correctly doesn't need to 
be fixed again. :)


-James (rickmastfan67)


> From: marti...@telenav.com
> Date: Mon, 14 Oct 2013 11:42:53 -0600
> To: talk-us@openstreetmap.org
> CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com; 
> chr...@telenav.com
> Subject: [Talk-us] Complex intersection mapping
> 
> Hi all,
> 
> Here at Telenav we have been looking at complex intersections and we
> have set about editing some of these intersections in a way we feel
> represents the situation on the ground better than their original
> state, and because of that, works better for us. We have received some
> feedback on our edits so we wanted to take a step back and see what we
> (as the OSM community) think is the preferred way to map these
> intersections.
> 
> So what are we talking about? Intersections like this one, where one
> or more dual carriageways come together at an at-grade intersection:
> 
> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
> 
> One of my colleagues at Telenav has remapped this intersection as follows:
> 
> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
> 
> The main difference, and the source of some feedback we have received
> over the past few days, is that the dual carriageway roads are
> straightened out, creating multiple intersection nodes (4 in this
> case) instead of the original single intersection node that connects
> all the incoming and outgoing ways. That technique turns out to yield
> more reliable and correct routing and guidance ('keep left, turn
> right') through these intersections in our testing. But of course,
> that cannot dictate how we map as a community, so let's discuss.
> 
> Some of the feedback we have received about these edits points to a
> statement on this wiki page:
> https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
> is a reasonable and well-used technique to bring the ways of dual
> carriageways back to a single point at intersections to facilitate and
> simplify the mapping of control devices and turn restrictions.' In my
> mapping across the US, my personal experience has been that this
> technique is in fact used, but the 'after' technique with straightened
> out ways is actually much more common. I personally prefer that
> technique as well - I think it is more pleasing to the eye, represents
> what is on the ground better, and is and easier to read. So my feeling
> was that this mapping practice would not be disputed. It turns out I
> was wrong, so I want to see what the consensus is on mapping
> intersections of this type - or perhaps there is none and we can work
> together to get there?
> 
> Thanks,
> Martijn
> --
> Martijn van Exel
> OSM data specialist
> Telenav
> http://www.osm.org/user/mvexel
> http://wiki.openstreetmap.org/wiki/User:Mvexel
> http://hdyc.neis-one.org/?mvexel
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
  ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[James Mast]

> From: marti...@telenav.com
> Date: Mon, 21 Oct 2013 17:40:11 -0600
> To: nel...@crynwr.com
> CC: talk-us@openstreetmap.org
> Subject: Re: [Talk-us] Complex intersection mapping
> 
> 
> One followup question I do have is about one of the other examples of
> elaborate intersections Minh raised, the Continuous Flow or or XDL
> intersections (example
> http://www.openstreetmap.org/browse/relation/1284976), I would prefer
> to put a no-U-turn restriction on
> http://www.openstreetmap.org/browse/node/1002992385 - agreed?
> 
> Thanks again for all your feedback.
> 
> -- 
> Martijn van Exel
> OSM data specialist
> Telenav
> http://www.osm.org/user/mvexel
> http://wiki.openstreetmap.org/wiki/User:Mvexel
> http://hdyc.neis-one.org/?mvexel
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us


Wouldn't splitting the primary_link at the light and adding an 
"only_straight_on" restriction be better here?

-James
  ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martijn van Exel]

On Tue, Oct 15, 2013 at 10:52 PM, Russ Nelson  wrote:
> It *is* incorrect to map in contravention to the description in the
> Wiki.
> It *is* incorrect to map without the wiki containing an explanation of
> how you map.
>
> If there are a dozen different ways to enter a stop sign into OSM, and
> they're all documented in the Wiki, that's good.
>
> If there are a dozen different ways to enter a stop sign into OSM, and
> one isn't documented in the Wiki, that's bad.
>
> If, of course, two people read the Wiki and map differently, that's
> not their fault -- it's the Wiki's description's fault.

Unfortunately, the wiki is not in a state that allows for such rigid
statements connecting mapping practices and documentation. I do agree
generally that everyone should look to the wiki for guidance on how to
map things, but it can't always be the definitive voice you seem to
make it out to be. Let me just give the one seminal example of
confusing, sometimes contradictory information on highway
classification, as represented on no less than four pages here
https://wiki.openstreetmap.org/wiki/United_States_Road_Classification,
here 
https://wiki.openstreetmap.org/wiki/United_States_Roadway_Classification_Guidelines,
here https://wiki.openstreetmap.org/wiki/United_States_roads_tagging
AND here https://wiki.openstreetmap.org/wiki/Highway:International_equivalence.
Another source of confusion on the wiki is the voting system on tags,
which evokes a sense of authoritativeness on decisions made per this
process that does not exist in reality, because so few people actually
take part in this process, and many actively dismiss it as being
misleading and confusing.

Back on topic, I see general support for straightening out
intersections where a road has continuous dual carriageways on both
sides, but Minh's specific cases make a lot of sense to me: we should
not overcomplicate situations and make them less legible and less true
to ground truth:

http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/remick_before.png
versus
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/remick_after.png
where I do prefer the first solution.

One followup question I do have is about one of the other examples of
elaborate intersections Minh raised, the Continuous Flow or or XDL
intersections (example
http://www.openstreetmap.org/browse/relation/1284976), I would prefer
to put a no-U-turn restriction on
http://www.openstreetmap.org/browse/node/1002992385 - agreed?

Thanks again for all your feedback.

-- 
Martijn van Exel
OSM data specialist
Telenav
http://www.osm.org/user/mvexel
http://wiki.openstreetmap.org/wiki/User:Mvexel
http://hdyc.neis-one.org/?mvexel

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Russ Nelson]

Tod Fitch writes:
 > 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.

It's *not* incorrect to map as you see fit.
It *is* incorrect to map in contravention to the description in the
Wiki.
It *is* incorrect to map without the wiki containing an explanation of
how you map.

If there are a dozen different ways to enter a stop sign into OSM, and
they're all documented in the Wiki, that's good.

If there are a dozen different ways to enter a stop sign into OSM, and
one isn't documented in the Wiki, that's bad.

If, of course, two people read the Wiki and map differently, that's
not their fault -- it's the Wiki's description's fault.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Tod Fitch]

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  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  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-

Re: [Talk-us] Complex intersection mapping

[Saikrishna Arcot]

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  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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://li

Re: [Talk-us] Complex intersection mapping

[Tod Fitch]

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  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
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[stevea]

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
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Stellan Lagerström]

On 2013-10-15 4:12 PM, Martijn van Exel wrote:

I apologize for the confusion around the term 'braiding' - we used
this term internally for a while (and it ended up in some changeset
comments) not realizing that this had a different meaning that traces
back to the TIGER source data.

To me, the "before" pattern looks a lot like sausage links when repeated 
along several blocks... :)


/StellanL

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martijn van Exel]

Hi Minh -

Thanks for clarifying the more specific cases. I realize that my
example would not cover all the possible permutations. Thank you for
bringing more specific cases to the table. My colleague Kristen also
has some more specific examples I know she intends to share here. Your
specific cases actually make a lot of sense to me. I want to discuss
this with my colleagues and get their opinions as well.

I apologize for the confusion around the term 'braiding' - we used
this term internally for a while (and it ended up in some changeset
comments) not realizing that this had a different meaning that traces
back to the TIGER source data.

Thank you for your feedback!

On Tue, Oct 15, 2013 at 3:51 AM, Minh Nguyen
 wrote:
> On 2013-10-14 10:42 AM, Martijn van Exel wrote:
>>
>> So what are we talking about? Intersections like this one, where one
>> or more dual carriageways come together at an at-grade intersection:
>>
>>
>> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>>
>> One of my colleagues at Telenav has remapped this intersection as follows:
>>
>>
>> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
>>
>> The main difference, and the source of some feedback we have received
>> over the past few days, is that the dual carriageway roads are
>> straightened out, creating multiple intersection nodes (4 in this
>> case) instead of the original single intersection node that connects
>> all the incoming and outgoing ways. That technique turns out to yield
>> more reliable and correct routing and guidance ('keep left, turn
>> right') through these intersections in our testing. But of course,
>> that cannot dictate how we map as a community, so let's discuss.
>
>
> I'm one of the troublemakers who complained about your colleague's edits.
> However, the example you give bears little resemblance to the intersections
> I disagree on. Your "before" screenshot depicts individual lanes (ew) that
> converge into a single-point intersection, even when the main road is
> divided on both sides of the intersection (ew). My quibble relates to
> divided roads that become undivided at an intersection.
>
> Screenshots tell it best, but unfortunately we don't seem to have a tool to
> visualize historical revisions of ways. So I recreated their changes from
> memory in iD (because that's how I roll).
>
>
>
> ** Example A **
>
> Ryans Way and Sycamore Grove Ln. meet Fields Ertel Rd. at the same
> intersection. Fields Ertel is undivided. Ryans Way is briefly divided at the
> subdivision entrance, a very common configuration in newer subdivisions, but
> Sycamore Grove is not.
>
> I mapped the intersection as a single point:
>
> 
>
> Your colleague redrew it as a two-point intersection, dividing the very tip
> of Sycamore Grove (to the south):
>
> 
>
> I prefer the former approach, because the latter shows a false traffic
> island on the south side of the intersection. Imagine a pedantic navigation
> tool that tells a driver coming from Sycamore Grove to "keep/bear right and
> immediately turn left".
>
> ** Example B **
>
> A divided Main St. intersects a divided Remick Blvd. Like everyone else here
> -- and unlike the "before" example Martijn provided -- I prefer a four-point
> intersection. But just to the east, Remick and a service road both become
> undivided at the same intersection. I mapped it as a single point:
>
> 
>
> Your colleague redrew it as a four-point intersection, this time with two
> triangles:
>
> 
>
> ** Example C **
>
> Originally, State Route 4 became undivided at an intersection with Walden
> Ponds Cir. (divided) and Fairham Rd. (undivided). SR 4, with a speed limit
> of at least 45 mph, was redrawn to shuffle about 25 feet to the left right
> after the intersection. But on major roads like SR 4, the landscaped median
> ends several hundred feet before the intersection to make room for a long
> left-turn lane. So I prefer to join the carriageways atop the left-turn
> lane, at a much gentler angle, without cutting into the median.
>
> Since I first mapped the area, the median on SR 4 was extended well past
> this intersection, so no "braiding" was necessary:
>
> 
>
>
>
> In all three examples, my original rendition was called "braiding", but the
> ways were never intertwined as in the much-ridiculed TIGER data.
>
> I don't know what specific issues you found with the way I'd been mapping.
> But I think routers should handle both styles gracefully, because mappers
> will intuitively gravitate towards one or the

Re: [Talk-us] Complex intersection mapping

[Alexander Jones]

James Mast wrote:

> After hands down.  That's how I do intersections like that with one minor
> difference.  If the road on the "right" (as in the example) doesn't have a
> divider, I merge the ways before leaving the intersection so I would have
> 3 traffic light nodes instead of 4.
> 
> -James

That's how I map them.

-Alexander



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martin Koppenhoefer]

2013/10/15 Minh Nguyen 

> ** Example A **
>
> Ryans Way and Sycamore Grove Ln. meet Fields Ertel Rd. at the same
> intersection. Fields Ertel is undivided. Ryans Way is briefly divided at
> the subdivision entrance, a very common configuration in newer
> subdivisions, but Sycamore Grove is not.
>
> I mapped the intersection as a single point:
>
>  intersections/ryans_before.png
> **>
>
> Your colleague redrew it as a two-point intersection, dividing the very
> tip of Sycamore Grove (to the south):
>
>  intersections/ryans_after.png
> >
>
> I prefer the former approach, because the latter shows a false traffic
> island on the south side of the intersection. Imagine a pedantic navigation
> tool that tells a driver coming from Sycamore Grove to "keep/bear right and
> immediately turn left".
>


+1, before is better, after is "false" according to current conventions.



>
> ** Example B **
>
> A divided Main St. intersects a divided Remick Blvd. Like everyone else
> here -- and unlike the "before" example Martijn provided -- I prefer a
> four-point intersection. But just to the east, Remick and a service road
> both become undivided at the same intersection. I mapped it as a single
> point:
>
>  intersections/remick_before.**png
> >
>
> Your colleague redrew it as a four-point intersection, this time with two
> triangles:
>
>  intersections/remick_after.png
> **>
>



again before is better and after is problematic for the reasons you
described. The problem introduced in the after versions  is btw. the same
problem also existent in the after picture that Martijn showed in his
initial post (a single carriageway discharging into a dual carriageway
should not become itself a dual carriageway, in the original posting this
was the way coming from the east/right).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Minh Nguyen]

On 2013-10-14 10:42 AM, Martijn van Exel wrote:

So what are we talking about? Intersections like this one, where one
or more dual carriageways come together at an at-grade intersection:

https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e

One of my colleagues at Telenav has remapped this intersection as follows:

https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92

The main difference, and the source of some feedback we have received
over the past few days, is that the dual carriageway roads are
straightened out, creating multiple intersection nodes (4 in this
case) instead of the original single intersection node that connects
all the incoming and outgoing ways. That technique turns out to yield
more reliable and correct routing and guidance ('keep left, turn
right') through these intersections in our testing. But of course,
that cannot dictate how we map as a community, so let's discuss.


I'm one of the troublemakers who complained about your colleague's 
edits. However, the example you give bears little resemblance to the 
intersections I disagree on. Your "before" screenshot depicts individual 
lanes (ew) that converge into a single-point intersection, even when the 
main road is divided on both sides of the intersection (ew). My quibble 
relates to divided roads that become undivided at an intersection.


Screenshots tell it best, but unfortunately we don't seem to have a tool 
to visualize historical revisions of ways. So I recreated their changes 
from memory in iD (because that's how I roll).




** Example A **

Ryans Way and Sycamore Grove Ln. meet Fields Ertel Rd. at the same 
intersection. Fields Ertel is undivided. Ryans Way is briefly divided at 
the subdivision entrance, a very common configuration in newer 
subdivisions, but Sycamore Grove is not.


I mapped the intersection as a single point:



Your colleague redrew it as a two-point intersection, dividing the very 
tip of Sycamore Grove (to the south):




I prefer the former approach, because the latter shows a false traffic 
island on the south side of the intersection. Imagine a pedantic 
navigation tool that tells a driver coming from Sycamore Grove to 
"keep/bear right and immediately turn left".


** Example B **

A divided Main St. intersects a divided Remick Blvd. Like everyone else 
here -- and unlike the "before" example Martijn provided -- I prefer a 
four-point intersection. But just to the east, Remick and a service road 
both become undivided at the same intersection. I mapped it as a single 
point:




Your colleague redrew it as a four-point intersection, this time with 
two triangles:




** Example C **

Originally, State Route 4 became undivided at an intersection with 
Walden Ponds Cir. (divided) and Fairham Rd. (undivided). SR 4, with a 
speed limit of at least 45 mph, was redrawn to shuffle about 25 feet to 
the left right after the intersection. But on major roads like SR 4, the 
landscaped median ends several hundred feet before the intersection to 
make room for a long left-turn lane. So I prefer to join the 
carriageways atop the left-turn lane, at a much gentler angle, without 
cutting into the median.


Since I first mapped the area, the median on SR 4 was extended well past 
this intersection, so no "braiding" was necessary:






In all three examples, my original rendition was called "braiding", but 
the ways were never intertwined as in the much-ridiculed TIGER data.


I don't know what specific issues you found with the way I'd been 
mapping. But I think routers should handle both styles gracefully, 
because mappers will intuitively gravitate towards one or the other, 
depending on what factors they consider. As intersections go, these 
examples are rather straightforward. On the other hand, I've mapped 
plenty of intersections where the traffic engineers clearly got carried 
away. If someone corrects me on one of those, I'm all ears! :-)






--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[James Mast]

After hands down.  That's how I do intersections like that with one minor 
difference.  If the road on the "right" (as in the example) doesn't have a 
divider, I merge the ways before leaving the intersection so I would have 3 
traffic light nodes instead of 4.

-James
  ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[John F. Eldredge]

Richard Welty  wrote:
> On 10/14/13 1:52 PM, Ian Dees wrote:
> >
> >
> >
> > On Mon, Oct 14, 2013 at 12:42 PM, Martijn van Exel
> > mailto:marti...@telenav.com>> wrote:
> >
> > Hi all,
> >
> > Here at Telenav we have been looking at complex intersections
> and we
> > have set about editing some of these intersections in a way we
> feel
> > represents the situation on the ground better than their
> original
> > state, and because of that, works better for us. We have
> received some
> > feedback on our edits so we wanted to take a step back and see
> what we
> > (as the OSM community) think is the preferred way to map these
> > intersections.
> >
> > So what are we talking about? Intersections like this one, where
> one
> > or more dual carriageways come together at an at-grade
> intersection:
> >
> >
> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
> >
> > One of my colleagues at Telenav has remapped this intersection
> as
> > follows:
> >
> >
> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
> >
> >
> > I've seen more examples of your "after" photo than the "before" in
> my
> > mapping. I create them by default when dual carriageways intersect.
> >
> > +1 you're doing the right thing.
> >
> i consider the "after" a better approach as well.
> 
> richard
> 
> 
> 
> 
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

I agree that the second version is much better.

-- 
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness: 
only light can do that.
Hate cannot drive out hate: only love can do that."
Dr. Martin Luther King, Jr.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Evin Fairchild]

I too prefer the after pattern since it is easier to do, especially when
you are making a road be dual-carriageway by using the "parallel way"
feature in Potlatch 2. Also, it matches the way it is on the ground better.
Since there seems to be unanimous agreement to map intersections this way,
then I'll change other intersections to match.

-Compdude


On Mon, Oct 14, 2013 at 10:42 AM, Martijn van Exel wrote:

> Hi all,
>
> Here at Telenav we have been looking at complex intersections and we
> have set about editing some of these intersections in a way we feel
> represents the situation on the ground better than their original
> state, and because of that, works better for us. We have received some
> feedback on our edits so we wanted to take a step back and see what we
> (as the OSM community) think is the preferred way to map these
> intersections.
>
> So what are we talking about? Intersections like this one, where one
> or more dual carriageways come together at an at-grade intersection:
>
>
> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>
> One of my colleagues at Telenav has remapped this intersection as follows:
>
>
> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
>
> The main difference, and the source of some feedback we have received
> over the past few days, is that the dual carriageway roads are
> straightened out, creating multiple intersection nodes (4 in this
> case) instead of the original single intersection node that connects
> all the incoming and outgoing ways. That technique turns out to yield
> more reliable and correct routing and guidance ('keep left, turn
> right') through these intersections in our testing. But of course,
> that cannot dictate how we map as a community, so let's discuss.
>
> Some of the feedback we have received about these edits points to a
> statement on this wiki page:
> https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
> is a reasonable and well-used technique to bring the ways of dual
> carriageways back to a single point at intersections to facilitate and
> simplify the mapping of control devices and turn restrictions.' In my
> mapping across the US, my personal experience has been that this
> technique is in fact used, but the 'after' technique with straightened
> out ways is actually much more common. I personally prefer that
> technique as well - I think it is more pleasing to the eye, represents
> what is on the ground better, and is and easier to read. So my feeling
> was that this mapping practice would not be disputed. It turns out I
> was wrong, so I want to see what the consensus is on mapping
> intersections of this type - or perhaps there is none and we can work
> together to get there?
>
> Thanks,
> Martijn
> --
> Martijn van Exel
> OSM data specialist
> Telenav
> http://www.osm.org/user/mvexel
> http://wiki.openstreetmap.org/wiki/User:Mvexel
> http://hdyc.neis-one.org/?mvexel
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Stellan Lagerström]

I prefer, and always use, the "after" pattern.

/Stellan

On 2013-10-14 7:42 PM, Martijn van Exel wrote:

Hi all,

Here at Telenav we have been looking at complex intersections and we
have set about editing some of these intersections in a way we feel
represents the situation on the ground better than their original
state, and because of that, works better for us. We have received some
feedback on our edits so we wanted to take a step back and see what we
(as the OSM community) think is the preferred way to map these
intersections.




___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Tod Fitch]

The latter (after) version matches the traffic signal wiki 
http://wiki.openstreetmaps.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways

It makes sense to me and is the way I prefer.

Tod

-- 
Sent from my mobile device. Please excuse my brevity.

Martijn van Exel  wrote:
>Hi all,
>
>Here at Telenav we have been looking at complex intersections and we
>have set about editing some of these intersections in a way we feel
>represents the situation on the ground better than their original
>state, and because of that, works better for us. We have received some
>feedback on our edits so we wanted to take a step back and see what we
>(as the OSM community) think is the preferred way to map these
>intersections.
>
>So what are we talking about? Intersections like this one, where one
>or more dual carriageways come together at an at-grade intersection:
>
>https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>
>One of my colleagues at Telenav has remapped this intersection as
>follows:
>
>https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
>
>The main difference, and the source of some feedback we have received
>over the past few days, is that the dual carriageway roads are
>straightened out, creating multiple intersection nodes (4 in this
>case) instead of the original single intersection node that connects
>all the incoming and outgoing ways. That technique turns out to yield
>more reliable and correct routing and guidance ('keep left, turn
>right') through these intersections in our testing. But of course,
>that cannot dictate how we map as a community, so let's discuss.
>
>Some of the feedback we have received about these edits points to a
>statement on this wiki page:
>https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
>is a reasonable and well-used technique to bring the ways of dual
>carriageways back to a single point at intersections to facilitate and
>simplify the mapping of control devices and turn restrictions.' In my
>mapping across the US, my personal experience has been that this
>technique is in fact used, but the 'after' technique with straightened
>out ways is actually much more common. I personally prefer that
>technique as well - I think it is more pleasing to the eye, represents
>what is on the ground better, and is and easier to read. So my feeling
>was that this mapping practice would not be disputed. It turns out I
>was wrong, so I want to see what the consensus is on mapping
>intersections of this type - or perhaps there is none and we can work
>together to get there?
>
>Thanks,
>Martijn
>--
>Martijn van Exel
>OSM data specialist
>Telenav
>http://www.osm.org/user/mvexel
>http://wiki.openstreetmap.org/wiki/User:Mvexel
>http://hdyc.neis-one.org/?mvexel
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Saikrishna Arcot]

To expand on the point of having both methods used, starting with the 
multiple intersection points method, what if all four intersection 
points were under a relation of a group of intersections, and the 
number of lanes on each way was marked? That way, routing algorithms 
could convert from the visually-friendly method to the individual lane 
and single intersection point method.

Saikrishna Arcot

On Mon 14 Oct 2013 05:28:28 PM EDT, Martin Koppenhoefer wrote:
>
> 2013/10/14 stevea  >
>
> Hi Martijn:  one thing "wrong" I do see at this particular
> intersection are extraneous nodes with highway=crossing tags:  two
> extra ones on the (northerly) east-west ped-path and one extra one
> each of the (westerly and easterly) north-south ped-paths.  A
> fairly minor error in the context of your larger question.
>
>
>
> +1, and another thing: the street coming from the right should not be
> expanded to a dual carriageway at the point where your colleague has
> done it, but rather at the latest possible point (i.e. at the first
> insection with the N-S-road) if doing it this way.
>
> cheers,
> Martin
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martin Koppenhoefer]

2013/10/14 stevea 

> Hi Martijn:  one thing "wrong" I do see at this particular intersection
> are extraneous nodes with highway=crossing tags:  two extra ones on the
> (northerly) east-west ped-path and one extra one each of the (westerly and
> easterly) north-south ped-paths.  A fairly minor error in the context of
> your larger question.



+1, and another thing: the street coming from the right should not be
expanded to a dual carriageway at the point where your colleague has done
it, but rather at the latest possible point (i.e. at the first insection
with the N-S-road) if doing it this way.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[stevea]

So what are we talking about? Intersections like this one, where one
or more dual carriageways come together at an at-grade intersection:

https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e

One of my colleagues at Telenav has remapped this intersection as follows:

https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92


Hi Martijn:  one thing "wrong" I do see at this particular 
intersection are extraneous nodes with highway=crossing tags:  two 
extra ones on the (northerly) east-west ped-path and one extra one 
each of the (westerly and easterly) north-south ped-paths.  A fairly 
minor error in the context of your larger question.



The main difference, and the source of some feedback we have received
over the past few days, is that the dual carriageway roads are
straightened out, creating multiple intersection nodes (4 in this
case) instead of the original single intersection node that connects
all the incoming and outgoing ways. That technique turns out to yield
more reliable and correct routing and guidance ('keep left, turn
right') through these intersections in our testing. But of course,
that cannot dictate how we map as a community, so let's discuss.


I do this myself on intersections which have complex "two-to-one" 
lane collapses in one direction, or "two-to-three" lane expansions in 
another direction, or even both.  I agree with you that making lanes 
which capture dual carriageway and multiple lanes like this 
accurately represents what is on the ground better, is pleasing to 
the eye both in an OSM editor and on an OSM rendering, AND likely 
results in better routing algorithm results (e.g. for offering turn 
directions).  The wiki entry on Braided Streets notwithstanding.



Some of the feedback we have received about these edits points to a
statement on this wiki page:
https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
is a reasonable and well-used technique to bring the ways of dual
carriageways back to a single point at intersections to facilitate and
simplify the mapping of control devices and turn restrictions.' In my
mapping across the US, my personal experience has been that this
technique is in fact used, but the 'after' technique with straightened
out ways is actually much more common. I personally prefer that
technique as well - I think it is more pleasing to the eye, represents
what is on the ground better, and is and easier to read. So my feeling
was that this mapping practice would not be disputed. It turns out I
was wrong, so I want to see what the consensus is on mapping
intersections of this type - or perhaps there is none and we can work
together to get there?


I don't know what the solution is.  It may be to coexist with BOTH 
types and try to do the best that can be done by "smartening up" 
routing algorithms to cope with EACH type of intersection as well as 
can be technically achieved.  That seems "long-term wise" given that 
there will likely be both types of intersections entered into the 
underlying data.


SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martin Koppenhoefer]

2013/10/14 Martijn van Exel 

> So what are we talking about? Intersections like this one, where one
> or more dual carriageways come together at an at-grade intersection:
>
>
> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>
>

I think it is not only ugly and confusing but also pointless. If you insist
on distinguishing between physically separated / not separated carriageways
in the area of a crossing, it would be more straightforward (and a little
bit less confusing) to map this as in the attached screenshot.




> One of my colleagues at Telenav has remapped this intersection as follows:
>
>
> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
>


this is how we usually do in around here (Europe).

cheers,
Martin
<>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Richard Welty]

On 10/14/13 1:52 PM, Ian Dees wrote:
>
>
>
> On Mon, Oct 14, 2013 at 12:42 PM, Martijn van Exel
> mailto:marti...@telenav.com>> wrote:
>
> Hi all,
>
> Here at Telenav we have been looking at complex intersections and we
> have set about editing some of these intersections in a way we feel
> represents the situation on the ground better than their original
> state, and because of that, works better for us. We have received some
> feedback on our edits so we wanted to take a step back and see what we
> (as the OSM community) think is the preferred way to map these
> intersections.
>
> So what are we talking about? Intersections like this one, where one
> or more dual carriageways come together at an at-grade intersection:
>
> 
> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>
> One of my colleagues at Telenav has remapped this intersection as
> follows:
>
> 
> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
>
>
> I've seen more examples of your "after" photo than the "before" in my
> mapping. I create them by default when dual carriageways intersect.
>
> +1 you're doing the right thing.
>
i consider the "after" a better approach as well.

richard



signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Ian Dees]

On Mon, Oct 14, 2013 at 12:42 PM, Martijn van Exel wrote:

> Hi all,
>
> Here at Telenav we have been looking at complex intersections and we
> have set about editing some of these intersections in a way we feel
> represents the situation on the ground better than their original
> state, and because of that, works better for us. We have received some
> feedback on our edits so we wanted to take a step back and see what we
> (as the OSM community) think is the preferred way to map these
> intersections.
>
> So what are we talking about? Intersections like this one, where one
> or more dual carriageways come together at an at-grade intersection:
>
>
> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>
> One of my colleagues at Telenav has remapped this intersection as follows:
>
>
> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92


I've seen more examples of your "after" photo than the "before" in my
mapping. I create them by default when dual carriageways intersect.

+1 you're doing the right thing.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us