Oh - I could not find out about any preference of avoidances yes/no. I am
under the assumption paved/unpaved, toll yes/no and so on are really simply
strict yes/no criteria - but otherwise irrelevant.
On 7 September 2015 at 11:29, Felix Hartmann <***@gmail.com>
wrote:
> Yes - there is no different time penalty based on road class. It's just
> that motorcar is much more focusing on them than any other mode and I would
> guess besides the penalties there are some other factors that only start
> to be considered on longer routes. And most of the difference for vehicles
> only appear on longer distances - which makes assessing differences really
> difficult.
>
> On 7 September 2015 at 11:20, Gerd Petermann <
> ***@hotmail.com> wrote:
>
>> Hi Felix,
>>
>> forgot to mention that I found no prove that the road class has an impact
>> on the penalty,
>> in other words: I found no relation between road class and calculated
>> travel time when the
>> road speed is the same.
>> Maybe this is different for longer routes, my test contains just for arcs
>> with the 2nd and 3rd
>> building the sharp angle. My test scenario doesn't allow to use other
>> roads.
>>
>> Reg. different vehicles:
>> I guess that they have different preferences regarding paved/unpaved
>> roads, maybe also
>> regarding road class. And maybe the penalties differ also.
>>
>> I'm now working out how the left turns differ from right turns.
>>
>> Gerd
>>
>> ------------------------------
>> Date: Mon, 7 Sep 2015 09:33:56 +0200
>>
>> From: ***@gmail.com
>> To: mkgmap-***@lists.mkgmap.org.uk
>> Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
>>
>> Oh - and one thing is sure. In Basecamp Dirt-Bike and ATV have the same
>> penalties as driving - but the algo differs quite a lot. For "difficult"
>> long routes - it works much better than driving. Driving seems to have some
>> hidden preference really for long straight highway type of drives...
>>
>> On 7 September 2015 at 09:32, Felix Hartmann <***@gmail.com>
>> wrote:
>>
>> Oh wow - I never did it so scientific. I just changed angles a bit or
>> changed roadspeed and looked at the effect. One problem is that even if
>> using faster time - time is not everything - at least for longer routes.
>> But so it seems - angles below 22.5° should really be avoided. However I'm
>> not sure if it is really good to change all angles so that they are 45° at
>> least - even in nature I would guess in general a route will not take too
>> many of them.
>> Maybe dropping roadspeed by -1 for angles 22.5-45° if unavoidable would
>> be better than changing the angle?
>>
>> On 7 September 2015 at 08:20, Gerd Petermann <
>> ***@hotmail.com> wrote:
>>
>> Hi Felix,
>>
>> I think I found some more rules, but I still need more tests
>> before I can code a new fix.
>> I found at least two errors in the v2 + v3 patch, not sure
>> if they cause harm or if they just prevent good results.
>> One was in the highest speed calculation, the other in the calculation
>> of the needed heading change (some angles were not enlarged, others
>> were enlarged too much)
>>
>> Here is what I learned so far:
>> 1) The time penalty for a turn depends on the angle and the sum of the
>> road speed values of the arcs which are used.
>> (I thought that I have to look at the maximum (or minimum))
>> 2) the sum of speeds gives a factor which is mulitplied with a value that
>> depends
>> on the angle. The threshold values for the sum of speeds:
>> 0,1 : 0
>> 2,3 : 1
>> 4,5 : 2
>> ...
>> 12..13: 6
>> 14: 7
>> 2) penalties (for a car) are
>> steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s)
>> steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s)
>> steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s)
>> steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s)
>>
>> 3) The penalty is always completely added to the travel time of the 2nd
>> arc.
>>
>> TODO:
>> - The above values are for a right turn in a drive-on-right area. I still
>> have to
>> check left turns.
>> - I also have to measure the effect on bicycle routing and maybe other
>> vehicles
>> - The effect of multiple arcs. They have an effect on the precision of
>> the stored
>> heading values. Not sure how this changes the results.
>> I guess that Garmin will only use an arc with a high speed when
>> that is long enough so that the higher speed weights out the penalty .
>> A few tests show that it typically prefers the slower roads at the
>> junction
>> with the sharp angle, and "jumps" on the faster road at the next node.
>>
>> If you think that I should also look at other parameters, please let me
>> know.
>> Gerd
>>
>> ------------------------------
>> Date: Sat, 5 Sep 2015 15:17:17 +0200
>> From: ***@gmail.com
>> To: mkgmap-***@lists.mkgmap.org.uk
>> Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
>>
>>
>> Yes - I think for the start and end of a route - the algo will choose
>> topmost route only. For inbetween sections however not - there it chooses
>> the best - at least according to my tests a few years ago...
>> There is a max of 6 or 7 roads lying on top of each other - if more it
>> will produce a routing error and not go there at all.
>>
>> And yeah - I also don't know what's best. V2 seemed best to me so far.
>>
>> On 5 September 2015 at 15:09, GerdP <***@hotmail.com>
>> wrote:
>>
>> Hi Felix,
>>
>> okay, I came to similar results with other styles today, so
>> maybe I'll revert the change that makes most angles larger.
>>
>> Reg- --x-cycle-map:
>> Without it only angles < 45° are changed to 45°.
>> With it and v2, angles were changed to 68° when road speed of an arc is
>> >= 3
>> and 90° when road_speed >= 5.
>> With it and v3, all angles < 90 are changed at junctions with only 3
>> directions.
>>
>> I think the Garmin algo is not really able to handle multiple arcs with
>> that your style creates, at least it doesn't seem to "look" at all of
>> them,
>> esp. the last part of a route seems always to use the "topmost" road,
>> means, the one that was last added in the style (as long as the selected
>> vehicle is allowed).
>> I think we first have to understand how the Garmin algo works before
>> we can try to manipulate the data for better results.
>> This is time consuming and error prone, so I'll need a few more days to
>> work out facts.
>>
>> Gerd
>>
>>
>> Felix Hartmann-2 wrote
>> > Well - I guess this will never be without errors - with Patch v3 there
>> > is again a little loop - now again at the first place:
>> >
>> >
>> > (only happens with "Shorter Distance" and one of the
>> > driving/motorcycle/Dirtbike and so on profiles..).
>> >
>> > Also on some other places still detours - in general "Shorter Distance"
>> > seems to be much more problematic than "faster time". So for sharp turns
>> > - ironically - shorter distance chooses the detour to avoid the sharp
>> > turn.
>> >
>> >
>> > I'm not really sure patch v3 is better than v2 however. Results are
>> > 50/50 better/worse. However the arrival times got a bit slower (even if
>> > following exactly the same route). I always tried with --x-cycle-map
>> > switch - never without. I'm still not so sure what this option really
>> > changes for outcome in the end.
>> > So - additional intersection roads would still be king IMHO... (but yes
>> > I know - not possible).
>> >
>> >
>> >
>> > On 04.09.2015 19:34, Gerd Petermann wrote:
>> >> Hi all,
>> >>
>> >> attached is v3, only small changes:
>> >> 1) the message "maybe duplicated OSM way " was printed too often
>> >> 2) with --x-cycle-map, change the headings
>> >> at junctions with only three different arcs so that angles of 90° or
>> more
>> >> are created.
>> >>
>> >> If I hear no complains I'll commit this patch on monday,
>> >> probably without the --x-fix-sharp-angles switch.
>> >>
>> >> I am still trying to work out in what case the Garmin routing algo
>> >> prefers a detour, so maybe I find more improvements later.
>> >>
>> >> Ciao,
>> >> Gerd
>> >>
>> >>
>> >> _______________________________________________
>> >> mkgmap-dev mailing list
>> >>
>>
>> > mkgmap-***@.org
>>
>> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >
>> > --
>> > keep on biking and discovering new trails
>> >
>> > Felix
>> > openmtbmap.org & www.velomap.org
>> >
>> >
>> > _______________________________________________
>> > mkgmap-dev mailing list
>>
>> > mkgmap-***@.org
>>
>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >
>> > ajjdjdgb.png (24K)
>> > <http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-***@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Floragasse 9/11
>> 1040 Wien
>> Austria - Ãsterreich
>>
>> _______________________________________________ mkgmap-dev mailing list
>> mkgmap-***@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-***@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Floragasse 9/11
>> 1040 Wien
>> Austria - Ãsterreich
>>
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Floragasse 9/11
>> 1040 Wien
>> Austria - Ãsterreich
>>
>> _______________________________________________ mkgmap-dev mailing list
>> mkgmap-***@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-***@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Floragasse 9/11
> 1040 Wien
> Austria - Ãsterreich
>
--
Felix Hartman - Openmtbmap.org & VeloMap.org
Floragasse 9/11
1040 Wien
Austria - Ãsterreich