[mkgmap-dev] Resurrect adjust-turn-headings

Wed Oct 21 11:10:07 BST 2020

Hi Gerd

I've deleted the dead code and commented out the node/arc investigation
code - it isn't "hard coded tests", rather a harness of a useful
diagnostic to see what is happening with the routing structures in
geographical areas and some examples of how to use it. It was under the
control of:
uk.me.parabola.imgfmt.app.net.AngleChecker.level=INFO

Also clarified some comments about indirect arcs and their headings.

Patch attached

Ticker

On Tue, 2020-10-20 at 13:32 +0000, Gerd Petermann wrote:
> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arcHeading_v2.patch
Type: text/x-patch
Size: 31273 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20201021/a41d5e9e/attachment-0001.bin>