Hi Gerd I presume you are just changing SHARP_DEGREES, leaving COMPACT_DIR_DEGREES alone. In this example the arcs on either side of the sharp angle have the same priority (class/speed) so there isn't an obvious one to adjust so the logic adjusts both. Also in this example, and very common, is a side turn off a basically straight road and the proportions that each arc is adjusted isn't ideal in that the straight road is bent slightly more than the side turn is adjusted. This could be spotted as a special case: when there are 3 arcs and the available angle on one side or the other (initial value of deltaPred or deltaNext) is close to 180 degrees then just the other side should be adjusted. Maybe the 3 arcs doesn't really matter as long as there is sufficient space to adjust the other side. I'll do some experiments. Ticker On Mon, 2024-08-05 at 08:55 +0000, Gerd Petermann wrote:

...

...

...

Hi Ticker,

thanks, I didn't test much, but with a value of 22.5 (or 23) the problem disappeared. It also disappears with --x-ignore-sharp-angles. Downgrade is that the NOD size increases a bit, but I think that is better than wrong turn instructions.

Let me know if you cannot reproduce and I'll create a more complete description reg. the options in use.

ciao, Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 5. August 2024 10:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd

I'll need to look carefully at this code again.

ISTR the 46 degrees was to stop arcs getting into the same compact segment when they shouldn't. My changes stopped a lot of incorrect turn instructions but maybe there is still scope for the algorithm to look for the same road entered and exiting in a straight line and try to preserve this by adjust other roads more.

Noticed that, in the example, these are bike routes and it looks like the algo ignores these.

Ticker

On Mon, 2024-08-05 at 06:37 +0000, Gerd Petermann wrote:

...

...

> > Hi all, > > > > in a private email Thorsten Kukuk contacted me about wrong turn > > instructions > > a > > sharp angles. > > An example is the node https://www.osm.org/node/27550903 > > > > A route coming from South that follows the way > > https://www.osm.org/way/36138336 at this junction should NOT > > produce a > > turn > > instruction. > > A route that turns left SHOULD produce a turn instruction. > > With current mkgmap it's vice versa and thus not OK. > > > > I thnk the current code in AngleFixer.java is too agressive as > > it tries > > to > > enlarge the angles so that a compact format can be used to write > > the > > heading values of the arcs at the mentioned node. It does this > > by > > changing > > the > > heading values of both arcs with go to the north. > > > > @Ticker: The code was introduced with your arcHeading_v2.patch, > > but > > maybe it > > existed before. > > Can you explain why the constant AngleChecker.SHARP_DEGREES is > > set to > > 46° > > instead of maybe 22.5° ? > > > > Gerd > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker, I'll have a look at the patch during the next days. Please ping me if I didn't react until August 20. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 6. August 2024 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer? Hi Gerd Patch attached that, where possible, keeps ~straight roads unchanged and widens the sharp angle on the other road. This should fix the particular example and generally be better, although it is difficult to test. I try and note where I get incorrect turn instructions and later work out why and, since the arcHeading_v2.patch in Oct 2020 I haven't found any that are fixable; I couldn't find a solution where the major road continues at an angle and the minor side road continues straight on. Ticker On Mon, 2024-08-05 at 19:14 +0100, Ticker Berkin wrote:

Hi Gerd

I presume you are just changing SHARP_DEGREES, leaving COMPACT_DIR_DEGREES alone.

In this example the arcs on either side of the sharp angle have the same priority (class/speed) so there isn't an obvious one to adjust so the logic adjusts both.

Also in this example, and very common, is a side turn off a basically straight road and the proportions that each arc is adjusted isn't ideal in that the straight road is bent slightly more than the side turn is adjusted.

This could be spotted as a special case: when there are 3 arcs and the available angle on one side or the other (initial value of deltaPred or deltaNext) is close to 180 degrees then just the other side should be adjusted. Maybe the 3 arcs doesn't really matter as long as there is sufficient space to adjust the other side.

I'll do some experiments.

Ticker

On Mon, 2024-08-05 at 08:55 +0000, Gerd Petermann wrote:

...

...

...

...

Hi Ticker,

thanks, I didn't test much, but with a value of 22.5 (or 23) the problem disappeared. It also disappears with --x-ignore-sharp-angles. Downgrade is that the NOD size increases a bit, but I think that is better than wrong turn instructions.

Let me know if you cannot reproduce and I'll create a more complete description reg. the options in use.

ciao, Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 5. August 2024 10:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd

I'll need to look carefully at this code again.

ISTR the 46 degrees was to stop arcs getting into the same compact segment when they shouldn't. My changes stopped a lot of incorrect turn instructions but maybe there is still scope for the algorithm to look for the same road entered and exiting in a straight line and try to preserve this by adjust other roads more.

Noticed that, in the example, these are bike routes and it looks like the algo ignores these.

Ticker

On Mon, 2024-08-05 at 06:37 +0000, Gerd Petermann wrote:

...

> > > Hi all, > > > > > > in a private email Thorsten Kukuk contacted me about wrong > > > turn > > > instructions > > > a > > > sharp angles. > > > An example is the node https://www.osm.org/node/27550903 > > > > > > A route coming from South that follows the way > > > https://www.osm.org/way/36138336 at this junction should NOT > > > produce a > > > turn > > > instruction. > > > A route that turns left SHOULD produce a turn instruction. > > > With current mkgmap it's vice versa and thus not OK. > > > > > > I thnk the current code in AngleFixer.java is too agressive as > > > it tries > > > to > > > enlarge the angles so that a compact format can be used to > > > write > > > the > > > heading values of the arcs at the mentioned node. It does this > > > by > > > changing > > > the > > > heading values of both arcs with go to the north. > > > > > > @Ticker: The code was introduced with your > > > arcHeading_v2.patch, > > > but > > > maybe it > > > existed before. > > > Can you explain why the constant AngleChecker.SHARP_DEGREES is > > > set to > > > 46° > > > instead of maybe 22.5° ? > > > > > > Gerd > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev@lists.mkgmap.org.uk > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Thorsten Is the problem still with node https://www.osm.org/node/27550903 and ways 36138336 / 144732811 I've loaded this example and looked at the angles before and after adjustment with my patch. From the south the way enters the node with heading 161.6 and leaves with heading -16, giving an angle of 178.6 (almost straight). The other way leaves with heading -32.4, giving a sharp angle of 15.4 degrees that the logic will want to increase. After the adjustments, the main way isn't changed and the other way is given a new heading of -63 degrees. In compactDir format the main way enters in seg 7 and leaves in seg 15 (direct opposite) and the other way now leaves in seg 13 (a clear segment between the other exit). This, I thought, would be enough to get the turn instruction on the correct road. I've forgotten how some of the forward and reverse arc stuff works and, if there is still a problem, I need to re-understand it to make sure that the manipulations that we do to the angles at a node make sense for all routes through it Ticker PS: no ideal about your mail error On Thu, 2024-08-08 at 11:45 +0200, Thorsten Kukuk wrote:

Hi,

trying from another email account, with the other I always get an error when trying to send to the mailing list: TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71): 123617668315712:error:1000012e:SSL routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT:third_party/openssl/boringss l/src/ssl/ssl_cert.cc:431:

I tried the patch from Ticker, it fixes routing problems with sharp angles for me, where previously Garmin devices would avoid the Junction. But it does not fix the wrong turn instruction for me.

Regards, Thorsten

Hi First of all did you have these values in AngleChecker COMPACT_DIR_DEGREES = 45+1; SHARP_DEGREES = COMPACT_DIR_DEGREES; If SHARP_DEGREES is less than this, then, with compactDir format, there might not be big enough distinction between the directions of the 2 exit ways to get the correct turn instruction. There isn't any flags or road matching to see which is the most likely continuation and which is the turn off. As far as I know, the turn instructions are just based on the AngleOfTurn. Before my change this week it just looked at the highway class and speed and, if different, adjusted the lower one in preference, and, if all else equal, adjusted both. My change this week is just based on one of the angles between arcs being between 177 and 183 degrees and, if so, not changing these arcs. With a bit more complication I could also try matching the way IDs. Your second example isn't quite clear; there are 3 3-way junctions near the coords you gave, and, for one of them, the continuous way bends with the other way, starting at the node, almost straight on going south. Without loading these nodes and checking all the initial headings I can't tell which angles are "sharp" and AngleChecker doesn't do anything if there are no sharp angles. Regards Ticker On Thu, 2024-08-08 at 15:11 +0200, Thorsten Kukuk wrote:

Hi,

Am 2024-08-08 14:22, schrieb Ticker Berkin:

...

Hi Thorsten

Is the problem still with node https://www.osm.org/node/27550903 and ways 36138336 / 144732811

Yes. That's one. Else see below.

...

I've loaded this example and looked at the angles before and after adjustment with my patch. From the south the way enters the node with heading 161.6 and leaves with heading -16, giving an angle of 178.6 (almost straight). The other way leaves with heading -32.4, giving a sharp angle of 15.4 degrees that the logic will want to increase.

After the adjustments, the main way isn't changed and the other way is given a new heading of -63 degrees.

In compactDir format the main way enters in seg 7 and leaves in seg 15 (direct opposite) and the other way now leaves in seg 13 (a clear segment between the other exit). This, I thought, would be enough to get the turn instruction on the correct road.

I've forgotten how some of the forward and reverse arc stuff works and, if there is still a problem, I need to re-understand it to make sure that the manipulations that we do to the angles at a node make sense for all routes through it

I don't know anything about the format. Is there somehow a flag what is the main road, or is this navigation instruction purely based on the degree of the turn? Because, I have more similar situations like here: https://www.openstreetmap.org/#map=18/49.43041/10.99213

If you go from north to the south and have to turn right no instruction is coming, if you have to go straight forward, a "turn left" is coming. Difference to the point above is, that the main road is make a turn right and the straight forward is a new, smaller way.

Regards, Thorsten

...

Ticker

PS: no ideal about your mail error

On Thu, 2024-08-08 at 11:45 +0200, Thorsten Kukuk wrote:

...

Hi,

trying from another email account, with the other I always get an error when trying to send to the mailing list: TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71): 123617668315712:error:1000012e:SSL routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT:third_party/openssl/bori ngss l/src/ssl/ssl_cert.cc:431:

I tried the patch from Ticker, it fixes routing problems with sharp angles for me, where previously Garmin devices would avoid the Junction. But it does not fix the wrong turn instruction for me.

Regards, Thorsten

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Thorsten I don't see an easy solution to your second example, the "turn-off" is almost straight on. I don't understand why my change didn't fix your first example, unless you allocate different road speed/class for different smoothness, surface, tracktype tags, in which case the continuous way might be lower priority than the joining way and the algorithm prefers to this. Regards Ticker On Thu, 2024-08-08 at 17:11 +0200, Thorsten Kukuk wrote:

Am 2024-08-08 16:52, schrieb Ticker Berkin:

...

Hi

First of all did you have these values in AngleChecker   COMPACT_DIR_DEGREES = 45+1;   SHARP_DEGREES = COMPACT_DIR_DEGREES; If SHARP_DEGREES is less than this, then, with compactDir format, there might not be big enough distinction between the directions of the 2 exit ways to get the correct turn instruction.

Yes, I haven't changed them. I'm using mkgmap r4921 with your patch.

...

Your second example isn't quite clear; there are 3 3-way junctions near the coords you gave, and, for one of them, the continuous way bends with the other way, starting at the node, almost straight on going south. Without loading these nodes and checking all the initial headings I can't tell which angles are "sharp" and AngleChecker doesn't do anything if there are no sharp angles.

The point is https://www.openstreetmap.org/node/261582603 The ways are https://www.openstreetmap.org/way/24147681 and https://www.openstreetmap.org/way/24147729

Thorsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Am 2024-08-10 09:39, schrieb Thorsten Kukuk:

To get that right: Your patch fixes one half of my first example: if you let Garmin calculate the route, it will now use the junction and will not use u-turns and detours to avoid it. So your patch is an improvement. What it does not fix is the wrong navigation instruction: it tells you to turn right if you need to go straight forward, and if you need to turn left it doesn't tell you anything. And this shouldn't have anything to do with road speed or surface.

Maybe pictures explain it better: 1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two forbidden u-turns and a detour and avoids the junction. 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses the junction. 3. navigation-instruction-turn-right.png: at the junction with a route straight forward Garmin Software and Devices tell you to turn right in navigation mode. I hope this explains it better. Regards, Thorsten

Hi Thorsten Let me know if the road_speed and/or road_class are different with the style you are using. If they are all the same I don't understand why it should give a turn instruction. If it is just the road_speed, I'll do another patch that prioritises road_class, then "likely same road", then road_speed. Ticker On Sat, 2024-08-10 at 16:27 +0100, Ticker Berkin wrote:

Hi Thorsten

The algorithm, in choosing which arc headings to adjust to remove sharp turns, prefers to adjust lower class roads. If class is the same it adjusts lower speed road. If these are the same, with my change it, it sees if one is reasonably straight and adjusts the other. As a last resort it adjusts both.

This, I consider, is reasonable and gives good results almost all the time.

With the default style both ways have speed=1 class=0 and so it adjusts way 144732811. However if your style gives them different classes/speeds (144732811 is paved, the other is unpaved) it will bend way 36138336 such that this might trigger a right-turn instruction if going from south to north.

I'm not sure what the best solution is for your example.

Regards Ticker

On Sat, 2024-08-10 at 10:01 +0200, Thorsten Kukuk wrote:

...

Am 2024-08-10 09:39, schrieb Thorsten Kukuk:

...

To get that right: Your patch fixes one half of my first example: if you let Garmin calculate the route, it will now use the junction and will not use u-turns and detours to avoid it. So your patch is an improvement. What it does not fix is the wrong navigation instruction: it tells you to turn right if you need to go straight forward, and if you need to turn left it doesn't tell you anything. And this shouldn't have anything to do with road speed or surface.

Maybe pictures explain it better:

1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two forbidden u-turns and a detour and avoids the junction. 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses the junction. 3. navigation-instruction-turn-right.png: at the junction with a route straight forward Garmin Software and Devices tell you to turn right in navigation mode.

I hope this explains it better.

Regards, Thorsten

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Thorsten Ah, the different road_class your style is generating would explain why my change didn't work for you. I started looking at the order in which to consider: road_class, sameWay, straightEnough, sameName, road_speed and, in a typical area looking for conflict between these, came to the conclusion that road_class should be first, which is unfortunate for your first case. I'll implement it a bit more and look at examples and see if they really matter. Introducing "sameWay" might fix your second example. Regards Ticker On Mon, 2024-08-12 at 10:23 +0200, Thorsten Kukuk wrote:

Hi Ticker,

The way straight forward is https://www.openstreetmap.org/way/36138336

It's one long way in OSM, which means all tags before and after the junction are the same: road_class=1 and road_speed=2

The way starting at the junction to the left is https://www.openstreetmap.org/way/144732811 and has road_class=2 and road_speed=2 in my style.

Regards, Thorsten

Am 2024-08-10 18:38, schrieb Ticker Berkin:

...

Hi Thorsten

Let me know if the road_speed and/or road_class are different with the style you are using. If they are all the same I don't understand why it should give a turn instruction.

If it is just the road_speed, I'll do another patch that prioritises road_class, then "likely same road", then road_speed.

Ticker

On Sat, 2024-08-10 at 16:27 +0100, Ticker Berkin wrote:

...

Hi Thorsten

The algorithm, in choosing which arc headings to adjust to remove sharp turns, prefers to adjust lower class roads. If class is the same it adjusts lower speed road. If these are the same, with my change it, it sees if one is reasonably straight and adjusts the other. As a last resort it adjusts both.

This, I consider, is reasonable and gives good results almost all the time.

With the default style both ways have speed=1 class=0 and so it adjusts way 144732811. However if your style gives them different classes/speeds (144732811 is paved, the other is unpaved) it will bend way 36138336 such that this might trigger a right-turn instruction if going from south to north.

I'm not sure what the best solution is for your example.

Regards Ticker

On Sat, 2024-08-10 at 10:01 +0200, Thorsten Kukuk wrote:

...

Am 2024-08-10 09:39, schrieb Thorsten Kukuk:

...

To get that right: Your patch fixes one half of my first example: if you let Garmin calculate the route, it will now use the junction and will not use u-turns and detours to avoid it. So your patch is an improvement. What it does not fix is the wrong navigation instruction: it tells you to turn right if you need to go straight forward, and if you need to turn left it doesn't tell you anything. And this shouldn't have anything to do with road speed or surface.

Maybe pictures explain it better:

1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two forbidden u-turns and a detour and avoids the junction. 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses the junction. 3. navigation-instruction-turn-right.png: at the junction with a route straight forward Garmin Software and Devices tell you to turn right in navigation mode.

I hope this explains it better.

Regards, Thorsten

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Thorsten and Gerd I've looked at examples around my area where a higher class way terminates (at a sharp angle) in the middle of a way or 2 straight ways and, in none that I found, would it be a problem to adjust the angle of the higher class road. I've re-done the patch to this effect, also adding in test for sameName arcs and simplifying the logic slightly such that it is easier to change the testing order. @Thorsten: can you try this; it should fix your first example. It might fix the second but, because the continuous way has quite an angle at the junction, even moving the turn-off road away from it might not be enough to trigger the turn- instruction. @Gerd: The new logic doesn't attempt to handle roads crossing. For straightEnough it just looks at the angle either side of the sharp angle. For sameWay and sameRoad it just looks at the adjacent arcs either side of the sharp angle. For 3 arc junctions this is correct but for 4 or more arcs it might help but is not complete. I'm going to use this for a while. There are some diags that could be removed later. Regards Ticker On Mon, 2024-08-12 at 09:34 +0000, Gerd Petermann wrote:

Hi Ticker,

I also thought about sameWay as a criteria, but remember that this is likely to fail. I see quite often that tracks are drawn with 90° angles and another one is added which also has a 90° angle at the same crossing.  No idea why, but it isn't wrong. Same situation in residential areas where multiple ways are needed but all have the same name and type (e.g. a paved living_street).

ciao Gerd

Hi Ticker, Am 2024-08-12 13:14, schrieb Ticker Berkin:

Really sorry, previous patch was wrong. Correct one attached

Sorry, but for https://www.openstreetmap.org/#map=18/49.47851/10.94281 this has still no effect. But I think I found the problem. The part from the log file is: sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° speeds 2 2 classes 2 1 increasing arc with heading 343° by 30.624285 The other sharp angle a few meters away (https://www.openstreetmap.org/#map=19/49.47966/10.94146), which works, has: sharp angle 40.094727 ° at 49.479659,10.941464 headings 132° 172° speeds 2 2 classes 2 2 increasing arc with heading 172° by 2.3486972 decreasing arc with heading 132° by 3.5565763 Difference: in the first case, the heading is >> 180° In the second case, it's < 180°. So I did go through the log and tested some more cases: If the heading is >> 180°, the navigation instruction is wrong. If the heading is < 180°, the navigation instruction is correct. Looks like if an angle is >> 180°, we have to code another one in the map. Regards, Thorsten

Ticker

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker, The code is identical. But: how do you explain, that on all junctions, where your logging reports headings in the 3xx° area, Garmin navigation instructions are wrong, and where the headings are < 180°, the navigation instructions are correct? In between it looks like, turn instructions for both directions are given. And I don't speak here about the two junctions I brought up in this mail thread, I selected several random junctions from the log file with "sharp angle" and created routes for it. And for all, where the headings are in the 3xx° area, the notifications were "wrong", and in all, where it was below 180°, it was correct. Examples for "wrong" routing instructions: sharp angle 13.183327 ° at 49.294696,11.107571 headings 307° 320° speeds 2 2 classes 3 1 increasing arc with heading 320° by 32.816673 sharp angle 32.202377 ° at 49.445028,11.075047 headings 322° 354° speeds 3 2 classes 1 3 decreasing arc with heading 322° by 13.797623 My observation: headings below < 180° seem to be fine. Or I had always luck when testing. headings around 270° seems to give you instructions for both directions. headings in the 3xx° area will give you "wrong" instructions. Regards, Thorsten Am 2024-08-13 18:57, schrieb Ticker Berkin:

Hi Thorsten

This is different from what I'm getting (after adjustments to get compatible class & speed):

sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° speeds 3 3 classes 2 1 decreasing arc with heading 328° by 30.624285

Can you check {yourbase}/src/uk/me/parabola/imgfmt/app/net/AngleChecker.java around line 379 you have: <<< // Hoping sameWay before road_class fixing more problems than it might cause if (chooseWhich == 0) { // if the two arcs either side of the sharp angle belong to the same // way then change the arc on the other side hoping to trigger // the correct turn-instruction ag0 = arcGroups.get ... ag3 = n == 3 ? ... if (ag2.sameWay(ag3)) chooseWhich = -1; else if (ag1.sameWay(ag0)) chooseWhich = +1; } if (chooseWhich == 0) chooseWhich = ag1.maxRoadClass - ag2.maxRoadClass;

...

...

...

as from AngleChecker_v3.patch and this is the version you've build and tested.

If it is all correct then I'll need to add more diagnostics to see if the internal ways have been manipulated.

Concerning the second example, I hope we've got good and consistent representations of all the RouteNode angles in the two formats in the garmin .img file and, generally, we get the turn-instructions expected but we don't know the rules for these.

Your examples where the turn-instructions are not what you expect are explicable because the other road is more straight-on than the way continuation. AngleChecker sometimes made this worse when giving junction RouteNode geometry that is different from reality to avoid garmin applying massive time penalties to some turns.

Regards Ticker

On Tue, 2024-08-13 at 17:06 +0200, Thorsten Kukuk wrote:

...

Hi Ticker,

Am 2024-08-12 13:14, schrieb Ticker Berkin:

...

Really sorry, previous patch was wrong. Correct one attached

Sorry, but for https://www.openstreetmap.org/#map=18/49.47851/10.94281  this has still no effect. But I think I found the problem.

The part from the log file is: sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° speeds 2 2 classes 2 1 increasing arc with heading 343° by 30.624285

