Anyone tried the arc tweezing patches?
I have received zero feedback on the recent arc tweezing patch. I believe that in its latest form (v4), it provides much improved routing instruction quality. In particular, it should give you fewer instructions to keep left/right or even turn left/right when you are continuing on a long road (like a motorway) that has various roads that branch off of it. So please do try it out if you can and report success/failure, etc. Thanks, Mark
Mark Burton wrote:
I have received zero feedback on the recent arc tweezing patch. I believe that in its latest form (v4), it provides much improved routing instruction quality. In particular, it should give you fewer instructions to keep left/right or even turn left/right when you are continuing on a long road (like a motorway) that has various roads that branch off of it. So please do try it out if you can and report success/failure, etc.
I will try it out, I thought the patch was meant more for giving you turn right/left instead of keep right/left instructions (thus increasing the angle). I would like to have the angle decreased (well not) instead of any increases, will look into the patch again and try to understand it better to see if it I can use it (in case that it works which I do expect knowing the effects that angle has onto routing)....
Thanks,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark Burton wrote:
I have received zero feedback on the recent arc tweezing patch. I believe that in its latest form (v4), it provides much improved routing instruction quality. In particular, it should give you fewer instructions to keep left/right or even turn left/right when you are continuing on a long road (like a motorway) that has various roads that branch off of it. So please do try it out if you can and report success/failure, etc.
Thanks,
Mark _______________________________________________
Hi Mark, Okay, I have played around now over 1 hour in Mapsource (allways creating two identical route start/endpoints and calculating with two maps identical if not for the tweeze arc patch and then comparing the choses routes) and just quickly rechecked that my Vista HCx behaves the same (and of course it does). So yes it is a good start, when routing with "faster time" the difference of ways chosen is very similar, with "shorter distance" one really starts to see the changes: Usually with the patch distance is about 1-2% shorter and a bit more direct. There are of course the odd cases when one route will be instead of 50km, 80km km long but this of course is inherent if one route takes a "motorway" making a big detour, while the other route is going for smaller streets on shorter distance. Calculated arrival time averages out pretty well (well a tiny bit faster with the patch on average) Overall I think the patch helps to iron out the "huge" time penalties garmin puts on small angles, and routing instructions get better too. Especially it irons decreases a bit the huge difference one might get when inverting a route. I would much prefer however if the original roads stay untouched and instead additional junction roads with small angle created instead as discussed previously. This could then even be adjusted so far, that you could set up time penalties depending on whether you go from primary to residential road (bigger time penalty, as you need to break) vs residential to primary road on the same junction in inverse direction (smaller time penalty, as on residential road you travelled slower and therefore do not need to lower speed so much) or even by deleting the original roads and inserting only new "junction roads" create time penalties for say traffic lights even when going straight instead of changing the road_speed of the whole road section that you can influence with the poi +- option.
Hi Felix, Many thanks for the report - comments inline.
Okay, I have played around now over 1 hour in Mapsource (allways creating two identical route start/endpoints and calculating with two maps identical if not for the tweeze arc patch and then comparing the choses routes) and just quickly rechecked that my Vista HCx behaves the same (and of course it does).
So yes it is a good start, when routing with "faster time" the difference of ways chosen is very similar, with "shorter distance" one really starts to see the changes: Usually with the patch distance is about 1-2% shorter and a bit more direct. There are of course the odd cases when one route will be instead of 50km, 80km km long but this of course is inherent if one route takes a "motorway" making a big detour, while the other route is going for smaller streets on shorter distance. Calculated arrival time averages out pretty well (well a tiny bit faster with the patch on average)
Overall I think the patch helps to iron out the "huge" time penalties garmin puts on small angles, and routing instructions get better too. Especially it irons decreases a bit the huge difference one might get when inverting a route.
That's all very interesting.
I would much prefer however if the original roads stay untouched and instead additional junction roads with small angle created instead as discussed previously.
The problem with leaving the arc headings of side roads untouched (certainly from the point of view of car routing) is that when the angle is too shallow (approx less than 40 deg) the GPS doesn't recognise it as a turn and often just tells you to keep left/right when you're routing down the main road or taking the turn. This is especially noticeable on motorways when sometimes it would tell you to keep right/left when passing a junction or even, take the exit, go around the exit roundabout and go back onto the motorway and carry on. The fundamental problem here is that there is no way (that we know of) to tell the GPS that some arcs are related (i.e. they are for the same road) and other arcs represent other roads. True, some arcs will share a RoadDef object and that coupling does get indicated to the GPS but, often, arcs that are for segments of a particular road will not share a RoadDef object and, therefore, the GPS doesn't have a clue that they are for the same road. So when it comes to providing the routing directions, the only info it has to go on is the arc headings.
This could then even be adjusted so far, that you could set up time penalties depending on whether you go from primary to residential road (bigger time penalty, as you need to break) vs residential to primary road on the same junction in inverse direction (smaller time penalty, as on residential road you travelled slower and therefore do not need to lower speed so much) or even by deleting the original roads and inserting only new "junction roads" create time penalties for say traffic lights even when going straight instead of changing the road_speed of the whole road section that you can influence with the poi +- option.
I know what you want to try out as it's been discussed before. I'm not convinced it will be beneficial but at least now there's more infrastructure in place to bring it a step closer to happening. Tell me, if you add the extra arcs that have the small (or even zero) exit angle how do you expect the GPS to tell you to route? Cheers, Mark
Mark Burton wrote:
Hi Felix,
Many thanks for the report - comments inline.
Okay, I have played around now over 1 hour in Mapsource (allways creating two identical route start/endpoints and calculating with two maps identical if not for the tweeze arc patch and then comparing the choses routes) and just quickly rechecked that my Vista HCx behaves the same (and of course it does).
So yes it is a good start, when routing with "faster time" the difference of ways chosen is very similar, with "shorter distance" one really starts to see the changes: Usually with the patch distance is about 1-2% shorter and a bit more direct. There are of course the odd cases when one route will be instead of 50km, 80km km long but this of course is inherent if one route takes a "motorway" making a big detour, while the other route is going for smaller streets on shorter distance. Calculated arrival time averages out pretty well (well a tiny bit faster with the patch on average)
Overall I think the patch helps to iron out the "huge" time penalties garmin puts on small angles, and routing instructions get better too. Especially it irons decreases a bit the huge difference one might get when inverting a route.
That's all very interesting.
Forgot to say, if you change to "truck" in the routing options, effects are much more drastic
I would much prefer however if the original roads stay untouched and instead additional junction roads with small angle created instead as discussed previously.
The problem with leaving the arc headings of side roads untouched (certainly from the point of view of car routing) is that when the angle is too shallow (approx less than 40 deg) the GPS doesn't recognise it as a turn and often just tells you to keep left/right when you're routing down the main road or taking the turn. This is especially noticeable on motorways when sometimes it would tell you to keep right/left when passing a junction or even, take the exit, go around the exit roundabout and go back onto the motorway and carry on.
The fundamental problem here is that there is no way (that we know of) to tell the GPS that some arcs are related (i.e. they are for the same road) and other arcs represent other roads. True, some arcs will share a RoadDef object and that coupling does get indicated to the GPS but, often, arcs that are for segments of a particular road will not share a RoadDef object and, therefore, the GPS doesn't have a clue that they are for the same road. So when it comes to providing the routing directions, the only info it has to go on is the arc headings.
There is an angle (don't ask me how much, I'ld guess about 25°) and if it is larger then you get the notice. And also we can trick the GPS into believing to no change the road when it changes the road, see below.
This could then even be adjusted so far, that you could set up time penalties depending on whether you go from primary to residential road (bigger time penalty, as you need to break) vs residential to primary road on the same junction in inverse direction (smaller time penalty, as on residential road you travelled slower and therefore do not need to lower speed so much) or even by deleting the original roads and inserting only new "junction roads" create time penalties for say traffic lights even when going straight instead of changing the road_speed of the whole road section that you can influence with the poi +- option.
I know what you want to try out as it's been discussed before. I'm not convinced it will be beneficial but at least now there's more infrastructure in place to bring it a step closer to happening.
Tell me, if you add the extra arcs that have the small (or even zero) exit angle how do you expect the GPS to tell you to route?
That is easy, have a look at my testmap from here: http://openmtbmap.x-nation.de/maps/legend.zip (inside you find the map in osm format) and here you can find it compiled: http://openmtbmap.x-nation.de/maps/mtblegend.7z.zip Have a look at the "cross" in the south of the map. Here you can see the two possible approaches on how it works, by rechecking with JOSM on how the streets are arranged. The way that is used when going from North to East without any time penalty at all (though it does tell you to turn!) would have to be realised as two opposing oneways so that you get the proper streetname announced. When going from W to S or reverse you notice the small angle is only sufficient to tell you keep on (but it already tells you the name of the new street!). If you increase the joining angle, you will notice it changing from keep to turn. If you play around a bit on the top you will notice how it works. I first did not understand it either, but playing with the testmap and changing the angles with JOSM I started to understand it more clearly. 1. If angle is below X (I think around 15°) then no turn announcement is given but "keep" 2. If angle is 0° then you are not even notified that you are changing the street, nor is there a time penalty! - This would be the easies to implement, as you would simply need to add some points on the old ways to get rid of the time penalty, but will be kinda strange as you have to turn without getting notified. 2. is the insteresting part. To setup the extra roads you have to depart from the old street with 0° (no notice, nothing) This has to be done from the new street too. The angle with which those two artificial streets now meet is the crucial part for routing. So the easy implementation is just make all angles 20° from both directions to decrease time penalties (this would be the best setting for cycle/foot autorouting) The more advanced would be to set that angle depending on the streets joining to different values, and even increase it (with opposing oneways to get different time penalties per direction) based on junction.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark Burton schreef:
I have received zero feedback on the recent arc tweezing patch.
Ehrm, eh, yes. Whatever destination I have in mind lately, I always seem to end up in the baby room. There's no computer there, you know. Anyway, tested your patch and it shows a huge improvement on a couple of weird routes I've come across so far. Like this one: http://www.yournavigation.org/?flat=52.445382&flon=4.80525&tlat=52.404858&tl... ... where the Nuvi sent me all around on a 30km journey, it now has quite a decent route, roughly comparable to the yournavigation.org one. The improvement seems especially visible with the "shortest route" setting; shortest time seems less affected (but I could be wrong here). (And I'm testing bicycle routing here, which cannot work correctly by design as has been pointed out on the list before). I did not find any broken routes ("failure" as you call it). As your patch is now in my mkgmap, I will test some more and I shall report any oddities. Best regards, Valentijn
Hi Valentijn, Thanks for the report. On Wed, 14 Oct 2009 17:00:55 +0200 Valentijn Sessink <valentyn@blub.net> wrote:
Mark Burton schreef:
I have received zero feedback on the recent arc tweezing patch.
Ehrm, eh, yes. Whatever destination I have in mind lately, I always seem to end up in the baby room. There's no computer there, you know.
Anyway, tested your patch and it shows a huge improvement on a couple of weird routes I've come across so far. Like this one: http://www.yournavigation.org/?flat=52.445382&flon=4.80525&tlat=52.404858&tl...
... where the Nuvi sent me all around on a 30km journey, it now has quite a decent route, roughly comparable to the yournavigation.org one.
Good.
The improvement seems especially visible with the "shortest route" setting; shortest time seems less affected (but I could be wrong here). (And I'm testing bicycle routing here, which cannot work correctly by design as has been pointed out on the list before).
Yes, Felix also noted that the shortest route routing appeared to be improved more than quickest route. I have to say that I had only tested it using quickest route.
I did not find any broken routes ("failure" as you call it). As your patch is now in my mkgmap, I will test some more and I shall report any oddities.
Thanks, that would be good. Cheers, Mark
How shall I merge this, it is conflicting - when using the patch version mkgmap does not compile. *mine* if("roundabout".equals(way.getTag("junction"))) road.setRoundabout(true); road.setLinkRoad(gt.getType() == 0x08 || gt.getType() == 0x09); // set road parameters. road.setRoadClass(gt.getRoadClass()); if (way.isBoolTag("oneway")) { road.setDirection(true); road.setOneway(); * patch version:* // set road parameters // road class (can be overriden by mkgmap:road-class tag) int roadClass = gt.getRoadClass(); String val = way.getTag("mkgmap:road-class"); if(val != null) { if(val.startsWith("-")) { roadClass -= Integer.decode(val.substring(1)); } else if(val.startsWith("+")) { roadClass += Integer.decode(val.substring(1)); } else { roadClass = Integer.decode(val); } int roadClassMax = 4; int roadClassMin = 0; val = way.getTag("mkgmap:road-class-max"); if(val != null) roadClassMax = Integer.decode(val); val = way.getTag("mkgmap:road-class-min"); if(val != null) roadClassMin = Integer.decode(val); if(roadClass > roadClassMax) roadClass = roadClassMax; else if(roadClass < roadClassMin) roadClass = roadClassMin; log.info("POI changing road class of " + way.getName() + " (" + way.getId() + ") to " + roadClass + " at " + points.get(0));
Felix,
How shall I merge this, it is conflicting - when using the patch version mkgmap does not compile.
Attached is a version of the patch that applies on top of the tweeze arcs patch. It would be good to commit the tweeze arcs patch as it affects quite a few files and makes it difficult to test other new stuff. Are you happy that the tweeze arcs stuff doesn't actually break anything (compared to before)? If so, I shall commit it in its present form. If the functionality is considered OK, I could also commit the delete tags patch and the set road params from POI patches as well because all of these features can be disabled by the user. Mark
Mark Burton wrote:
Felix,
How shall I merge this, it is conflicting - when using the patch version mkgmap does not compile.
Attached is a version of the patch that applies on top of the tweeze arcs patch.
It would be good to commit the tweeze arcs patch as it affects quite a few files and makes it difficult to test other new stuff.
Are you happy that the tweeze arcs stuff doesn't actually break anything (compared to before)? If so, I shall commit it in its present form Better than the status quo, so would support committing it (and also for a merge of the mdr branch into trunk, because at some point this has to be done) .
If the functionality is considered OK, I could also commit the delete tags patch and the set road params from POI patches as well because all of these features can be disabled by the user.
Yip, both very very practical!
Mark
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
Are you happy that the tweeze arcs stuff doesn't actually break anything (compared to before)? If so, I shall commit it in its present form Better than the status quo, so would support committing it (and also for a merge of the mdr branch into trunk, because at some point this has to be done) .
If the functionality is considered OK, I could also commit the delete tags patch and the set road params from POI patches as well because all of these features can be disabled by the user.
Yip, both very very practical!
OK - I will commit these three patches. As for the mdr branch, that's Steve's baby so it's best left to him to merge that back into trunk (shouldn't be too difficult given that it's mostly new classes). Mark
Mark Burton wrote:
Felix,
Are you happy that the tweeze arcs stuff doesn't actually break anything (compared to before)? If so, I shall commit it in its present form
Better than the status quo, so would support committing it (and also for a merge of the mdr branch into trunk, because at some point this has to be done)
.
If the functionality is considered OK, I could also commit the delete tags patch and the set road params from POI patches as well because all of these features can be disabled by the user.
Yip, both very very practical!
OK - I will commit these three patches.
Could you commit the "continue" patch too?
As for the mdr branch, that's Steve's baby so it's best left to him to merge that back into trunk (shouldn't be too difficult given that it's mostly new classes).
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Felix Hartmann -
Mark Burton -
Valentijn Sessink