- mkgmap-dev - The mkgmap lists

Commit r3695: hide-gmapsupp-on-pc.patch: add option to set flag in img header
by svn commit 11 Sep '16

11 Sep '16

Version mkgmap-r3695 was committed by gerd on Sun, 11 Sep 2016 hide-gmapsupp-on-pc.patch: add option to set flag in img header http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3695

1 0

Re: [mkgmap-dev] Large polygons and subdivisions
by Ticker Berkin 10 Sep '16

10 Sep '16

Hi Gerd Just noticed that I didn't reply to the list either! I need to change mergeShapes so that it only re-joins polygons that got split by MultiPolygonRelation, because the sorting has to be by original area, otherwise, across a subdivision join, areas might be in different order. The gmapsupp.img is 0.2% bigger (probably mostly the effect of not doing mergeShapes) When I've changed mergeShapes I need to tidy up my changes and remove quite a lot of diagnostics and I'll post a patch Regards Ticker On Sat, 2016-09-10 at 15:40 +0000, Gerd Petermann wrote: > Hi Ticker, > > sorry, just noted that I did not reply to the list. > Why do you have to disable the mergeShapes? > What is the effect on img size? > I don’t have much time for mkgmap now as I am working on some patches > for JOSM. > Feel free to post Patches to the list, maybe others like them, too. > > Gerd > > Von: Ticker Berkin > Gesendet: Samstag, 10. September 2016 17:31 > An: Gerd Petermann > Betreff: Re: AW: [mkgmap-dev] Large polygons and subdivisions > > Hi Gerd > > I've done this and haven't found any side effects yet. I had to track > the original full area of polygons and sort on this (and disable > MapBuilder.mergeShapes). It seems to fix the problems I was having. > > Ticker > > > On Fri, 2016-09-09 at 15:27 +0000, Gerd Petermann wrote: > > Hi Ticker, > > > > Yes, that’s what is happening and I hink it is intended. You may > try > > to add code that cuts the polygons > > when subdivs are split in MapSplitter, but maybe this will have > side > > effects. > > > > Gerd > > > > > > Von: Ticker Berkin > > Gesendet: Freitag, 9. September 2016 17:06 > > An: mkgmap development > > Betreff: [mkgmap-dev] Large polygons and subdivisions > > > > Hi > > > > I'm getting inconsistent displays in, for example, an area with > woods > > and a large sports area, also area of wetland with many lakes (not > > expressed as outer/inner relation). > > > > From my reading of the code, the problem occurs where the larger > > polygon crosses a subdivision boundary. It seems that its full area > > is > > allocated to just 1 subdivision, even though it might span many. > > > > In the subdivision to which the large area is allocated, it is > drawn > > first, then the small areas are drawn, overwriting nicely (because > > the > > shapes in the subdivision have been sorted by decreasing size). But > > in > > an adjacent subdivision the small areas are overwritten. > > > > Shouldn't polygons be split on subdivision boundaries? I can't see > > any > > code that does this. > > > > Regards > > Ticker Berkin > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk

1 0

Large polygons and subdivisions
by Ticker Berkin 09 Sep '16

09 Sep '16

Hi I'm getting inconsistent displays in, for example, an area with woods and a large sports area, also area of wetland with many lakes (not expressed as outer/inner relation). >From my reading of the code, the problem occurs where the larger polygon crosses a subdivision boundary. It seems that its full area is allocated to just 1 subdivision, even though it might span many. In the subdivision to which the large area is allocated, it is drawn first, then the small areas are drawn, overwriting nicely (because the shapes in the subdivision have been sorted by decreasing size). But in an adjacent subdivision the small areas are overwritten. Shouldn't polygons be split on subdivision boundaries? I can't see any code that does this. Regards Ticker Berkin

1 0

