[PATCH v3] heed the through_route relation when adjusting turn headings

v3 - bug fixes: now ignores through_route relations if the junction is outside of the tile's bounding box should no longer think that ways that have been split do not start or end at the junction. -------------------- v2 - no longer requires the node to have role "junction" This patch also includes two other changes to the heading adjustment code: When matching arcs, as a last resort, match road class and speed. If at a node, an outgoing arc cannot be matched to an incoming arc by possiblySameRoad(), try to find a single outgoing arc that has the same road class and speed as the incoming arc and use that. and: When adjusting turn headings apply all relevant adjustments. Previously, if a heading needed adjusting because the delta from the outgoing arc was too small, it did not then consider whether the delta from the incoming arc was too small also. Now, it considers both cases and adjusts the heading as appropriate. So please test even if you are not adding any through_route relations and if you see any notable changes (good or bad) please say. -------------------- This new relation (type through_route) specifies which 2 ways are the "through route" at a junction. The relation requires 2 ways (no role required) and a node with role = junction. It should only be used at those junctions where the through route cannot be reliably inferred from the ways' names and/or refs. Here's an example from my local town: | 1 | / | / |/ A | | | | B /| / | / | 2 | The vertical road is the "through route", i.e. you can drive from one end to the other without crossing any white lines. But, from point 1 to point 2 is a B road so ways 1-A, A-B, and B-2 all have some ref, say, B1234. Without the through_route relation, mkgmap assumes (erroneously) that the through route is 1-2 because all of the ways in that route have the ref B1234. By adding 2 through_route relations (one at A and the other at B), mkgmap is informed of the real through route and will take that into account when adjusting the turn headings. The end result is that the quality of the routing directions is improved (we hope). In this example, we need to have 2 relations because the B road joins/leaves the through route at two places. So if you know of any junctions that would benefit from this relation, please add it to the map data and try this patch to see if it improves the routing instructions. Mark

Mark Burton wrote:
v3 - bug fixes:
now ignores through_route relations if the junction is outside of the tile's bounding box
should no longer think that ways that have been split do not start or end at the junction.
Mark - I've been giving the 'through_route' patch a bit of use, and I must say it does a great job of allowing the mapper to 'fix' those annoying junctions where there was no way for mkgmap to decide the road priority. I have a couple of issues still, and a few suggestions: 1) Could you arrange for mkgmap to honour the "continuity" of a drawn way? In other words, if a way with a given name has a bend in it, and a stub of the same road class and same road name makes a "T" junction with it, then assume that the continuously-drawn way is the through-route? Here's an example: http://www.openstreetmap.org/?mlat=51.577273&mlon=-4.041473&zoom=17&layers=B... ..if you drive south-east on Kilfield Road, then as you approach the marker you'll be told to "turn right" where really the entire length of Kilfield Road is drawn as a single way, with the smaller stub being another way in its own right. I don't know about other mappers, but I know a *lot* of cases (mostly in residential areas) where a long curve of road had small stubs sticking off it, and they'll all generate bogus instructions if this isn't dealt with. 2) Can we invent some way to mark up traffic lanes? Here's a case in point: http://www.openstreetmap.org/?mlat=51.61219&mlon=-3.961323&zoom=18&layers=B0... You probably want to look at the area in Potlatch to see what's happening. Yes - I know I'm probably rather stretching the rules here, but the idea was that if a driver approaches on the A4067 from the east, wanting to take the right turn onto the stub of B4290 and thence to follow the B4290 towards the northeast, then he'd get a "keep right" instruction about 150m before the junction itself (that's where a dedicated traffic lane starts) and then get a "turn right" at the junction itself, followed by another "turn right" 30m later to the north as he joins the northeast-bound B4290. It used to work like that, but now I get a "turn right" (not "keep right") at 150m short of the junction because the heading of the junction has been tweaked. If we could mark up traffic lanes it might allow you to maintain that useful "keep right" where the lane branches off. Additionally, one day we might find how "lane assist" works in Garmin maps and be able to code for it properly. I wonder if marking a lane like this one as "highway=primary" "primary=traffic_lane" "ref=A4076" (etc) would be useful and desirable and would you be able to handle it anyway? Steve

Hi Steve, Thanks for the feedback.
Mark - I've been giving the 'through_route' patch a bit of use, and I must say it does a great job of allowing the mapper to 'fix' those annoying junctions where there was no way for mkgmap to decide the road priority.
Good.
I have a couple of issues still, and a few suggestions:
1) Could you arrange for mkgmap to honour the "continuity" of a drawn way? In other words, if a way with a given name has a bend in it, and a stub of the same road class and same road name makes a "T" junction with it, then assume that the continuously-drawn way is the through-route? Here's an example:
http://www.openstreetmap.org/?mlat=51.577273&mlon=-4.041473&zoom=17&layers=B...
..if you drive south-east on Kilfield Road, then as you approach the marker you'll be told to "turn right" where really the entire length of Kilfield Road is drawn as a single way, with the smaller stub being another way in its own right. I don't know about other mappers, but I know a *lot* of cases (mostly in residential areas) where a long curve of road had small stubs sticking off it, and they'll all generate bogus instructions if this isn't dealt with.
I have just tried routing on that road and mapsource did not give me a "turn right" at that junction. However, I have tweaked the code as it could get confused as to which is the through route as all the roads at that junction have the same name. So now the one-piece road will take precedence over the stub even though they have the same name. I will post a new patch shortly, please see if it does the right thing there.
2) Can we invent some way to mark up traffic lanes? Here's a case in point:
http://www.openstreetmap.org/?mlat=51.61219&mlon=-3.961323&zoom=18&layers=B0...
You probably want to look at the area in Potlatch to see what's happening. Yes - I know I'm probably rather stretching the rules here, but the idea was that if a driver approaches on the A4067 from the east, wanting to take the right turn onto the stub of B4290 and thence to follow the B4290 towards the northeast, then he'd get a "keep right" instruction about 150m before the junction itself (that's where a dedicated traffic lane starts) and then get a "turn right" at the junction itself, followed by another "turn right" 30m later to the north as he joins the northeast-bound B4290.
It used to work like that, but now I get a "turn right" (not "keep right") at 150m short of the junction because the heading of the junction has been tweaked. If we could mark up traffic lanes it might allow you to maintain that useful "keep right" where the lane branches off. Additionally, one day we might find how "lane assist" works in Garmin maps and be able to code for it properly.
I wonder if marking a lane like this one as "highway=primary" "primary=traffic_lane" "ref=A4076" (etc) would be useful and desirable and would you be able to handle it anyway?
This is a difficult situation to handle. A problem is that if you don't tweak the heading for the link road you will then get "keep left" instructions for each exit you approach. It currently does a good job of not telling you to "keep left" on motorways and trunk roads and I would prefer that it stays that way. More thought required... Cheers, Mark

Mark Burton wrote:
..if you drive south-east on Kilfield Road...
I have just tried routing on that road and mapsource did not give me a "turn right" at that junction. However, I have tweaked the code as it could get confused as to which is the through route as all the roads at that junction have the same name.
Yeah, exactly. And I can show you quite a few other residential roads where the same thing happens.
So now the one-piece road will take precedence over the stub even though they have the same name. I will post a new patch shortly, please see if it does the right thing there.
If that comes up today, I can test it tonight. Thanks in advance.
2) Can we invent some way to mark up traffic lanes [...] one day we might find how "lane assist" works in Garmin maps and be able to code for it properly.
I wonder if marking a lane like this one as "highway=primary" "primary=traffic_lane" "ref=A4076" (etc) would be useful and desirable and would you be able to handle it anyway?
This is a difficult situation to handle. A problem is that if you don't tweak the heading for the link road you will then get "keep left" instructions for each exit you approach. It currently does a good job of not telling you to "keep left" on motorways and trunk roads and I would prefer that it stays that way. No argument there. That's why I suggest some sort of mark-up for the traffic lanes situation. It's a special-case, and another thing the mark-up would help with is to fix the complaints that "keepright" gives for junctions like that.
Now, there probably is an attitude out there that I shouldn't be doing this in the first place, but on approaching complex multi-lane junctions it would be good for the GPS to generate "get in lane" instructions. The "official" maps often do, and we should too if our maps are to be considered seriously. If we do generate mark-up, we'll need to invent something that's GPS-independent of course, so it can be used by the Android and TomTom and other map projects out there.
More thought required...
Yup! Steve

Mark Burton wrote:
Hi Steve,
If that comes up today, I can test it tonight. Thanks in advance.
A v4 patch was posted yesterday, here it is again.
I wasn't paying attention - you're quite right, it was already posted. Whatever - I tried it last night and it was fine. Thank you. Unless you know better, I'd say it was time or nearly time to merge that branch back to trunk. The only slightly odd behaviour for me is at: http://www.openstreetmap.org/?mlat=51.612512&mlon=-3.961642&zoom=18&layers=B... ..where, if I approach on the southern stub from the traffic lights on Oystermouth Rd (A4067) I'd expect to be told "turn right" onto the oneway section of B4290. But I get no announcement. That northeasterly-bound section of B4290 isn't a single way because of bus-route issues, but I made a "through_route" relation to span across the junction "just in case". It made no difference. Steve

Hi Steve,
Unless you know better, I'd say it was time or nearly time to merge that branch back to trunk.
Agreed.
The only slightly odd behaviour for me is at: http://www.openstreetmap.org/?mlat=51.612512&mlon=-3.961642&zoom=18&layers=B...
..where, if I approach on the southern stub from the traffic lights on Oystermouth Rd (A4067) I'd expect to be told "turn right" onto the oneway section of B4290. But I get no announcement.
That northeasterly-bound section of B4290 isn't a single way because of bus-route issues, but I made a "through_route" relation to span across the junction "just in case". It made no difference.
But as a left turn isn't actually allowed there, perhaps the GPS doesn't bother to tell you to turn right as it "knows" you can't turn left? Cheers, Mark

Mark Burton wrote:
That northeasterly-bound section of B4290 isn't a single way because of bus-route issues, but I made a "through_route" relation to span across the junction "just in case". It made no difference.
But as a left turn isn't actually allowed there, perhaps the GPS doesn't bother to tell you to turn right as it "knows" you can't turn left?
Don't think so. On a different junction last night I got told to turn left on joining a dual-carriageway from a side road when there was no alternative. Steve
participants (2)
-
Mark Burton
-
Steve Hosgood