[mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

Wed Jul 8 10:46:08 BST 2020

Hi all,

attached is a patch with changes the order of the nodes without arcs to appear first. The binary is here:
http://files.mkgmap.org.uk/download/485/mkgmap.jar

The patch seems to improve routing with Felix' test case but I still have trouble to get the demo mode working, so it woud be great to hear your results.
I seem to be unable to tell the device were it should start to simulate the route, it always starts somewhere else. Guess I have to read the manual to find out how this simulation mode has to be used...
Advantage of this patch is that it has nearly no impact on the img size.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Mittwoch, 8. Juli 2020 10:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

Hi developers,

I analysed the Garmin demo maps with routing data and found out that there is a difference compared to the map produced by mkgmap.
Garmin maps also have route nodes without arcs, but those always appear in the first route center while mkgmap doesn't care about this order.
Also, this first route center contains ONLY contains nodes without arcs.
Such a node without arcs is typically a routing island, e.g. if a map contains a T-shaped junction without further road connections.

These nodes without arcs don't occur with Steves patch, so it might be the place which causes the trouble. I am not yet sure what happens when
a single tile contains so many nodes without arcs that they don't fit into a single route center. I did not yet find such a case in the Garmin maps.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Mittwoch, 8. Juli 2020 08:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

Hi Felix,

OK, so I guess we have to prefer stabilty for now. I try to find out under what circumstances Garmin uses route nodes at the end of ways in their demo maps. If I don't find anything today I'll commit Steves patch. Better safe than sorry.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver at gmail.com>
Gesendet: Mittwoch, 8. Juli 2020 08:34
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

I've got feedback that with the patch from steve applied - the actual routing for that street is working again.

On Wed, 8 Jul 2020 at 08:10, Gerd Petermann <gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>> wrote:
Hi all,

I tried to reproduce the routing errors on my Oregon 600 as Felix described. I see similar problems with a map produced with r4555, but I never see good routing results in demo mode. Neither the patch from Steve nor a map produced with r4359 produce better results. For me they look even worse. I've never used the demo mode on this device so I have no idea if it ever worked or if I do something wrong. I create a short route with two nodes and select "map". The device first shows a plausible pink line but when I press OK it first tells me that the calculation may take long and then that there are no routable ways in this area.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk<mailto:rwb-mkgmap at jagit.co.uk>>
Gesendet: Dienstag, 7. Juli 2020 13:34
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

Hi Gerd

If you were to use it to experiment with routing, I'd keep updated with
the branch and use it to investigate my problem.

Ticker

On Tue, 2020-07-07 at 09:21 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't understand. When I update the branch it would identical to
> the trunk version. How does that help?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk<mailto:rwb-mkgmap at jagit.co.uk>>
> Gesendet: Dienstag, 7. Juli 2020 11:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with
> default style (and other styles)
>
> Hi Gerd
>
> I've been trying to pin down another routing problem that shows on
> MapSource and eTrex 30x & HCx, but not BaseCamp. It also happens on
> an
> old version I have (r42950) which is pre NET-no-NOD.
>
> When you were looking at some of the problems I was having with NET
> -no
> -NOD, changing the order of roads affected routing errors I was
> getting.
>
> However, most problems were only demonstrated in BaseCamp, where
> having
> a lineType that should be routable but isn't (because of the NOD
> removal or explicitly using one) makes a non-routable area around the
> feature.
>
> It would be handy if you updated the NET-no-NOD branch to the latest
> trunk.
>
> Ticker
>
> On Tue, 2020-07-07 at 08:38 +0000, Gerd Petermann wrote:
> > Hi all,
> >
> > I am back home and started to look at the data. I assume the
> > special
> > case with way
> > https://www.openstreetmap.org/way/27866666/history#map=
> > 16/40.4820/-3.9354 is that it is not connected to other roads in
> > both
> > end nodes AND that is is connected to multiple other roads between
> > the ends. I guess I didn't think of this case before.
> >
> > I can reproduce the crash with NodCheck when I create a map for
> > 64130028.osm.pbf using only the option --route, but up to now I was
> > not able to reproduce it with a smaller input file just containing
> > the area around the special way, so there might be a 2nd problem...
> >
> > Gerd
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto: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<mailto: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<mailto: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<mailto:mkgmap-dev at lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
Felix Hartman - Openmtbmap.org & VeloMap.org

_______________________________________________
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: no-arcs-first.patch
Type: application/octet-stream
Size: 1761 bytes
Desc: no-arcs-first.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200708/da717418/attachment-0001.obj>