Re: [mkgmap-dev] MapSource crash with DEM: Maybe tdb file needs changes?
Hi all, thanks for the input. I still have no idea what this size value might be but I agree that it doesn't seem to have an influence on the crash. I also tried changing several other of the unknown fields and found no change. I also tried to change the tdb to version 411, no change reg. crash. I do now try to reproduce the problem with tiles that have the same coordinates as those in the Garmin map. Gerd Von: mkgmap-dev im Auftrag von Steve Ratcliffe Gesendet: Montag, 5. Februar 2018 12:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] MapSource crash with DEM: Maybe tdb file needs changes? Hi > It seems that mkgmap writes some constants that might be important, e.g. > MapDetailBlock.java contains > //01 c3 00 ff > os.write4(0xff00c301); > os.write(0); > os.write(0); > os.write(0); I've just looked at this. No idea where any of those came from :) I think those 7 bytes should be: 1 byte: unknown to me 1 byte: Maybe index into block 'S' (0x53) 1 byte: index into block 'R' (0x52) or zero if no block 'R' 4 bytes: a size that is generally related to the size of the file. cgpsmapper and gmaptool set this size to 256 (and previously to 255) Block R has the following structure: 1 byte: index number, starting from 1 n bytes: zero terminated string There is probably only ever one of these. Eg "Europe guide v1" Gmaptool appears to create one of these with the name "All". Block S has the following structure: 1 byte: number, probably index into block R 1 byte: number index in this block, starting from 1 n bytes: zero terminated string name eg: 1,1 "Region 1 - Aus/Switz/N.Italy" 1,2 "Region 2 - France" 1,3 "Region 3 - Germany/Czech Republic" ... Unfortunately I think they have nothing to do with DEM as maps without DEM have these. There are lots of unknown entries in the TDB header, there could be something there. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] My findings about the crash in MapSource
Hi Gerd, > I only have one routable map with DEM data See this nice post by moderator on Garmin Forum: https://forum.garmin.de/showthread.php?49979-TopV7-Routen-aus-markierten-Wegen&p=247707#post247707 These maps work in BaseCamp, when placed on pendrive. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4103: improve description of DEM options
Hi all, I am wondering why the DEM-features are titled „Hillshading Options“. The most valuable function of DEM (which I was missing for a long time) is the 3d-View in Basecamp when planning trips. This should be promoted with a appropriate headline :) Andreas > Am 03.02.2018 um 11:21 schrieb svn commit : > > Version mkgmap-r4103 was committed by gerd on Sat, 03 Feb 2018 > > improve description of DEM options > > dem-options2.patch by Carlos Dávila, changes in options.txt > should be similar > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4103 > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] max-jobs patch
Hi Gerd, I think it's even more in combination with DEM. I usually use 6 of my 8 cores and ending up with 10 to 12 GB of heap. So I definitely agree with you available heap somehow needs to be considered as well. Not only CPU cores. Btw. for CFD/FEM analysis the simulation is usually is faster if you only use physical cores, not the 'virtual' ones. Don't know how mkgmap will behave. Henning On 05.02.2018 15:28, Gerd Petermann wrote: > Hi Mike, > > thought about this again. Maybe this change is too simple. With multiple jobs > one also > needs more heap (-Xmx JRE option). If you create rather large tiles with > splitter (max-nodes=160) > you need 0.5 - 1 GB for each job. Not sure what happens when a user creates a > map with > 10 tiles on an 8-core machine without any -Xmx option. > > I fear this will result in OutOfMemory exception, so better check the > available heap as well. > > Gerd > > > Von: mkgmap-dev im Auftrag von Mike > Baggaley > Gesendet: Sonntag, 4. Februar 2018 15:14 > An: 'Development list for mkgmap' > Betreff: [mkgmap-dev] max-jobs patch > > 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 > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource crash with DEM: Maybe tdb file needs changes?
Hi It seems that mkgmap writes some constants that might be important, e.g. MapDetailBlock.java contains //01 c3 00 ff os.write4(0xff00c301); os.write(0); os.write(0); os.write(0); I've just looked at this. No idea where any of those came from :) I think those 7 bytes should be: 1 byte: unknown to me 1 byte: Maybe index into block 'S' (0x53) 1 byte: index into block 'R' (0x52) or zero if no block 'R' 4 bytes: a size that is generally related to the size of the file. cgpsmapper and gmaptool set this size to 256 (and previously to 255) Block R has the following structure: 1 byte: index number, starting from 1 n bytes: zero terminated string There is probably only ever one of these. Eg "Europe guide v1" Gmaptool appears to create one of these with the name "All". Block S has the following structure: 1 byte: number, probably index into block R 1 byte: number index in this block, starting from 1 n bytes: zero terminated string name eg: 1,1 "Region 1 - Aus/Switz/N.Italy" 1,2 "Region 2 - France" 1,3 "Region 3 - Germany/Czech Republic" ... Unfortunately I think they have nothing to do with DEM as maps without DEM have these. There are lots of unknown entries in the TDB header, there could be something there. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource crash with DEM: Maybe tdb file needs changes?
Hi Gerd, > The wiki [1] describes these 7 bytes as > "byte:0 has copyright text,byte 1: has 0x53 text : byte 2:if 1 then > bytes 3_7: an unknown total (density) " For gmaptool I have assumed following meaning of these data: byte 0 - always 1 byte 1 - region (always 1) byte 2 - subregion (always 0) bytes 3-6 - always 0 1 0 0 Region and subregion are extension to family ID and product ID and are used for coding unlock keys. I have replaced original TDB by a TDB created by gmaptool and map still crashes, so I assume these values aren't important. Gerd, don't you have access to tdb from Adria Topo? There is Hungary TopoGuide available too: http://www.garmin.hu/topoguide-magyarorszag-v212c -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource crash with DEM: Maybe tdb file needs changes?
Hi Gerd Have been checking a few garmin tdbs and it appears that while the first 3 bytes remain the same for each, ie 01 00 00, the last four bytes are always different and never zero ! also ,except with mkgmap tiles, I have not come across C3 in the second byte ie a 01 *c3 *00 Nick On 05/02/2018 08:36, Gerd Petermann wrote: Hi, Ive discussed with Frank if there might be a field in the tdb file that has to be changed. Maybe there is a value that tells MapSource something about the alignment of DEM data? I don't have a single original Garmin tdb file :-( It seems that mkgmap writes some constants that might be important, e.g. MapDetailBlock.java contains //01 c3 00 ff os.write4(0xff00c301); os.write(0); os.write(0); os.write(0); The wiki [1] describes these 7 bytes as "byte:0 has copyright text,byte 1: has 0x53 text : byte 2:if 1 then bytes 3_7: an unknown total (density)" The display tool seems to expect something similar to the wiki: d.rawValue(2, "01 01"); d.byteValue("intro flag"); d.intValue("intro %d"); Any idea what this "intro" or "unknown total(density) could be ? And what is the 0x53 text? [1]https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/TDB_File_Format Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] MapSource crash with DEM: Maybe tdb file needs changes?
Hi, Ive discussed with Frank if there might be a field in the tdb file that has to be changed. Maybe there is a value that tells MapSource something about the alignment of DEM data? I don't have a single original Garmin tdb file :-( It seems that mkgmap writes some constants that might be important, e.g. MapDetailBlock.java contains //01 c3 00 ff os.write4(0xff00c301); os.write(0); os.write(0); os.write(0); The wiki [1] describes these 7 bytes as "byte:0 has copyright text,byte 1: has 0x53 text : byte 2:if 1 then bytes 3_7: an unknown total (density) " The display tool seems to expect something similar to the wiki: d.rawValue(2, "01 01"); d.byteValue("intro flag"); d.intValue("intro %d"); Any idea what this "intro" or "unknown total(density) could be ? And what is the 0x53 text? [1]https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/TDB_File_Format Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev