On 26.05.2010 23:40, Steve Ratcliffe wrote:


already inflicting Mapsource 6.16.1 and Basecamp 3.

OK so I upgraded to 6.16.1, had to upgrade twice to get there.

This means that also if you compile maps that are not routable, you have
to pass the --route parameter. Else the GPS / Mapsource looks into an
empty NOD table and may crash. This will happen as soon as you mix
routable maps with the non routable mkgmap created maps.

Now how exactly do I reproduce the problem?
I've not been able to.
You need to combine two different maps of the same area (so most often one being contourlines) into the same mapset (meaning same tdb/overview image/mdr/....).
Then whenever you route to an object that is inside the nonroutable map (i.e. the contourlines), Mapsource will not calculate the route but stop with:



-- Basecamp 3 will even outright get into a loop you can only escape by closing it via task-manager  (don't ask me what happens if you use it via WINE)

If you want, here is a beta map that you could install that shows the behaviour (install from d:/garmin/0mtb/mtbaustria1/ as the location is hardcoded inside the bat and the path is set for x64 windows, or exchange it with texteditor to your liking, or simply register the maps with Mapsettoolkit or by hand):
run both install* .bat files, one will install without contourlines (correct routing), and one with broken routen (*srtm*).
http://openmtbmap.x-nation.de/maps/beta/mtbaustria.7z.zip
and here a route that will show the error: http://openmtbmap.x-nation.de/maps/beta/Broken_route.zip


Sometimes it does not happen, but usually it does, it seems to depend how much other information that is routable is nearby. As to what I am told by Garmin, all future Firmwares will show the same behaviour, even worse, just having an activated mkgmap created map created without --route is then may be enough to crash the GPS.

If you rebuild the 7*.img files (the contourlines) with --route, than the problem is worked around. (to rebuilt just open the *.img with gpsmapedit, save as MP, and recompile with mkgmap).


If the flag is in TRE, then my first guess would be within
the 3 bytes from 0x43.
We don't know exactly what they are for, but some of the bits
at least affect routing (see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001473.html)

Please try the attached patch.

..Steve


_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to