[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

"Invalid rule expression" for expression in line file after upgrade from r3649 to r3693
by Patrik Brunner 28 Aug '16

28 Aug '16

Gents, With newest release r3693 I'm having troubles creating a map with a style file 'line' containing the following expression (it worked with r3649 and earlier version): maxspeed = * & ( maxspeedkmh()>120 | maxspeed = none ) & ( highway = motorway | highway = trunk ) { set mkgmap:road-speed-class = 7 } It bailes out with the following error codes in the output: java -Xmx1536M -jar D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar --max-jobs=2 -c Freizeitkarte_CHE.cfg --check-styles Time started: Fri Aug 12 12:14:08 CEST 2016 Found one style in D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_CHE_de/style/fzk Error in style: Error: (lines:442): Invalid rule expression: (((maxspeedkmh()>120)|($maxspeed='none'))&((($highway='motorway')|($highway='trunk'))&$maxspeed=*)) could not open style fzk finished check-styles Error in style: Error: (lines:442): Invalid rule expression: (((maxspeedkmh()>120)|($maxspeed='none'))&((($highway='motorway')|($highway='trunk'))&$maxspeed=*)) Error in style: Error: (lines:442): Invalid rule expression: (((maxspeedkmh()>120)|($maxspeed='none'))&((($highway='motorway')|($highway='trunk'))&$maxspeed=*)) Error in style: Error: (lines:442): Invalid rule expression: (((maxspeedkmh()>120)|($maxspeed='none'))&((($highway='motorway')|($highway='trunk'))&$maxspeed=*)) Error in style: Error: (lines:442): Invalid rule expression: (((maxspeedkmh()>120)|($maxspeed='none'))&((($highway='motorway')|($highway='trunk'))&$maxspeed=*)) Could not open style Number of ExitExceptions: 1 When just changing the order of the expressions (without changing the logic/result) as shown below it works properly also with release r3693: maxspeed = * & ( highway = motorway | highway = trunk ) & ( maxspeedkmh()>120 | maxspeed = none ) { set mkgmap:road-speed-class = 7 } Is it possible that the 'fixes' for r3667 or r3671 fixed some errors but brought a new one in ? Or do I completely misunderstand the concept of these expressions ? Thanks for checking Patrik

2 4

mkgmap add poi2areas
by Thomas Morgenstern 28 Aug '16

28 Aug '16

Hi all, my intention is to add a POI to some spezific polygons. But not to all polygons. How must i use the option /--add-pois-to-areas ? /In Stylefile 'polygons' ? For exempel : if /sport=free_flying, /then I want a POI and {set mkgmap:area2poi=true }. Is this right ? Any hint's are welcome. Thomas

2 2

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

Re: [mkgmap-dev] Problems with routing on Etrek 20 with latest firmware
by ael 21 Aug '16

21 Aug '16

On Sun, Aug 21, 2016 at 11:28:07AM -0400, Greg Troxel wrote: > > > Thanks for posting your resolution. If I follow correctly, it sounds > like once you normalize the waypoint files, then your only real complaint > about 4.30 is startup slowness. It sounds like you can display > mkgmap-generated files and route with them. So far as I have tested, yes. I had other problems with the loss of tracks, but that looks as if I had forgotten to "umount" the Garmin volume on at least one occasion and had a corrupt vfat file system. fsck fixed that, and I have had no further problems. It would be nice if the etrek firmware did its own checks on its fat32 filesystem now and again, but it seems to be down to the (informed) user. I have had some problems with address lookup which sometimes seems to fail in circumstances where previous firmware versions worked. But I don't use that often, and haven't really explored that properly, so I could be wrong. There have always been some address failures with mgmap- generated maps in my previous experience, but it seemed to depend on how one navigated through the menus. I didn't get around to any objective analysis. As for the slow startup, I should mention that I have a 32GB sdhc card installed, and keep a large number of georeferenced photographs there, among other things. The firmware searches and locates these photographs (I don't know how to turn that off), and it seems to do that at start up. I have been steadily increasing the number of these photographs, so part of the slow down may be because of this startup search takes longer to plough through everything. Currently I have around 7GB of these pictures, so even just looking at the exif tags takes some time. If I was designing the firmware, I would do the search after the initial boot. Another plausible reason for the slower start up is that the firmware was trying and failing to parse the "old" Waypoint files. Since I have converted them with gpsbabel and cleaned out the old crud, my subjective impression is that the start up is a little less slow. > I have much older firmware on my Etrex 30, and this makes me inclined to > update, since in general it seems like some bugs are likely to be > fixed. But maybe I should hold off... As I have only recently cleaned up the Waypoints, I don't yet have enough experience to give a firm answer. But I think it should be reasonably safe. Good luck! ael

1 0

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

o5m plugin for JOSM
by Gerd Petermann 19 Aug '16

19 Aug '16

Hi all, some years ago I wrote a JOSM plugin to allow the import of o5m files. I've now managed to add this to the JOSM plugin list. If you use the --output=o5m option in splitter this might help. It works similar to the pbf plugin. Gerd

1 0