Hi Ticker, OK, I believe that you tested it well with the default style? Did you also try a style that adds multiple routable ways for one OSM way? Not sure if Felix still uses this for his maps on https://www.velomap.org/ but in the past this lead to all kinds of special cases that do not appear with the default style. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 14:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings Hi Gerd With sharp-angle code enabled, most junctions will get compactDirs; just a few less than the existing code. Original gmapsupp.img for my test area was 9801728 and with this change it is 4096 bytes bigger. I looked at some of the NodCheck angle errors and decided that not much could be done as it only has the low-res road points to work with. In mkgmap, the algo using hi-res points gave a good angle in all the cases I looked at, so the code is now really there to deal with real sharp junctions that cause the time penalty and misleading direction pop-ups. I had a list of troublesome junctions and looked at the angles in 8-bit and 4-bit format before & after my changes to see that it was doing as expected. I also looked the leg-time info from MapSource for various routes. Since then I've been using it a lot for car routing and it hasn't done anything that I've disagreed with. It seemed that you had determined that there was no benefit in increasing angles so that there was more than 1 empty sector between vehicle arcs, so I just did the same such that it was also guaranteed to work if the junction went non-compact for some other reason - an angle of 23 degrees, say the arcs were at -11.5 and +11.5, would considered non-sharp in compact format but is sharp in 8-bit format. Ticker On Tue, 2020-10-20 at 09:25 +0000, Gerd Petermann wrote:
Hi Ticker,
my understanding is that original Garmin maps use compact dirs a lot, so I think it is not a good idea to disable them. My problem with the patch is that NodCheck complains a lot more Steve and I are not sure how Garmin calculates the encoded angles, so we are still just guessing. Your approach might well be the best so far. The code in NodCheck has one big problem: It uses the data stored in RGN to calculate the bearings, and that means 24 bit precision. So for nearby nodes the rounding errors are too big and NodCheck uses a fallback algo which selects another point. I guess Garmin also calculates the NOD data with more than 24 bit precision, so they probably also have some kind of angle fixer. How did you test your changes? I think I used fake data that contained two alternative routes. That helped me to find the threshold values for the penalties. I also used real world OSM data to check special cases like roundabouts or *_link roads. Unfortunately it is very difficult to create unit tests for this, and the risk is high that a change improves 10 cases but worsens another 10, esp. with other styles or in other countries.
Maybe there is only one way to find out. I commit your patch and we wait for comments here or in the Garmin forum...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev