My findings about the crash in MapSource
Hi all, I found out that whenever mkgmap r4100 wrote a tile with DEM data that has the "extra flag" set to 2 (which means that the tile contains invalid height information which should be ignored) I was able to reproduce the crash in MapSource when clicking on "Show profile..." for a route which crosses the boundaries of this tile I found one error in the code for the --dem-poly option. This produced too many "invalid" values, even for tiles which are completely inside the bounding polygon. I fixed that with r4101. Still, the same problem occurs when a hgt file contains too many voids or the tile is in fact partly outside the polygon. It seems that Andrzejs patch dem-align-6.patch is part of the problem. When I disable parts of the code with the attached patch the problem seems to disappear. Gerd
Hi Gerd, maybe this is a problem of overlapping of DEM form different tiles? Or maybe size of DEM area is calculated incorrectly? Could you upload an example? I haven't used dem-poly on my maps and never noticed this problem. -- Best regards, Andrzej
Hi Andrzej, I also think that it could be related to the alignment of DEM tiles. I think the problem is not (only) related to dem-polygon, you should be able to reproduce it when you change line 109 in DEMSection.java from boolean hasExtra = false; to boolean hasExtra = true; The polygon handling simply forces that this variable is set to true and when this happens I see the crashes, although it only changes the size of the header info. I'll prepare a test set tomorrow. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Freitag, 2. Februar 2018 22:14 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Gerd, maybe this is a problem of overlapping of DEM form different tiles? Or maybe size of DEM area is calculated incorrectly? Could you upload an example? I haven't used dem-poly on my maps and never noticed this problem. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, I've uploaded my test data: http://files.mkgmap.org.uk/download/411/baddem6.7z Please adjust the hard coded paths so that splitter r590 and mkgmap r4102 are used. The script produces a few small tiles with splitter and 4 maps with slightly different options I think the hgt file in SRTM3_orig contains no voids, so I created a copy and placed a few voids (0x8000) into it. Those voids appear only in tile 63240004. The file crash.gdb contains two routes crossing tiles. The one starting in City park causes crashes in MapSource (version 6.16.3) when you don't use the map in folder map\orig\OSM map.gmap This changes when you compile r4102 with the no-dem-align.patch. The other route never causes a crash because all tiles have no extra flag. This changes when you use r4100. My current understanding is that there is a problem when mkgmap r4102 writes tiles with the has extra flag set to true. All routes crossing tile borders of those tiles seem to produce the crash. BTW: BuildDEMFile doesn't align and produces DEM which doesn't crash. That's why I thought that the alignment might be the problem. I guess that we should increase or decrease the overlap of the DEM tiles. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 2. Februar 2018 22:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Andrzej, I also think that it could be related to the alignment of DEM tiles. I think the problem is not (only) related to dem-polygon, you should be able to reproduce it when you change line 109 in DEMSection.java from boolean hasExtra = false; to boolean hasExtra = true; The polygon handling simply forces that this variable is set to true and when this happens I see the crashes, although it only changes the size of the header info. I'll prepare a test set tomorrow. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Freitag, 2. Februar 2018 22:14 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Gerd, maybe this is a problem of overlapping of DEM form different tiles? Or maybe size of DEM area is calculated incorrectly? Could you upload an example? I haven't used dem-poly on my maps and never noticed this problem. -- Best regards, Andrzej _______________________________________________ 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
Hi Gerd, I have compiled baddem6 and I confirm your observations. I have no idea, what to do with it. I have found a minor error, see attached patch. Mkgmap calculates min/max heights for header using values form tiles, which have bitstream data. This is wrong for flat surfaces, which have height but no bitstream and for voids, which have bitstream without real heights. I also removed bitstream for tiles with all voids, but I don't know the reason for putting it in first place, so maybe it is wrong change. -- Best regards, Andrzej
Hi Andrzej, your patch reverts that change that I made r4048 to solve your problems with empty areas. Maybe it is no longer needed since 4101? http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027704.html Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Samstag, 3. Februar 2018 20:39 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Gerd, I have compiled baddem6 and I confirm your observations. I have no idea, what to do with it. I have found a minor error, see attached patch. Mkgmap calculates min/max heights for header using values form tiles, which have bitstream data. This is wrong for flat surfaces, which have height but no bitstream and for voids, which have bitstream without real heights. I also removed bitstream for tiles with all voids, but I don't know the reason for putting it in first place, so maybe it is wrong change. -- Best regards, Andrzej
Hi all, maybe you can help: It seems that the crash is related to the alignment of the tiles, so I try to find out the relation between alignment of tile boundaries and DEM. I only have one routable map with DEM data (topo 2010 demo ), it is a gmapsupp.img with several tiles spread over Germany that are not connected. I used this gmaptool command gmt -s gmapsupp.img to split it into various *.img and used display tool to extract the tile boundaries from the TRE file of each img TreDisplay creates a long report containing lines like this: 00000015 | 8a 67 25 | north boundary 2451338 00000018 | d0 95 07 | east boundary 497104 0000001b | 20 43 25 | south boundary 2442016 0000001e | 20 59 07 | west boundary 481568 | | In degrees lat,lon: 52,4000,10,3333 52,6000,10,6667 I was only interestend in the last line, so I used this one line command: del bounds && for %i in (*.img) do java -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.TreDisplay %i | grep "In degrees" >> bounds to create this list of tile boundaries in file bounds: | | In degrees lat,lon: 54,2000,9,0000 54,4000,9,3334 | | In degrees lat,lon: 54,0000,11,3739 54,2069,12,0000 | | In degrees lat,lon: 53,4000,9,6666 53,6000,10,0000 | | In degrees lat,lon: 53,0000,8,6666 53,2000,9,0000 | | In degrees lat,lon: 52,4000,10,3333 52,6000,10,6667 | | In degrees lat,lon: 52,4000,13,0000 52,6000,13,3334 | | In degrees lat,lon: 52,0000,13,6666 52,2000,14,0000 | | In degrees lat,lon: 51,8000,11,6667 52,0000,12,0000 | | In degrees lat,lon: 51,2000,8,0000 51,4000,8,3333 | | In degrees lat,lon: 51,0000,13,0000 51,2000,13,3334 | | In degrees lat,lon: 50,8000,10,6667 51,0000,11,0000 | | In degrees lat,lon: 49,8000,6,6666 50,0000,7,0000 | | In degrees lat,lon: 49,6000,8,3333 49,8000,8,6667 | | In degrees lat,lon: 49,1512,6,5475 49,4000,7,0000 | | In degrees lat,lon: 48,8000,11,6667 49,0000,12,0000 | | In degrees lat,lon: 48,6000,8,3333 48,8000,8,6667 It is obvious that Garmin preferred splits neer 1/5 degrees for lat and 1/3 degrees for lon in this map. If you have another routable Garmin map with DEM it would be great if you could try this as well and report the results for your maps, presuming that MapSource doesn't crash with Garmin maps. I've uploaded the latest display tool binary here: http://files.mkgmap.org.uk/download/413/display.jar Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 3. Februar 2018 20:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Andrzej, your patch reverts that change that I made r4048 to solve your problems with empty areas. Maybe it is no longer needed since 4101? http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027704.html Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Samstag, 3. Februar 2018 20:39 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Gerd, I have compiled baddem6 and I confirm your observations. I have no idea, what to do with it. I have found a minor error, see attached patch. Mkgmap calculates min/max heights for header using values form tiles, which have bitstream data. This is wrong for flat surfaces, which have height but no bitstream and for voids, which have bitstream without real heights. I also removed bitstream for tiles with all voids, but I don't know the reason for putting it in first place, so maybe it is wrong change. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
.oops, just noticed that I used grep in my command, this is probably not in your Windows path. So please use Mircosofts findstr instead: del bounds && for %i in (*.img) do java -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.TreDisplay %i | findstr "In degrees" >> bounds Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 4. Februar 2018 10:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi all, maybe you can help: It seems that the crash is related to the alignment of the tiles, so I try to find out the relation between alignment of tile boundaries and DEM. I only have one routable map with DEM data (topo 2010 demo ), it is a gmapsupp.img with several tiles spread over Germany that are not connected. I used this gmaptool command gmt -s gmapsupp.img to split it into various *.img and used display tool to extract the tile boundaries from the TRE file of each img TreDisplay creates a long report containing lines like this: 00000015 | 8a 67 25 | north boundary 2451338 00000018 | d0 95 07 | east boundary 497104 0000001b | 20 43 25 | south boundary 2442016 0000001e | 20 59 07 | west boundary 481568 | | In degrees lat,lon: 52,4000,10,3333 52,6000,10,6667 I was only interestend in the last line, so I used this one line command: del bounds && for %i in (*.img) do java -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.TreDisplay %i | grep "In degrees" >> bounds to create this list of tile boundaries in file bounds: | | In degrees lat,lon: 54,2000,9,0000 54,4000,9,3334 | | In degrees lat,lon: 54,0000,11,3739 54,2069,12,0000 | | In degrees lat,lon: 53,4000,9,6666 53,6000,10,0000 | | In degrees lat,lon: 53,0000,8,6666 53,2000,9,0000 | | In degrees lat,lon: 52,4000,10,3333 52,6000,10,6667 | | In degrees lat,lon: 52,4000,13,0000 52,6000,13,3334 | | In degrees lat,lon: 52,0000,13,6666 52,2000,14,0000 | | In degrees lat,lon: 51,8000,11,6667 52,0000,12,0000 | | In degrees lat,lon: 51,2000,8,0000 51,4000,8,3333 | | In degrees lat,lon: 51,0000,13,0000 51,2000,13,3334 | | In degrees lat,lon: 50,8000,10,6667 51,0000,11,0000 | | In degrees lat,lon: 49,8000,6,6666 50,0000,7,0000 | | In degrees lat,lon: 49,6000,8,3333 49,8000,8,6667 | | In degrees lat,lon: 49,1512,6,5475 49,4000,7,0000 | | In degrees lat,lon: 48,8000,11,6667 49,0000,12,0000 | | In degrees lat,lon: 48,6000,8,3333 48,8000,8,6667 It is obvious that Garmin preferred splits neer 1/5 degrees for lat and 1/3 degrees for lon in this map. If you have another routable Garmin map with DEM it would be great if you could try this as well and report the results for your maps, presuming that MapSource doesn't crash with Garmin maps. I've uploaded the latest display tool binary here: http://files.mkgmap.org.uk/download/413/display.jar Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 3. Februar 2018 20:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Andrzej, your patch reverts that change that I made r4048 to solve your problems with empty areas. Maybe it is no longer needed since 4101? http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027704.html Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Samstag, 3. Februar 2018 20:39 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Gerd, I have compiled baddem6 and I confirm your observations. I have no idea, what to do with it. I have found a minor error, see attached patch. Mkgmap calculates min/max heights for header using values form tiles, which have bitstream data. This is wrong for flat surfaces, which have height but no bitstream and for voids, which have bitstream without real heights. I also removed bitstream for tiles with all voids, but I don't know the reason for putting it in first place, so maybe it is wrong change. -- Best regards, Andrzej _______________________________________________ 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
Hi Minko, thanks for the link. I tried the biking map. This map seems to avoid the problem. They don't set the extra flag that is causing trouble, that means the DEM data doesn't contain voids (or invalid/unknown heights), and they don't use irregular bounds so they don't have a need to mark height values as "invalid" or "unknown" . I assume that they have interpolated the voids in the hgt file (if any). They also seem to prefer splits at 1/2 degrees for lat and lon while also aligning the upper left corner to multiples of dem-dist which is the common 3312. So, maybe that's they way to go. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von lig fietser <ligfietser@hotmail.com> Gesendet: Sonntag, 4. Februar 2018 11:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Gerd, Maybe you can have a look here: http://openmaps.eu/garmindownload _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, ich versuche es jetzt auf diesem Weg. Dein Mail-Provider scheint ein Problem zu haben. Jedenfalls meckert hotmail-com.olc.protection.outlook.com immer bei meiner Mail. ich habe gerade das Beispiel 6b (ohne BuildDEMFile) ausprobiert. Die Varianten mod und org funktionieren, die beiden poly-Varianten stürzen ab. Ich habe das nicht richtig verfolgt. Was genau bewirkt die Option --dem-poly? Werden da nur bestimmte Bereiche der DEM-Daten mit nodata gefüllt, also eine Art clipping? Oder passiert da noch irgendetwas anderes? Ich habe mir die Transalpin nochmal angesehen. An der Adria gibt es auch Bereiche mit Codingtype 2. Das Höhenprofil für eine Route wird angezeigt. Die TDB-Header sind, abgesehen von der Family-ID, identisch. Die bei mir als Unknown bezeichneten Bytes für eine Kartenkachel sind aber z.T. unterschiedlich: Transalpin Mapnumber (4 Byte): 16596754 / 0xFD3F12 Mapnumber (4 Byte): 63240001 / 0x3C4F741 ParentMapnumber (4 Byte): 16596991 / 0xFD3FFF ParentMapnumber (4 Byte): 63240000 / 0x3C4F740 North (4 Byte): 544029184 / 0x206D3A00; 45,5999994277954° North (4 Byte): 624689152 / 0x253C0000; 52,36083984375° East (4 Byte): 150324224 / 0x8F5C400; 12,6000308990479° East (4 Byte): 129564672 / 0x7B90000; 10,8599853515625° South (4 Byte): 539256832 / 0x20246800; 45,1999855041504° South (4 Byte): 622657536 / 0x251D0000; 52,1905517578125° West (4 Byte): 145551360 / 0x8ACF000; 12,1999740600586° West (4 Byte): 127074304 / 0x7930000; 10,6512451171875° Description (8 Byte): 'Venezia' Description (26 Byte): 'OSM street map (63240001)' Unknown1 (2 Byte): 7 / 0x7 Unknown1 (2 Byte): 7 / 0x7 SubCount (2 Byte): 6 / 0x6 SubCount (2 Byte): 6 / 0x6 Size: Size: (4 Byte): 159678 / 0x26FBE (4 Byte): 4307 / 0x10D3 (4 Byte): 767091 / 0xBB473 (4 Byte): 374556 / 0x5B71C (4 Byte): 50029 / 0xC36D (4 Byte): 25407 / 0x633F (4 Byte): 256693 / 0x3EAB5 (4 Byte): 52340 / 0xCC74 (4 Byte): 487497 / 0x77049 (4 Byte): 140926 / 0x2267E (4 Byte): 601379 / 0x92D23 (4 Byte): 11916 / 0x2E8C HasCopyright (1 Byte): 1 / 0x1 HasCopyright (1 Byte): 1 / 0x1 Unknown2 (1 Byte): 1 / 0x1 Unknown2 (1 Byte): 195 / 0xC3 Unknown3 (1 Byte): 0 / 0x0 Unknown3 (1 Byte): 0 / 0x0 Unknown4 (1 Byte): 0 / 0x0 Unknown4 (1 Byte): 255 / 0xFF Unknown5 (1 Byte): 1 / 0x1 Unknown5 (1 Byte): 0 / 0x0 Unknown6 (1 Byte): 0 / 0x0 Unknown6 (1 Byte): 0 / 0x0 Unknown7 (1 Byte): 0 / 0x0 Unknown7 (1 Byte): 0 / 0x0 Name: Name: (13 Byte): 'I0FD3F12.LBL' (13 Byte): '63240001.TRE' (13 Byte): 'I0FD3F12.RGN' (13 Byte): '63240001.RGN' (13 Byte): 'I0FD3F12.TRE' (13 Byte): '63240001.LBL' (13 Byte): 'I0FD3F12.NET' (13 Byte): '63240001.NET' (13 Byte): 'I0FD3F12.NOD' (13 Byte): '63240001.NOD' (13 Byte): 'I0FD3F12.DEM' (13 Byte): '63240001.DEM' Unknown8 (8 Byte): 0 / 0x0 Unknown8 (8 Byte): 0 / 0x0 Unknown9 (9 Byte): 0 / 0x0 Unknown9 (9 Byte): 0 / 0x0 Die Punkte links-oben sind immer Vielfache des Punktabstandes. Aber Garmin nimmt es offensichtlich nicht so ganz ernst damit, wirklich den zur TRE-Position nächstliegenden Punkt zu nehmen. DEM: PointDistance 3312 / 0xCF0 13248 / 0x33C0 26512 / 0x6790 53024 / 0xCF20 Left 145549152 / 0x8ACE760 145542528 / 0x8ACCD80 145524368 / 0x8AC8690 145497856 / 0x8AC1F00 Top 544032432 / 0x206D46B0 544042368 / 0x206D6D80 544052752 / 0x206D9610 544079264 / 0x206DFDA0 TRE Diff. zu DEM West: 568560 / 0x8ACF0 -> 145551360 2208 8832 26992 (!) 53504 (!) North: 2125114 / 0x206D3A -> 544029184 -3248 -13184 -23568 -50080 Ich glaube, man sollte eher mit den "Unknown"-Bytes in der TDB experimentieren. Frank --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
Hallo Frank, wenn ich das richtig in Erinnerung habe, sollte nur die Variante orig funktionieren, kann aber sein, dass das nur mit dem crash.dbg aus baddem6.zip so ist. Ja, --dem-poly sorgt dafür, das für Punkte ausserhalb des Polygons der Wert UNDEF (1) zurückgegeben wird, so wie auch für voids in hgt files. Die tdb Dateien schaue ich mir mal genauer an. ciao, Gerd (1) kann per Parameter --x-dem-outside-polygon=x überschrieben werden ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Frank Stinner <Frank.Stinner@kabelmail.de> Gesendet: Sonntag, 4. Februar 2018 16:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] My findings about the crash in MapSource Hi Gerd, ich versuche es jetzt auf diesem Weg. Dein Mail-Provider scheint ein Problem zu haben. Jedenfalls meckert hotmail-com.olc.protection.outlook.com immer bei meiner Mail. ich habe gerade das Beispiel 6b (ohne BuildDEMFile) ausprobiert. Die Varianten mod und org funktionieren, die beiden poly-Varianten stürzen ab. Ich habe das nicht richtig verfolgt. Was genau bewirkt die Option --dem-poly? Werden da nur bestimmte Bereiche der DEM-Daten mit nodata gefüllt, also eine Art clipping? Oder passiert da noch irgendetwas anderes? Ich habe mir die Transalpin nochmal angesehen. An der Adria gibt es auch Bereiche mit Codingtype 2. Das Höhenprofil für eine Route wird angezeigt. Die TDB-Header sind, abgesehen von der Family-ID, identisch. Die bei mir als Unknown bezeichneten Bytes für eine Kartenkachel sind aber z.T. unterschiedlich: Transalpin Mapnumber (4 Byte): 16596754 / 0xFD3F12 Mapnumber (4 Byte): 63240001 / 0x3C4F741 ParentMapnumber (4 Byte): 16596991 / 0xFD3FFF ParentMapnumber (4 Byte): 63240000 / 0x3C4F740 North (4 Byte): 544029184 / 0x206D3A00; 45,5999994277954° North (4 Byte): 624689152 / 0x253C0000; 52,36083984375° East (4 Byte): 150324224 / 0x8F5C400; 12,6000308990479° East (4 Byte): 129564672 / 0x7B90000; 10,8599853515625° South (4 Byte): 539256832 / 0x20246800; 45,1999855041504° South (4 Byte): 622657536 / 0x251D0000; 52,1905517578125° West (4 Byte): 145551360 / 0x8ACF000; 12,1999740600586° West (4 Byte): 127074304 / 0x7930000; 10,6512451171875° Description (8 Byte): 'Venezia' Description (26 Byte): 'OSM street map (63240001)' Unknown1 (2 Byte): 7 / 0x7 Unknown1 (2 Byte): 7 / 0x7 SubCount (2 Byte): 6 / 0x6 SubCount (2 Byte): 6 / 0x6 Size: Size: (4 Byte): 159678 / 0x26FBE (4 Byte): 4307 / 0x10D3 (4 Byte): 767091 / 0xBB473 (4 Byte): 374556 / 0x5B71C (4 Byte): 50029 / 0xC36D (4 Byte): 25407 / 0x633F (4 Byte): 256693 / 0x3EAB5 (4 Byte): 52340 / 0xCC74 (4 Byte): 487497 / 0x77049 (4 Byte): 140926 / 0x2267E (4 Byte): 601379 / 0x92D23 (4 Byte): 11916 / 0x2E8C HasCopyright (1 Byte): 1 / 0x1 HasCopyright (1 Byte): 1 / 0x1 Unknown2 (1 Byte): 1 / 0x1 Unknown2 (1 Byte): 195 / 0xC3 Unknown3 (1 Byte): 0 / 0x0 Unknown3 (1 Byte): 0 / 0x0 Unknown4 (1 Byte): 0 / 0x0 Unknown4 (1 Byte): 255 / 0xFF Unknown5 (1 Byte): 1 / 0x1 Unknown5 (1 Byte): 0 / 0x0 Unknown6 (1 Byte): 0 / 0x0 Unknown6 (1 Byte): 0 / 0x0 Unknown7 (1 Byte): 0 / 0x0 Unknown7 (1 Byte): 0 / 0x0 Name: Name: (13 Byte): 'I0FD3F12.LBL' (13 Byte): '63240001.TRE' (13 Byte): 'I0FD3F12.RGN' (13 Byte): '63240001.RGN' (13 Byte): 'I0FD3F12.TRE' (13 Byte): '63240001.LBL' (13 Byte): 'I0FD3F12.NET' (13 Byte): '63240001.NET' (13 Byte): 'I0FD3F12.NOD' (13 Byte): '63240001.NOD' (13 Byte): 'I0FD3F12.DEM' (13 Byte): '63240001.DEM' Unknown8 (8 Byte): 0 / 0x0 Unknown8 (8 Byte): 0 / 0x0 Unknown9 (9 Byte): 0 / 0x0 Unknown9 (9 Byte): 0 / 0x0 Die Punkte links-oben sind immer Vielfache des Punktabstandes. Aber Garmin nimmt es offensichtlich nicht so ganz ernst damit, wirklich den zur TRE-Position nächstliegenden Punkt zu nehmen. DEM: PointDistance 3312 / 0xCF0 13248 / 0x33C0 26512 / 0x6790 53024 / 0xCF20 Left 145549152 / 0x8ACE760 145542528 / 0x8ACCD80 145524368 / 0x8AC8690 145497856 / 0x8AC1F00 Top 544032432 / 0x206D46B0 544042368 / 0x206D6D80 544052752 / 0x206D9610 544079264 / 0x206DFDA0 TRE Diff. zu DEM West: 568560 / 0x8ACF0 -> 145551360 2208 8832 26992 (!) 53504 (!) North: 2125114 / 0x206D3A -> 544029184 -3248 -13184 -23568 -50080 Ich glaube, man sollte eher mit den "Unknown"-Bytes in der TDB experimentieren. Frank --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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-Weg... These maps work in BaseCamp, when placed on pendrive. -- Best regards, Andrzej
participants (5)
-
Andrzej Popowski -
Frank Stinner -
Gerd Petermann -
Gerd Petermann
-
lig fietser