[mkgmap-dev] Resurrect adjust-turn-headings

Tue Oct 20 14:32:08 BST 2020

Hi Ticker,

OK, let's try it. Some cleanup is needed. I see
- hard coded tests like if (isClose(51.182575, -1.388928, 0.002))
- dead code: getImgAngle() is not used

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Dienstag, 20. Oktober 2020 15:21
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings

Hi Gerd

I kept the existing logic that takes all arcs within one degree and
treats them as one (and fixed the extra case where they straddle +-180)
so there should be no difference in this aspect.

Ticker

On Tue, 2020-10-20 at 12:48 +0000, Gerd Petermann wrote:
> 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 at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev