[mkgmap-dev] Anyone tried the arc tweezing patches?

Wed Oct 14 12:58:21 BST 2009

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