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