Re: [Talk-us] Complex intersection mapping
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 rickmastfa...@hotmail.com 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,
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 rickmastfa...@hotmail.com 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
was that this mapping practice would not be disputed. It turns out I
was wrong, so I want to see what the
Re: [Talk-us] Complex intersection mapping
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
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 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
Re: [Talk-us] Complex intersection mapping
On Tue, Oct 15, 2013 at 10:52 PM, Russ Nelson nel...@crynwr.com 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
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
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
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:
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/ryans_before.png
Your colleague redrew it as a two-point intersection, dividing the very
tip of Sycamore Grove (to the south):
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_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.
** 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:
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/remick_before.png
Your colleague redrew it as a four-point intersection, this time with
two triangles:
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/remick_after.png
** 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:
http://osm.org/browse/way/24089
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! :-)
http://osm.org/browse/relation/1843583
http://osm.org/browse/relation/1284976
http://osm.org/go/ZR~9kObUM
--
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
2013/10/15 Minh Nguyen m...@nguyen.cincinnati.oh.us ** 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: http://nguyen.cincinnati.oh.**us/minh/osm/talk-us/braided_** intersections/ryans_before.pnghttp://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/ryans_before.png ** Your colleague redrew it as a two-point intersection, dividing the very tip of Sycamore Grove (to the south): http://nguyen.cincinnati.oh.**us/minh/osm/talk-us/braided_** intersections/ryans_after.pnghttp://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_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: http://nguyen.cincinnati.oh.**us/minh/osm/talk-us/braided_** intersections/remick_before.**pnghttp://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/remick_before.png Your colleague redrew it as a four-point intersection, this time with two triangles: http://nguyen.cincinnati.oh.**us/minh/osm/talk-us/braided_** intersections/remick_after.pnghttp://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_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
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
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
m...@nguyen.cincinnati.oh.us 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:
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/ryans_before.png
Your colleague redrew it as a two-point intersection, dividing the very tip
of Sycamore Grove (to the south):
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_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.
** 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:
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/remick_before.png
Your colleague redrew it as a four-point intersection, this time with two
triangles:
http://nguyen.cincinnati.oh.us/minh/osm/talk-us/braided_intersections/remick_after.png
** 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:
http://osm.org/browse/way/24089
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
Re: [Talk-us] Complex intersection mapping
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
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
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 stevea...@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. 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
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 stevea...@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@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://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complex intersection mapping
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 saiarcot...@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 stevea...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org
Re: [Talk-us] Complex intersection mapping
On Mon, Oct 14, 2013 at 12:42 PM, Martijn van Exel marti...@telenav.comwrote: 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
Re: [Talk-us] Complex intersection mapping
On 10/14/13 1:52 PM, Ian Dees wrote: On Mon, Oct 14, 2013 at 12:42 PM, Martijn van Exel marti...@telenav.com 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
2013/10/14 Martijn van Exel marti...@telenav.com 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 attachment: josm-dualcarriageway.jpg___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complex intersection mapping
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
2013/10/14 stevea stevea...@softworkers.com 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
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 stevea...@softworkers.com mailto:stevea...@softworkers.com 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
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 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
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
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
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 marti...@telenav.comwrote:
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
Richard Welty rwe...@averillpark.net wrote: On 10/14/13 1:52 PM, Ian Dees wrote: On Mon, Oct 14, 2013 at 12:42 PM, Martijn van Exel marti...@telenav.com 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
