[mkgmap-dev] Resurrect adjust-turn-headings

Tue Oct 20 13:30:19 BST 2020

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