- mkgmap-dev - The mkgmap lists

what do the 0x4a polygon in the mean?
by Gerd Petermann 14 Jan '18

14 Jan '18

Hi experts, today I played with a map that has non-rectangular shape. I tried this: Use the dem-poly option to cut also the 0x4b polygon for each tile, use these 0x4b polygons also in the overview map and also for 0x4a in the overview map. I expected that this would create nicer maps but found no effect in MapSource. I tried this with the sample from Andrzej. The DEM data in the Winterkarte does not show the steps which are produced by mkgmap at polygon boundary. What am I doing wrong? Gerd

3 11

DEM file and the block-size option
by Gerd Petermann 14 Jan '18

14 Jan '18

Hi all, the current default block-size is 512. This is used for most *.img files and gives a maximum file size of 65534*512 ~ 32MB. For large DEM files you might need a --block-size=1024 or even 2048. If I got that right you may run into the next problem when using this option as the mdr file will be also created with this value, and if no value is given it uses 16384 (which means the mdr file can grow close to 1GB) This disadvantage of a larger block-size is that your img files are typically a bit larger. @Steve: If I got that right we should be able to calculate the optimal block-size as we do know the number of bytes that we will write to the img-file before anything is actually written to the disk. Wouldn't that be much better? Gerd

5 15

The 0x4b background polygon in the overview map
by Gerd Petermann 12 Jan '18

12 Jan '18

Hi all, up to now mkgmap always creates a rectangular 0x4b polygon for the overview map. I wonder if I should change that so that the 0x4b polygons of the sub tiles are used. This seems to be the better way if we start using non-rectangular 0x4b polygons? Gerd

4 18

DemDisplay supports now img files with GMP
by Gerd Petermann 12 Jan '18

12 Jan '18

Hi all, thanks to hints from Andrzej DemDisplay is now able to read DEM data from NT map (GMP format). See http://www.mkgmap.org.uk/websvn/revision.php?repname=display&rev=516 New binary: http://www.mkgmap.org.uk/websvn/revision.php?repname=display&rev=516 Usage is the same as before. Winterkarte uses these dem-dists values: 9936, 19872, 44176, 88368 Strangly, it seems to encode DEM tiles outside the 0x4B polygon exactly the way mkgmap did before r4048. Maybe this works because MapSource and Basecamp don't even try to read that data. Gerd

2 1

option --show-profiles and DEM
by Gerd Petermann 12 Jan '18

12 Jan '18

Hi all, the help says --show-profiles=1 Sets a flag in tdb file which marks set mapset as having contour lines and allows showing profile in MapSource. Default is 0 which means disabled. I've tried this with MapSource. My findings: The option is not related to contour lines, those are always displayed and height is shown when you select one. I found two effects of show-profiles=1: 1) The button "Show Profile..." in the Route Properties popup is enabled even if no DEM data is available. Without DEM data this button is of no use, the displayed profile is a straight line at height 0. 2) With DEM data available Mapsource displays the height in the status line when you hover over a hill-shaded area with valid data. The button "Show Profile..." in the Route Properties popup is always enabled when DEM data is available. My conclusion: The option is useless without DEM data and with DEM data it should default to --show-profiles=1 In other words: I think the option should be removed and the flag should be set depending on the DEM data. Comments? Gerd

10 32

dem-poly and precomp-sea
by Gerd Petermann 12 Jan '18

12 Jan '18

Hi all, I think that the bounding polygon given with option --dem-poly should be also be used in the precomp-sea option, so that mkgmap doesn't generate sea polygons outside of the bounding polygon. With the current code a map of e.g. scandinavia looks strange, see attached picture. In a further step I should try to use that polygon also for the background polygon (0x4B) and other data. In a final step we might be able to use it for routing data so that you can split maps at left-driving / right-driving boundaries, but that needs more thinking. I've not coded anything yet, but I wonder if the option should be changed from dem-poly to e.g. --polygon-file or --bounding-polygon. Gerd

5 5

HGT - getElevation()
by Andrzej Popowski 11 Jan '18

11 Jan '18

Hi, I have looked at code and get some doubts. File HGTConverter.java, function getElevation(). Shouldn't conversion double -> int use Math.floor? I mean these lines: int row = (int) ((lat32 - minLat32) * FACTOR); int col = (int) ((lon32 - minLon32) * FACTOR); int xLeft = (int) x1; int yBottom = (int) y1; I'm not sure, but I think, you won't get left/bottom value of coordinate for negative number. -- Best regards, Andrzej

3 16

--gmapi not in parameter list
by Henning Scholland 11 Jan '18

11 Jan '18

Hi, is there a reason for not listing --gmapi in the documentation (at least on website)? Description can be simply: Outputs map in gmap-format. Btw: In overview map DEM, LBL, RGN and TRE don't follow map-id based file name, but using 62340000. In my case it should be 10050000. NET and NOD and all map tiles are fine. Henning

3 6

r4044: changes in doc and help
by Gerd Petermann 11 Jan '18

11 Jan '18

Hi all, the discussion about show-profiles got a bit confused, so I've now committed my current knowledge. Please review http://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap&path=%2Fbranches%2F… BTW: I found no problem with a map without DEM and without contour lines created with show-profiles=1. The button "Show profile..." is disabled in MapSource and Basecamp says "The current map does not contain any elevation data on the selected route(s)" Don't know if the false flag costs time when Mapsource/Basecamp try to find data that doesn't exist. Gerd

1 0

DEM format is better than zip
by Gerd Petermann 10 Jan '18

10 Jan '18

Hi all, FYI: Today I've coded a quick+dirty solution to use Garmins DEM format to compress hgt files. The compression ratio is much better than that of zip, on average the file is < 50% of the zip file, and the format should allow nearly random access, so maybe it would be the better input for mkgmap. I've also compared with bzip2 (with -9 = highest compression), file sizes are similar to DEM. I've not coded the decompressor, but I've used DemDisplay to verify that it works in principle. Complete code to compress + decompress would take some days. I see no real use case for this at the moment, just wanted to let you know. Gerd

1 0