The other sharp angle a few meters away (https://www.openstreetmap.org/#map=19/49.47966/10.94146), which works, has: sharp angle 40.094727 ° at 49.479659,10.941464 headings 132° 172° speeds 2 2 classes 2 2 increasing arc with heading 172° by 2.3486972 decreasing arc with heading 132° by 3.5565763

Difference: in the first case, the heading is >> 180° In the second case, it's < 180°.

So I did go through the log and tested some more cases: If the heading is >> 180°, the navigation instruction is wrong. If the heading is < 180°, the navigation instruction is correct.

Looks like if an angle is >> 180°, we have to code another one in the map.

Regards, Thorsten

...

Ticker

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker, Am 2024-08-14 17:48, schrieb Ticker Berkin:

Hi Thorsten

I can't explain the turn instructions being in the wrong direction for some ranges of angles. What are you seeing this on - Basecamp / MapSource / Garmin Device?

I see this on BaseCamp, Garmin GPSMap 66sr, Garmin Edge 1030+ and 1050. I have only tested a few junctions with the Garmin devices, the ones in the near, but the result was always identical.

Can you send me the same sections of the log file, the first should look like this:

fixSharpAngles_v4 at 49.478507,10.942814 mask 2 smallestAngle 15.375715 nArcs 3 nDirectArcs 3 nGroups 3 Arc heading -32.3756 328° angToPrev 166.0431 class 2 speed 2 way 144732811 isFake false rdDef -2042305213 name null paved true Arc heading -16.999884 343° angToPrev 15.375715 class 1 speed 2 way 36138336 isFake false rdDef -485064406 name null paved false Arc heading 161.5813 162° angToPrev 178.58118 class 1 speed 2 way 36138336 isFake false rdDef -485064406 name null paved false Angle 15.375715 between -32.3756 and -16.999884 minAngle 46.0 wantedInc 30.624285 deltaPred 120.043106 deltaNext 132.58118 decreasing arc with heading 328° by 30.624285 modInitialHeading arc from -32.3756 by -30.624285 to -62.999886 join angle 8.872055 ° at 49.483048,10.932943 increased by 37.127945

If, in this example, way 36138338 has been split, I need to see if there is any way of finding the associated bits of road

But with this build, the "wrong" turn instructions are gone! This time the 328° heading was used, not the 343°. If you haven't done any other changes to your patch except debugging code (I haven't looked at the patch yet), then I'm afraid we have somewhere an unstable sort or use a hash table, which will not give reproducable results. Regards, Thorsten

Am 2024-08-15 15:49, schrieb Ticker Berkin:

Hi Thorsten

Apart from moving and adding diagnostics, the only significant change I made was to remove a test for the arcs on either side of a sharp angle being the same road, and, if so, not widen the angle. This didn't occur in your example. The other changes were cosmetic.

With this latest version/build, have all your wrong turn-instructions gone?

I don't have currently the time to test all examples, but the few I tested seems to be Ok now. Instead of wrong "turn right" for straight forward I have now no message for it or "turn left" for the left way. In some cases I get "keep right" and "keep left" (assumes "Y" junction), which is Ok in that cases.

Do you use option --preserve-element-order? Elsewhere in the code quite a lot of effort has been taken to avoid java constructs with unpredictable ordering.

No, I'm not using "--preserve-element-order". Regards, Thorsten

Regards Ticker

On Thu, 2024-08-15 at 14:24 +0200, Thorsten Kukuk wrote:

...

Hi Ticker,

Am 2024-08-14 17:48, schrieb Ticker Berkin:

...

Hi Thorsten

I can't explain the turn instructions being in the wrong direction for some ranges of angles. What are you seeing this on - Basecamp / MapSource / Garmin Device?

I see this on BaseCamp, Garmin GPSMap 66sr, Garmin Edge 1030+ and 1050.

I have only tested a few junctions with the Garmin devices, the ones in the near, but the result was always identical.

...

Can you send me the same sections of the log file, the first should look like this:

fixSharpAngles_v4 at 49.478507,10.942814 mask 2 smallestAngle 15.375715 nArcs 3 nDirectArcs 3 nGroups 3 Arc heading -32.3756 328° angToPrev 166.0431 class 2 speed 2 way 144732811 isFake false rdDef -2042305213 name null paved true Arc heading -16.999884 343° angToPrev 15.375715 class 1 speed 2 way 36138336 isFake false rdDef -485064406 name null paved false Arc heading 161.5813 162° angToPrev 178.58118 class 1 speed 2 way 36138336 isFake false rdDef -485064406 name null paved false Angle 15.375715 between -32.3756 and -16.999884 minAngle 46.0 wantedInc 30.624285 deltaPred 120.043106 deltaNext 132.58118 decreasing arc with heading 328° by 30.624285 modInitialHeading arc from -32.3756 by -30.624285 to -62.999886 join angle 8.872055 ° at 49.483048,10.932943 increased by 37.127945

...

If, in this example, way 36138338 has been split, I need to see if there is any way of finding the associated bits of road

But with this build, the "wrong" turn instructions are gone! This time the 328° heading was used, not the 343°. If you haven't done any other changes to your patch except debugging code (I haven't looked at the patch yet), then I'm afraid we have somewhere an unstable sort or use a hash table, which will not give reproducable results.

Regards,    Thorsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker, the patch solves the original problem at https://www.osm.org/node/27550903 I tried to find other places where the change in the map data produce differences in routing but without success so far. I think that's good news, but all cases only involved footways or tracks so far. So, I wait for Thorsten to confirm that the patch is an improvement. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 24. August 2024 18:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer? Hi Gerd & Thorsten This, I hope, is the final version of the changes to AngleFixer. I've simplified and clarified some of the logic, improved some of the diagnostics, added more comments and made better choices of when compactDir format is used. There should be a slight reduction in .img size, fewer time penalties and better turn-instructions. Regards Ticker

Hi Gerd & Thorsten I need to test one more scenario where a fast one-way lane splits with equal priority (eg on a motorway) and check that my changes don't trigger a turn instruction instead of "keep-left" or "keep-right". Please don't commit anything until I've tested this. Ticker On Mon, 2024-08-26 at 11:55 +0000, Gerd Petermann wrote:

Hi Ticker,

the patch solves the original problem at https://www.osm.org/node/27550903 I tried to find other places where the change in the map data produce differences in routing but without success so far. I think that's good news, but all cases only involved footways or tracks so far.

So, I wait for Thorsten to confirm that the patch is an improvement.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 24. August 2024 18:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd & Thorsten

This, I hope, is the final version of the changes to AngleFixer.

I've simplified and clarified some of the logic, improved some of the diagnostics, added more comments and made better choices of when compactDir format is used. There should be a slight reduction in .img size, fewer time penalties and better turn-instructions.

Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi, I tested that patch in BaseCamp and yesterday evening on a bicycle tour. Navigation instructions were good, I haven't seen any wrong hint, no missing one and also no superfluous. Same result as I had already on several other tours the last days with v5. Great job, that patch is a big improvement! With v6 I had some wired navigation instructions on one place when when I deviated from the route and it automatically guided me back. But when I did inspect the map today, there is a small, parallel path, could be very well that the Garmin device wanted to route me via that way and it was not visible on the small display. I couldn't reproduce that with a GPX track or BaseCamp. Need to check the OSM data later, I assume wrong tags. Or I need to switch the line types in my maps. It's really wired which effect line types have on routing and navigation instructions. So if you get flooded with useless navigation instructions, this could also be the fault of using the wrong line type in your map... Thorsten Am 2024-08-29 10:42, schrieb Ticker Berkin:

Hi

I've improved some of the logic where arcs on either side of an angle are one- way (merging, splitting or continuous).

I didn't detect turn-left/right instructions rather then keep-left/right on the roads I use where there is a gradual split. However I thought this would be a possibility in other cases if the angles on the split were increased so it seemed best give an accurate representation to the device and let it announce what it considers best.

One-ways merging don't need any increase in angle.

Continuous one-ways were considered to be a flare, eg joining a roundabout or a more major road and the angle wasn't increased, but there are other cases where it should be, so I've removed this as a special case.

Patch attached

Ticker

On Mon, 2024-08-26 at 17:16 +0100, Ticker Berkin wrote:

...

Hi Gerd & Thorsten

I need to test one more scenario where a fast one-way lane splits with equal priority (eg on a motorway) and check that my changes don't trigger a turn instruction instead of "keep-left" or "keep-right".

Please don't commit anything until I've tested this.

Ticker

On Mon, 2024-08-26 at 11:55 +0000, Gerd Petermann wrote:

...

Hi Ticker,

the patch solves the original problem at https://www.osm.org/node/27550903 I tried to find other places where the change in the map data produce differences in routing but without success so far. I think that's good news, but all cases only involved footways or tracks so far.

So, I wait for Thorsten to confirm that the patch is an improvement.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 24. August 2024 18:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd & Thorsten

This, I hope, is the final version of the changes to AngleFixer.

