January 2018 - mkgmap-dev - The mkgmap lists

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

mkgmap r4042 improves interpolation and thus reduces DEM sizes
by Gerd Petermann 10 Jan '18

10 Jan '18

Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4042 Details are discussed here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027628.html Thanks to Andrzej for this patch, I think it is another good improvement. A nice side effect of the better interpolation is that DEM sizes are a bit smaller. So, maybe also try higher dem-dist values now. Gerd

1 0

one mistake less in DEM
by Frank Stinner 09 Jan '18

09 Jan '18

Hi, there is a new BuildDEMFile-version with a rectified encoder. This should help on maps with strong changes in height. Example: East 79,335° / North 42,554°, PointDistance 55000 -> 0,004610° Hi Gerd, there seems to be a limitation for my variable "sumH" for the calculation of hunit. Perhaps garmin use only a 2-byte-var. I have included in CodingTypeStd.addValue() after "SumH += dh;": if (SumH + unitdelta + 1 >= 0xFFFF) SumH -= 0x10000; I have no idea, why not "if (SumH + unitdelta > 0xFFFF)" or so. I have done the same with CodingTypePlateauFollowerNotZero.AddValue() and CodingTypePlateauFollowerZero.AddValue(). Frank

2 1

Re: [mkgmap-dev] Performance with zipped hgt files
by Frank Stinner 09 Jan '18

09 Jan '18

Hi Gerd, at last you need the data uncompressed in a buffer, right? That's why i see no difference between using compressed or uncompressed hgt files. Compressed files need a little bit more time for uncompressing, but after that the data need the same size in memory. That's why i see no vantage for mkgmap if the data are stored in an other form. It can only save disc space, no heap space. What speaks against a limitation for the extent of a maptile? This limited the count of hgt's for one maptile too. You have the option --max-areas for splitter. We need only an additional option like --maxextent or whatever. Perhaps we have then maptiles without points, lines or areas (on oceans, deserts or so), but why not? Frank

3 7