- mkgmap-dev - The mkgmap lists

Please test new dem options in r4013 in the dem-tfb branch
by Gerd Petermann 22 Dec '17

22 Dec '17

Hi all, with r4013 I've added support to write DEM file into the overview map if option --x-dem is given. For now, it uses a hard coded value 88368 for the points distance, please suggest an option name if needed. I think DEM support works now quite well in mkgmap. So, thanks again to Frank Stinner for his work on the DEM format and his program BuildDEMFile which made this possible. Next step is to add docu for the options and maybe cleanup the code. So, if you miss an option or have suggestions for better defaults, please let me know. Gerd

3 3

mkgmap r4010
by Gerd Petermann 22 Dec '17

22 Dec '17

Hi, I've just committed r4010. I think I found the bug that caused the wrong reliefs or empty rectangles. Next step is to calculate multiple levels. @Frank: I forgot to make the number of zero bits depended on the previously calculated plateau length. The corresponding code in your program if (iPlateauLengthBinBits >= 0) // bei Plateaufollower weniger Bit erlaubt lbits -= iPlateauLengthBinBits + 1; I think that this makes only sense if a BigBin value changes something, e.g. resets a flag or increases/decreases a counter. Else it would just be a waste of space. I think you mentioned something like that in the pdf as well. Gerd

6 9

mkgmp r4012 with new --x-dem-dists option
by Gerd Petermann 22 Dec '17

22 Dec '17

Hi all, this new option allows to configure multiple DEM levels, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4012 for details. Please suggest a better option or an algorithm to detect useful values. Next step is to add DEM to the overview map... Gerd

1 0

different DEM file sizes from mkgmap and BuildDEMFile
by Gerd Petermann 21 Dec '17

21 Dec '17

Hi all, I've noticed that BuildDEMFile typically writes larger DEM files. One reason is that a missing hgt file is not treated as sea (where all heights are 0), instead --usedummyvalue seems to mean "treat as invalid". In the past, some hgt files contained such holes with invalid values, but I think nowadays better files are available. I've also noticed that the two programs sometimes interpolate slightly different value. I did not yet check which one is better. I plan to add a some unit tests to find out. Gerd

1 0

r4006: 1st alpha version to write DEM data
by Gerd Petermann 21 Dec '17

21 Dec '17

Hi all, FYI: r4006 in the dem-tdb branch implements a new option --x-dem=path_to_dir_with_hgt_files It will crash if any hgt file is missing, probably there are also other stupid problems, e.g. with negative lat/lon values. It cannot (yet) read zip files, so the directory must contain unzipped *.hgt files. The hgt files can be in 3'' or 1'' resolution, but for now DEM data is always stored with 3'' res. I plan to change that soon, so that 1'' is used if at least a part of the tile is covered by 1'' SRTM data. It doesn't yet create DEM for the overview map and it only creates DEM for level 0. So far I've only implemented a very basic hgt reader which doesn't do any interpolation, this might change soon. I did not check if the flags in the tdb file are set correctly now, I've only created some small maps for parts of the alps so far and they looked good in Basecamp /Mapsource. If you want to try this version, see http://www.mkgmap.org.uk/download/mkgmap-dem-tdb-r4006.zip @Frank: My currennt understanding is that mkgmap should do the calculation of the DEM resolution based on the levels used to create the rest of the map. I have to find out how to calculate the values for lower resolutions. I assume it has to be the average of the values, so if at res 24 we have 4 points with 123, 124,128, and 122 the value for res 23 would be Math.round((123+124+128+122)/4) = 124. For res 22 it would be the average of 4*4=16 values, and so on. Does that make sense? ciao, Gerd

7 20

Re: [mkgmap-dev] DEM File Format and mkgmap
by Guy Vandervorst 19 Dec '17

19 Dec '17

I have 2 shortcuts for Basecamp: Basecamp and Basecamp 2D. Rightclick on Basecamp 2D gives me: "C:\Program Files (x86)\Garmin\BaseCamp" /Disable3D Starting 2D gives me Basecamp with 3D-maps greyed out. Guy

3 2

Maps in *.gmap format installation directory
by Carlos Dávila 19 Dec '17

19 Dec '17

Is there a unique directory where maps in *.gmap format can be installed? I would like to change my current installers to use gmap format instead of the old format, but I don't know what is the right directory to install them. In my XP virtual box if I copy gmap folder in c:\archivos de programa(program files)\Garmin\Maps maps are read by MapSource, but not by BaseCamp. If I copy gmap folder in C:\Archivos de programa\Garmin\Basecamp\Maps then they are read by BaseCamp, but not by MapSource. And what about more recent versions of Windows?

5 4

Re: [mkgmap-dev] DEM File Format and mkgmap
by osm＠pinns 18 Dec '17

18 Dec '17

Hi Andreas I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes. I think you are right ; there is an issue. On 15/12/2017 19:30, Andreas Schmidt wrote: > Hi Frank, > > with ypur great tool I am able to > > - have3d - View in basecamp > - hillshading on Oregon600 > > Thats really amazing ! > > In Oregon there is also a menu item „3D“. Even if the map Shows Up > hillshading,, this function doesnt work. Oregon complains that the map > does Not have enough hight information. > > Could you make it work on your device? > > Andreas > > > > > > > > Gesendet mit der Telekom Mail App > <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlin…> > > > > -----Original-Nachricht----- > Von: Frank Stinner <frank.stinner(a)leipzig.de> > Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap > Datum: 08.12.2017, 09:27 Uhr > An: mkgmap-dev(a)lists.mkgmap.org.uk > Hi, > > i must confess, i have never tried to decompilea garmin dem map. I > have only playing with bit-patterns and then lookingfor the result in > mapsource. But i'm sure, that we have different algorithmsor one > algorithm with different special cases. > > My description in the pdf is (only) validfor the „TOPO Deutschland > v3“. Please see the pages 3 and 4. There area few "unknown values". > > For example see "Codierungstyp"(coding type) for a 64x64 tile. I found > in different garmin maps valuesfrom 0 to 6. 0 is the standard. It > seems to be, that the coding type haveno influence of the algorithm, > but i'm not sure. Presumable is this typeonly important for different > interpretations of the height values. BuildDEMFileuse type 1 for areas > with "unknown height". This is in this casethe interpretation for > height=maxvalue. > > Unknown is also the byte on position 0x25in the dem header. In the > „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other > maps 0x0. > > Interesting is also the word in 0x12 in evereyzoomlevel definition > (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But > i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for > heights? > > Very important is the bytes 0x0 (and 0x1)in everey zoomlevel > definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be > a number as "link" to a maplevel. But i don'treally understand the > sense ot that. We can have 6 maplevels and we cansay the maplevel 2 > and 4 are without dem's? > > In a little demo map from garmin i have see"twins" of > zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. > Perhaps 0x0 is for different and optimized output on pcand gps? > > I think, a decompiler with the algo frommy pdf is working only for > this special case: > 0x15 in dem header should be 0 (meter) > 0x25 in dem header should be 1 > 0x0 and 0x12 in every zoomlevel should 0 > > By the way, have anybody see a dem with valuesin foot? The values in > such a dem should be greater then for a dem in meter.Have anybody > height values with a precision of foot? The conversion fromfoot to > meter would be a first compression step. If garmin really use > "foot",then a different/better compression algo make sense. > > > Frank > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

4 10

Re: [mkgmap-dev] DEM File Format and mkgmap
by Andreas Schmidt 15 Dec '17

15 Dec '17

Hi Frank, with ypur great tool I am able to - have3d - View in basecamp - hillshading on Oregon600 Thats really amazing ! In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information. Could you make it work on your device? Andreas Gesendet mit der Telekom Mail App <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlin…> -----Original-Nachricht----- Von: Frank Stinner <frank.stinner(a)leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev(a)lists.mkgmap.org.uk Hi, i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases. My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values". For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue. Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0. Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights? Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's? In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps? I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0 By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense. Frank

1 0

expression not-contained
by demon.box 15 Dec '17

15 Dec '17

hi, in my style, in "relations" I have this code: set route_ref1='$(route_ref1), ${ref|not-contained:, :route_ref1}' | '${ref}'; and I have a way that is member of 3 relations with ref 3, 362 and 363 it seems like the command not-contained process only the first character because the result for route_ref1 is only 3 instead 3, 362, 363 it's a bug of mkmap or it's something desired and known? thanks --enrico -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

4 12