I've simplified and clarified some of the logic, improved some of the diagnostics, added more comments and made better choices of when compactDir format is used. There should be a slight reduction in .img size, fewer time penalties and better turn-instructions.

Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker, thanks, but the problem is not routable vs. non-routable, but that the device seems to prefer to leave the cycleway for a longer footway instead of staying on the shorter cycleway, which should additional have a higher road_speed and a higher road_class. And that it does not work here means either the tags on the ways are not correct or there is an error in my style. Something to debug for the next rainy day :) Thorsten Am 2024-08-30 17:21, schrieb Ticker Berkin:

Hi Thorsten

Thanks for testing this.

The routable line types are: 0x01 ... 0x13 highways 0x16 highway 0x1a ... 0x1b ferry on newer garmin devices/Basecamp 0x2c ... 0x2f ?/Climbing path/Via Ferrata/Cable Car

Using these for non-routables can break routing nearby in some Garmin software; I've certainly seen this behaviour in Basecamp. The default style uses the correct routable/non-routable types for the context.

I've seen suggestions that 0x17 is routable. This is used by the default style as non-routable.

Routable types 0x08, 0x09, 0x0c, 0x1a and 0x1b and maybe 0x13 have slightly different behaviour - mainly relating to the navigation instructions issued.

Regards Ticker

On Fri, 2024-08-30 at 09:59 +0200, Thorsten Kukuk wrote:

...

Hi,

I tested that patch in BaseCamp and yesterday evening on a bicycle tour. Navigation instructions were good, I haven't seen any wrong hint, no missing one and also no superfluous. Same result as I had already on several other tours the last days with v5. Great job, that patch is a big improvement!

With v6 I had some wired navigation instructions on one place when when I deviated from the route and it automatically guided me back. But when I did inspect the map today, there is a small, parallel path, could be very well that the Garmin device wanted to route me via that way and it was not visible on the small display. I couldn't reproduce that with a GPX track or BaseCamp. Need to check the OSM data later, I assume wrong tags. Or I need to switch the line types in my maps. It's really wired which effect line types have on routing and navigation instructions. So if you get flooded with useless navigation instructions, this could also be the fault of using the wrong line type in your map...

Thorsten

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Ah sorry, I've already commited it! Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 15. Dezember 2024 09:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer? Hi Ticker and Thorsten! What's the status here? Should I commit one of the patches? ciao Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Thorsten Kukuk <kukuk@thkukuk.de> Gesendet: Freitag, 30. August 2024 17:45 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Problem in AngleFixer? Hi Ticker, thanks, but the problem is not routable vs. non-routable, but that the device seems to prefer to leave the cycleway for a longer footway instead of staying on the shorter cycleway, which should additional have a higher road_speed and a higher road_class. And that it does not work here means either the tags on the ways are not correct or there is an error in my style. Something to debug for the next rainy day :) Thorsten Am 2024-08-30 17:21, schrieb Ticker Berkin:

Hi Thorsten

Thanks for testing this.

The routable line types are: 0x01 ... 0x13 highways 0x16 highway 0x1a ... 0x1b ferry on newer garmin devices/Basecamp 0x2c ... 0x2f ?/Climbing path/Via Ferrata/Cable Car

Using these for non-routables can break routing nearby in some Garmin software; I've certainly seen this behaviour in Basecamp. The default style uses the correct routable/non-routable types for the context.

I've seen suggestions that 0x17 is routable. This is used by the default style as non-routable.

Routable types 0x08, 0x09, 0x0c, 0x1a and 0x1b and maybe 0x13 have slightly different behaviour - mainly relating to the navigation instructions issued.

Regards Ticker

On Fri, 2024-08-30 at 09:59 +0200, Thorsten Kukuk wrote:

...

Hi,

I tested that patch in BaseCamp and yesterday evening on a bicycle tour. Navigation instructions were good, I haven't seen any wrong hint, no missing one and also no superfluous. Same result as I had already on several other tours the last days with v5. Great job, that patch is a big improvement!

With v6 I had some wired navigation instructions on one place when when I deviated from the route and it automatically guided me back. But when I did inspect the map today, there is a small, parallel path, could be very well that the Garmin device wanted to route me via that way and it was not visible on the small display. I couldn't reproduce that with a GPX track or BaseCamp. Need to check the OSM data later, I assume wrong tags. Or I need to switch the line types in my maps. It's really wired which effect line types have on routing and navigation instructions. So if you get flooded with useless navigation instructions, this could also be the fault of using the wrong line type in your map...

Thorsten

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev