- mkgmap-dev - The mkgmap lists

Please test r4116
by Gerd Petermann 15 Feb '18

15 Feb '18

Hi all, Please try r4116 [1] with normal splitter. I hope you don't see any more crashes in MapSource with the "Show Profile..." button or corresponding empty "Graphs" in Basecamp, even if you hgt files contain voids or if you use --dem-poly option. I also did not see any problems with routing, so I hope that the description for field at offset 0x3f in the wiki [2] is simply wrong. Gerd [1] http://www.mkgmap.org.uk/download/mkgmap-dem-tdb-r4116.zip [2] https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/TRE_Subfile_Format

7 12

max-jobs patch
by Mike Baggaley 15 Feb '18

15 Feb '18

Hi Gerd, Please find attached a patch that amends the default behaviour if the --max-jobs option is not specified, to using a value equal to the number of CPU cores, as suggested in a previous post. The documentation is also amended to reflect the change. This halves the execution time of mkgmap for building a map of Staffordshire on my 8-core PC when --max-jobs is not specified (I didn't know about this option previously and was unaware the performance could have been improved). Cheers, Mike

6 21

Heureka!
by Gerd Petermann 14 Feb '18

14 Feb '18

Hi all, I think I found the flag that has to be set to avoid the crash: The 1st bit at offset 0x3F in TRE must be 1, not 0. The wiki says about the meaning of this one byte field: Flags: 0: detailed map, 1: transparent map, 2: show street before street number, 3: show zip before city, 4-7: ?? When bit 0 is set routing is cancelled (wilpin) Any hints where this flag might cause trouble? Gerd

4 4

Strange error in mkgmap
by franco_bez 14 Feb '18

14 Feb '18

Hi all, I stumbled over a problem in mkgmap when I build a map with my bikeroute style (an overlay-map to highlight bicycle routes) I get a non-functional map for bigger areas. There is no error message during the build process, just the resulting map file is faulty. When I remove some tiles the map is OK. It seems to be related to the size of the map, not the data itself. I composed a sample that produces a good and a bad map. Unfortunately the files are rather big. The smallest example I could build is ~600MB. I will provide a link to the example once the upload has finished. <http://gis.19327.n8.nabble.com/file/t339543/BAD.bmp> <http://gis.19327.n8.nabble.com/file/t339543/GOOD.bmp> The faulty map get displayed in the Garmin's map list as "Map data (c) OpenStreetmap" while the good map get displayed correctly as "Bikeroute" When I remove one tile from the build the map is OK. It does not matter which one I remove. So there is no error in one single tile. It has to be a more complex problem. Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

3 9

Commit r4112: Further constraint on auto block size algorithm
by svn commit 13 Feb '18

13 Feb '18

Version mkgmap-r4112 was committed by steve on Tue, 13 Feb 2018 Further constraint on auto block size algorithm Must ensure that the header&FAT fit within 240 blocks. Bug lead to file corruption for a range of file sizes. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4112

1 0

Error in style since MKGMAP mkgmap-r4106.zip
by lasemax 13 Feb '18

13 Feb '18

I get following message during my style check: Error in style: Error: (points:169): Unrecognised command 'amenity' My point file in line 169 say´s amenity=arzt { set amenity=doctors } I have many code in my style with "set" and all line with set xxxxx get an error. Regards lasmax -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 6

changes in dem-tdb branch
by Gerd Petermann 12 Feb '18

12 Feb '18

Hi all, slowly I seem to get closer to a solution for the crash problem. I've re-activated the dem-tdb branch to test some changes. With r4111 I've implemented a special option to force the problem case, so that the crash doesn't depend on the content of the hgt file or the dem-poly, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4111 When the extra flag is set, the crash is related to the position of the tile boundaries (TRE), the height and width - and therefore the overlaps - of the DEM area(s), the dem-dists values, the length of the route, the place where the route starts and ends, maybe more. I assume that MapSource makes certain assumptions about these values when the extra flag is set AND "something else" is true or false. This something might be a value in TRE or tdb, for example I've calculated a map for some tiles with the same (?) boundaries as in the Garmin map TopoGuide Hungary 2.12c. I've calculated some routes in the Garmin map and stored them in a *.gdb file. (no crashes with "Show profile..." button, data looks reasonable) I've used the same routes for the map calculated by mkgmap, I see crashes for some of them. I replaced the *.DEM data in the Garmin map by that from mkgmap and I see no crashes(!) (I made sure that I see the data calculated by mkgmap) It is difficult to create tiles with exactly the same boundary values in TRE and DEM and *.tdb, so maybe I still have to improve the code regarding rounding errors or calculation of the position. That's what I've done so far and I am still making progress... Another explanation is my conspiracy theory: It might be that MapSource is much more restrictive when the tdb file says that the map is not from Garmin, e.g. it is not lockable or whatever MapSource might use to detect that. Let's hope that this is not the case. BTW: Reg. "Show Profile.." /Graph I've learned that both MapSource and Basecamp use different DEM levels depending on the overall length of the route. With dem-dist=5520,16560,y the DEM level 0 (5520) is used for routes < ~ 29 km, 16560 is used for 29..86 km, y >= 87 With dem-dist=3312,x the DEM level 0 (3312) is used for routes < ~ 17,4 km The ratios show a constant value : 17,4 / 3312 ~ 29/5520 ~ 87 / 16560 ~ 190 The odd numbers are probably caused by different units (feet / metres). Gerd

3 6

order of subfiles in tdb and hasDem flag
by Gerd Petermann 12 Feb '18

12 Feb '18

Hi tdb experts, I've noticed that mkgmap writes the sub files (DEM, TRE, NOD,... ) in a different order compared to the Garmin maps . Also, the display tool TdbDisplay expects them in this order and reports wrong file sizes when they are in a different order. Maybe this is related to the fact that mkgmap still writes header version 407 while those Garmin maps show 411, maybe it was always wrong? "AdriaTOPO 2.40" uses this order: LBL,RGN,NET,DEM,TRE "TopoGuide Hungary 2.12c" show this order: LBL,RGN,NET,NOD,DEM,TRE mkgmap always starts with TRE. I assume the order doesn't matter, we just have to make sure that file sizes and the names are written in the same order and TdbDisplay should use the file names to determine the meaning of the size fields. Or maybe the order should be as in the Garmin maps ? Gerd

3 3

patch for crash in MapSource
by Gerd Petermann 11 Feb '18

11 Feb '18

Hi all, attached is a patch that seems to help in many cases where --dem-poly causes crashes in MapSource "Show Profile..." A binary is here: http://files.mkgmap.org.uk/download/414/mkgmap.jar It changes the TRE file and the *.tdb file. I still see a few crashes but maybe those are caused by other problems. Please try and let me know your results. I found no bad impact so far, long distance routing still seems to work, but I've not tested much. @Steve: Maybe we have to make sure that the areas in *.tdb do not overlap. In this case this patch is not yet okay. Gerd

6 24

GRAVE (WrongAngleFixer)
by Steph Ixus 11 Feb '18

11 Feb '18

Hi, I got this message compiling a map for Brazil with srtm: java.lang.AssertionError: boundary node is replaced at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.replaceCoord(WrongAngleFixer.java:111) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.access$300(WrongAngleFixer.java:51) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer$CenterOfAngle.tryChange(WrongAngleFixer.java:881) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.removeWrongAngles(WrongAngleFixer.java:373) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.optimizeWays(WrongAngleFixer.java:100) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:608) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Exiting - if you want to carry on regardless, use the --keep-going option Number of ExitExceptions: 1 And: GRAVE (WrongAngleFixer): lon-65.00_-64.00lat3.52_3.53_srtm1v3.0.osm.pbf: boundary node is replaced by node with non-equal coordinates at http://www.openstreetmap.org/?mlat=3.531611&mlon=-64.611722&zoom=17 I tried different versions of mkgmap, from the most recent to r3991 ! lon-65.00_-64.00lat3.52_3.53_srtm1v3.0.osm.pbf was made with phyghtmap and I guess the problem didn't occur when I used .osm instead of .pbf. If necessary I can re-make the .osm, but do you think the problem can be within mkgmap ? The file: http://files.mkgmap.org.uk/download/419/lon-65.00_-64.00lat3.52_3.53_srtm1v… Steph

2 2