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

Wed Oct 14 14:55:35 BST 2009

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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20091014/1d0e6f9a/attachment.html 