July 2016 - mkgmap-dev - The mkgmap lists

Mapsource crashes while calculating a route
by Andrzej Popowski 29 Sep '16

29 Sep '16

Hi, I have observed crashes for some time. Mapsource 6.16.3 indicates a bug in module MPL_MAP.CPP. Basecamp reports an error or goes into infinite loop. Now I have extracted minimal source data, which creates faulty map. Removing any road or even a crossing point restore routing. Bug exist in mkgmap r2815, r2857, r2889, r2975 and r2976. Map created by mkgmap r2795 works correctly. I'm attaching here files to reproduce problem: mkgmap.bat - batch, which I have used to create the map, test-a.pbf - very simple OSM source data, route.gpx - short route, which causes a crash in Mapsource. -- Best regards, Andrzej

4 15

make the gmapsupp visible/invisible in Basecamp
by joern de 12 Sep '16

12 Sep '16

Hi developers, is there an option to make the gmapsupp visible/invisible in Basecamp? At the moment its always visible, but this is a bit annoying (since one has to wait some minutes until some hundred MBs are copied). Thanks for your ideas, Joern

5 12

[Patch v1] improve LinePreparer to reduce img size
by Gerd Petermann 06 Sep '16

06 Sep '16

Hi all, during the last days I tried to find more about the way how mkgmap stores polygons, esp. why we have some limits. While doing that I stumbled over an old comment in LinePreparer.java: // I don't care about getting the smallest possible file size so // err on the side of caution. which made me curious because I do care ;-) I found out that Garmin offers a "trick" in the delta encoding which allows to reduce the needed bytes in some cases, the imgformat-1.0.pdf explains this in detail, search for " only the sign bit is set ". This "trick" helps esp. well when coastline polygons or rivers are stored. I can explain this more detailed if somebody likes to know more, for now I'd like to hear if the trick causes any problems, I did not find any so far. A binary with this and a slightly improved overview_levels_v2.patch can be found here: http://files.mkgmap.org.uk/download/301/mkgmap.jar Depending on the data a single tile with size ~5MB may be reduced by 50 - 500+kB. Gerd

7 16

Re: [mkgmap-dev] Problems with routing on Etrek 20 with latest firmware
by Mark Bradley 22 Aug '16

22 Aug '16

> Message: 3 > Date: Thu, 28 Jul 2016 20:06:46 +0100 > From: ael <law_ence.dev(a)ntlworld.com> > To: mkgmap-dev(a)lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Problems with routing on Etrek 20 with > latest firmware > Message-ID: <20160728190646.GA4953(a)shelf.conquest> > Content-Type: text/plain; charset=us-ascii > > On Thu, Jul 28, 2016 at 12:36:03PM -0400, Greg Troxel wrote: > > > > do you have pointers to older firmware, and can you roll back to 4.20? > > Garmin seem to do their best to make it difficult to get their firmware images. > Anyway, I seem to remember reading that it was not possible to roll back to older > versions. But maybe my memory is wrong. But I don't want to risk bricking my Etrek. It > is possible that I still have the older firmware somewhere. > > > I have an etrex 30 with 2.80, which basically works. > > Yes, I am pretty sure I was on 2.80 before, and had no problems. > > I suppose a conspiracy theory would be that Garmin changed something to bread > mkgmap, but I guess it is more likely that the reverse engineering of the map format > is imperfect, and this new bug may be the opportunity to track down such > imperfections. Which is why I thought the developers' list was the right place to post. > > If I can find the old firmware image, and am sure that reverting won't brick the unit, I > will give it a try. > > I may also try some of the other maps suggested, although I am currently away from > home with limited internet bandwidth, so large maps might be a problem ATM. > > Thanks for the suggestions. > > ael You may be able to locate firmware for your unit at www.gawisp.com/perry/agree.html. Mark Bradley

3 3

Problems with routing on Etrek 20 with latest firmware
by ael 20 Aug '16

20 Aug '16

I hope this is an appropriate post for this list. Since I updated my Garmin Etrex 20 to the latest firmware (4.30 [http://www8.garmin.com/support/download_details.jsp?id=5553] I have had problems with routing with OSM maps generated with mkgmap. So far, I have only tried standard maps from http://garmin.openstreetmap.nl/ and http://extract.bbbike.org/. (My previous quick attempts to run mkgmap directly failed after I was unable to find documents that explained the process sufficiently clearly, although I may now need to try again after this problem.) Trying various routes that had always worked with previous versions of the firmware, I get a variety of symptoms including: 1) Apparent deadlocks (requiring batteries to be removed to achieve reboot); 2) "Route calculation error"; 3) "The route does not match the available maps. Cannot follow the roads precisely. Do you want to recalculate the the route?" Choosing [Yes] gives "Route calculation error. Maps do not have routable roads in this area." A quick google search only showed one similar very brief report of similar problems (although not with mgkmap/OSM so far as I could tell) after firmware 4.30 was installed. Is this a known problem? Garmin certainly changed more than they documented on this firmware revision: for example version 4.30 could not read Waypoint files written by previous versions. Thanks for any help on this. If I can help with diagnosis, please let me know. ael

5 10

Move to Java 1.8
by Gerd Petermann 18 Aug '16

18 Aug '16

Hi all, Java 1.7 is no longer maintained, so I guess that most users are already using Java 1.8 I'd like to change the build of splitter and mkgmap to use 1.8 instead of 1.7 soon, JOSM already requires 1.8. I needed a newer ant version, 1.8.4 did not work with JDK 1.8, but 1.9.7 seems to work fine. @Steve : I think we don't need a warning message for users with an older JRE, but I don't know if you need time to change the build environment? Gerd

5 17

Roundabout checks
by Mike Baggaley 03 Aug '16

03 Aug '16

Hi, I wonder whether we could add a check that any highways joining onto a roundabout only do so at the end of way, and that no more than one way joins the roundabout at any given node? This would highlight roundabouts that do not adhere to the rule of having a separate node for each entrance and exit - I believe these cause the GPS to display the incorrect exit number when routing. I suspect this check would too complex to be done in a style file. Regards, Mike

4 9

spurious data showing in Basecamp
by 987654321＠use.startmail.com 02 Aug '16

02 Aug '16

Hi I am not sure if this is the place for this question. I have created a number of maps using the latest version of mkgmap. I then sent the maps to basecamp using mapsettoolkit as layer 25. Repeatedly, I see 1 specific issue. * If I install the map in basecamp as not transparent the map appears properly. * If I install the exact same map in basecamp as transparent, spurious lines appear. However, when I use Basecamp to install the maps on the Garmin, they show properly without the spurious data. Please see attached pdf showing Basecamp screenshots of the exact same area with the same dataset with the only change being the transparency setting. I have cleared the Basecamp cache over and over to no avail.. If this is not the correct place, would you please direct me to it. Thanks Bill * Windows 7 SP1 all updates 32 bit * Basecamp 4.6.2 * mkgmap dated 4-2-2016 * mapsettoolkit v1.77 * cgpsmapper 2.5.2

3 4

Option to output polygons in size order
by Ticker Berkin 01 Aug '16

01 Aug '16

Hi I'm using splitter-r437/mkgmap-r3676 to make a map for Etrex Legend from british-isles-latest.osm.pbf from geofabric.de. Using "default" style and not using a TYP file, no land features (woods,marsh,green) show because an island polygon for "British Isles" is rendered near the end, on top of everything else. I guess that the Etrex has all area types as the same draworder and renders them in file order. I presume I could use TYP / _DrawOrder to change this behaviour slightly but I keep finding examples of woods in islands in lakes in marsh in islands etc etc, so _DrawOrder can't solve the problem. What would make everything show correctly would be to output polygons in size order, largest to smallest. Could this be done easily? either in splitter then --preserve-element-order, or in mkgmap, possibly after style processing because there will be a lot fewer polygons at this point. Regards Ticker Berkin

7 48

Re-using a splitter result
by Bernhard Hiller 31 Jul '16

31 Jul '16

From one data extract (comprising Germany, Austria, Switzerland, Czechia, Belgium, Netherlands), I create 3 maps: - a routable map for car with id 4312 - a routable map for bicycle with id 4311 - a shared map with points of interest, areas, and some lines (river, railway, etc) with id 4310 Due to an "activity routing" capable firmware, the routable maps must be separated. Currently, I call splitter 3 times, with those different ids, and different names. All other parameters for splitter stay unchanged. That process costs a lot of time. Is there some way to use the result of splitter for all three maps?

4 3