Re: [mkgmap-dev] Please help
Hi Gerd The only thing I can add is that the large mdr file is part of the current Garmin NT file structure , ie Topo France V3 , which might explain the 2 additional bytes. Nick On 30/12/2021 07:19, Gerd Petermann wrote: Hi Nick and Ticker, there is another problem with the large mdr file. The POI section (MDR 11) seems to contain 2 unexpected additional bytes before(!) the known bytes for city and MDR15 offset. We should really try to find out the meaning of the magic number in MDR11 instead of looking at the recsize only. The current logic also fails with a gmapsupp index and tries to read MDR 15 offsets :( Maybe we can learn something for mkgmap there. I'm working on an implementation of Huffman encoding in mkgmap first... Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Mittwoch, 29. Dezember 2021 12:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Please help Hi all, thanks for all the input. It answered most of the open questions, display tool r577 should be able to analyse all the files. Binary is here: https://files.mkgmap.org.uk/detail/543 See also https://www.mkgmap.org.uk/websvn/listing.php?repname=display=576 and https://www.mkgmap.org.uk/websvn/listing.php?repname=display=577 @Nick: the larger MDR seems to cause trouble when section 1 is displayed. Will look into this later. r577 should work with option --print=!1 This option means that all but the 1st section should be printed, will cause huge output for that file, but string decoding seems to work well Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Mittwoch, 29. Dezember 2021 12:03 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Ticker / Gerd I've found another one which I think included mdr15 but second byte = 0x15 Also added a mdr.mdrfrom Topo France V3 which the display.jar couildn't parse but might be of interest Warning file sz is large https:\pinns.co.uk\2812\mdr2.zip HTH Nick On 29/12/2021 09:31, Ticker Berkin wrote: Hi Nick Thanks. Interesting, but not maybe not relevant to the Huffman stuff, in mdr16austria.txt the MDR headers go out of sync after MDR30 Ticker On Tue, 2021-12-28 at 18:28 +, nick wrote: Hi Gerd OK thanks will check that tomorrow. I think it's amazing how far both of you got. Nick On 28/12/2021 18:26, Gerd Petermann wrote: Hi Nick, yes, and esp. those MDR 16 which do not have a 0x15 at offset 2 like in this example: 03fa | 00 | aa 04 15 1b 15 08 cf 00 | record 0 (len: 300, 0x12c) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd Great but as you confusing, although typically Garmin ;) I noticed some are called map_mdr.img. I'll check some other pc s tomorrow; I suppose you are specifically looking for mdr16 Nick On 28/12/2021 18:17, Gerd Petermann wrote: Hi Nick, thanks, the mdr file looks like a very early version with a very different structure. Should help to understand the remaining bits :) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd I have done a few for you, including one which causes a java error so added the mdr https:\pinns.co.uk\2812\mdrmap.zip Wishing you and Ticker every success! Great Job ! r Nick On 28/12/2021 14:55, Gerd Petermann wrote: java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk ht
Re: [mkgmap-dev] Please help
Hi Nick and Ticker, there is another problem with the large mdr file. The POI section (MDR 11) seems to contain 2 unexpected additional bytes before(!) the known bytes for city and MDR15 offset. We should really try to find out the meaning of the magic number in MDR11 instead of looking at the recsize only. The current logic also fails with a gmapsupp index and tries to read MDR 15 offsets :( Maybe we can learn something for mkgmap there. I'm working on an implementation of Huffman encoding in mkgmap first... Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Mittwoch, 29. Dezember 2021 12:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Please help Hi all, thanks for all the input. It answered most of the open questions, display tool r577 should be able to analyse all the files. Binary is here: https://files.mkgmap.org.uk/detail/543 See also https://www.mkgmap.org.uk/websvn/listing.php?repname=display=576 and https://www.mkgmap.org.uk/websvn/listing.php?repname=display=577 @Nick: the larger MDR seems to cause trouble when section 1 is displayed. Will look into this later. r577 should work with option --print=!1 This option means that all but the 1st section should be printed, will cause huge output for that file, but string decoding seems to work well Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Mittwoch, 29. Dezember 2021 12:03 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Ticker / Gerd I've found another one which I think included mdr15 but second byte = 0x15 Also added a mdr.mdrfrom Topo France V3 which the display.jar couildn't parse but might be of interest Warning file sz is large https:\pinns.co.uk\2812\mdr2.zip HTH Nick On 29/12/2021 09:31, Ticker Berkin wrote: > Hi Nick > > Thanks. > > Interesting, but not maybe not relevant to the Huffman stuff, in > mdr16austria.txt the MDR headers go out of sync after MDR30 > > Ticker > > > On Tue, 2021-12-28 at 18:28 +, nick wrote: >> Hi Gerd >> >> OK thanks will check that tomorrow. >> >> I think it's amazing how far both of you got. >> >> Nick >> >> On 28/12/2021 18:26, Gerd Petermann wrote: >>> Hi Nick, >>> >>> yes, and esp. those MDR 16 which do not have a 0x15 at offset 2 >>> like in this example: >>> 03fa | 00 | aa 04 15 1b 15 08 cf 00 | record 0 (len: 300, >>> 0x12c) >>> >>> Gerd >>> >>> ____________________ >>> Von: mkgmap-dev im Auftrag >>> von nick >>> Gesendet: Dienstag, 28. Dezember 2021 19:21 >>> An: mkgmap-dev@lists.mkgmap.org.uk >>> Betreff: Re: [mkgmap-dev] Please help >>> >>> Hi Gerd >>> >>> Great but as you confusing, although typically Garmin ;) >>> >>> I noticed some are called map_mdr.img. >>> >>> I'll check some other pc s tomorrow; I suppose you are specifically >>> looking for mdr16 >>> >>> Nick >>> >>> >>> On 28/12/2021 18:17, Gerd Petermann wrote: >>>> Hi Nick, >>>> >>>> thanks, the mdr file looks like a very early version with a very >>>> different structure. Should help to understand the remaining bits >>>> :) >>>> >>>> Gerd >>>> >>>> >>>> Von: mkgmap-dev im >>>> Auftrag von nick >>>> Gesendet: Dienstag, 28. Dezember 2021 19:00 >>>> An: mkgmap-dev@lists.mkgmap.org.uk >>>> Betreff: Re: [mkgmap-dev] Please help >>>> >>>> Hi Gerd >>>> >>>> I have done a few for you, including one which causes a java >>>> error so >>>> added the mdr >>>> >>>> https:\pinns.co.uk\2812\mdrmap.zip >>>> >>>> Wishing you and Ticker every success! Great Job ! >>>> >>>> r >>>> >>>> Nick >>>> >>>> On 28/12/2021 14:55, Gerd Petermann wrote: >>>>> java -ea -Xmx6800m -cp >>>>> d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar >>>>> test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt >>>> ___ >>>> mkgmap-dev mailing list >>>> mkgmap-dev@lists.mkgmap.org.uk >>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>>> ___ >>>> mkgmap-dev mailing list >>>> mkgmap-dev@lists.mkgmap.org.uk >>&
Re: [mkgmap-dev] Please help
Hi all, thanks for all the input. It answered most of the open questions, display tool r577 should be able to analyse all the files. Binary is here: https://files.mkgmap.org.uk/detail/543 See also https://www.mkgmap.org.uk/websvn/listing.php?repname=display=576 and https://www.mkgmap.org.uk/websvn/listing.php?repname=display=577 @Nick: the larger MDR seems to cause trouble when section 1 is displayed. Will look into this later. r577 should work with option --print=!1 This option means that all but the 1st section should be printed, will cause huge output for that file, but string decoding seems to work well Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Mittwoch, 29. Dezember 2021 12:03 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Ticker / Gerd I've found another one which I think included mdr15 but second byte = 0x15 Also added a mdr.mdrfrom Topo France V3 which the display.jar couildn't parse but might be of interest Warning file sz is large https:\pinns.co.uk\2812\mdr2.zip HTH Nick On 29/12/2021 09:31, Ticker Berkin wrote: > Hi Nick > > Thanks. > > Interesting, but not maybe not relevant to the Huffman stuff, in > mdr16austria.txt the MDR headers go out of sync after MDR30 > > Ticker > > > On Tue, 2021-12-28 at 18:28 +, nick wrote: >> Hi Gerd >> >> OK thanks will check that tomorrow. >> >> I think it's amazing how far both of you got. >> >> Nick >> >> On 28/12/2021 18:26, Gerd Petermann wrote: >>> Hi Nick, >>> >>> yes, and esp. those MDR 16 which do not have a 0x15 at offset 2 >>> like in this example: >>> 03fa | 00 | aa 04 15 1b 15 08 cf 00 | record 0 (len: 300, >>> 0x12c) >>> >>> Gerd >>> >>> ____________________ >>> Von: mkgmap-dev im Auftrag >>> von nick >>> Gesendet: Dienstag, 28. Dezember 2021 19:21 >>> An: mkgmap-dev@lists.mkgmap.org.uk >>> Betreff: Re: [mkgmap-dev] Please help >>> >>> Hi Gerd >>> >>> Great but as you confusing, although typically Garmin ;) >>> >>> I noticed some are called map_mdr.img. >>> >>> I'll check some other pc s tomorrow; I suppose you are specifically >>> looking for mdr16 >>> >>> Nick >>> >>> >>> On 28/12/2021 18:17, Gerd Petermann wrote: >>>> Hi Nick, >>>> >>>> thanks, the mdr file looks like a very early version with a very >>>> different structure. Should help to understand the remaining bits >>>> :) >>>> >>>> Gerd >>>> >>>> >>>> Von: mkgmap-dev im >>>> Auftrag von nick >>>> Gesendet: Dienstag, 28. Dezember 2021 19:00 >>>> An: mkgmap-dev@lists.mkgmap.org.uk >>>> Betreff: Re: [mkgmap-dev] Please help >>>> >>>> Hi Gerd >>>> >>>> I have done a few for you, including one which causes a java >>>> error so >>>> added the mdr >>>> >>>> https:\pinns.co.uk\2812\mdrmap.zip >>>> >>>> Wishing you and Ticker every success! Great Job ! >>>> >>>> r >>>> >>>> Nick >>>> >>>> On 28/12/2021 14:55, Gerd Petermann wrote: >>>>> java -ea -Xmx6800m -cp >>>>> d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar >>>>> test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt >>>> ___ >>>> mkgmap-dev mailing list >>>> mkgmap-dev@lists.mkgmap.org.uk >>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>>> ___ >>>> mkgmap-dev mailing list >>>> mkgmap-dev@lists.mkgmap.org.uk >>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> ___ >>> mkgmap-dev mailing list >>> mkgmap-dev@lists.mkgmap.org.uk >>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> ___ >>> mkgmap-dev mailing list >>> mkgmap-dev@lists.mkgmap.org.uk >>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> ___ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Ticker / Gerd I've found another one which I think included mdr15 but second byte = 0x15 Also added a mdr.mdrfrom Topo France V3 which the display.jar couildn't parse but might be of interest Warning file sz is large https:\pinns.co.uk\2812\mdr2.zip HTH Nick On 29/12/2021 09:31, Ticker Berkin wrote: Hi Nick Thanks. Interesting, but not maybe not relevant to the Huffman stuff, in mdr16austria.txt the MDR headers go out of sync after MDR30 Ticker On Tue, 2021-12-28 at 18:28 +, nick wrote: Hi Gerd OK thanks will check that tomorrow. I think it's amazing how far both of you got. Nick On 28/12/2021 18:26, Gerd Petermann wrote: Hi Nick, yes, and esp. those MDR 16 which do not have a 0x15 at offset 2 like in this example: 03fa | 00 | aa 04 15 1b 15 08 cf 00 | record 0 (len: 300, 0x12c) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd Great but as you confusing, although typically Garmin ;) I noticed some are called map_mdr.img. I'll check some other pc s tomorrow; I suppose you are specifically looking for mdr16 Nick On 28/12/2021 18:17, Gerd Petermann wrote: Hi Nick, thanks, the mdr file looks like a very early version with a very different structure. Should help to understand the remaining bits :) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd I have done a few for you, including one which causes a java error so added the mdr https:\pinns.co.uk\2812\mdrmap.zip Wishing you and Ticker every success! Great Job ! r Nick On 28/12/2021 14:55, Gerd Petermann wrote: java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Nick Thanks. Interesting, but not maybe not relevant to the Huffman stuff, in mdr16austria.txt the MDR headers go out of sync after MDR30 Ticker On Tue, 2021-12-28 at 18:28 +, nick wrote: > Hi Gerd > > OK thanks will check that tomorrow. > > I think it's amazing how far both of you got. > > Nick > > On 28/12/2021 18:26, Gerd Petermann wrote: > > Hi Nick, > > > > yes, and esp. those MDR 16 which do not have a 0x15 at offset 2 > > like in this example: > > 03fa | 00 | aa 04 15 1b 15 08 cf 00 | record 0 (len: 300, > > 0x12c) > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von nick > > Gesendet: Dienstag, 28. Dezember 2021 19:21 > > An: mkgmap-dev@lists.mkgmap.org.uk > > Betreff: Re: [mkgmap-dev] Please help > > > > Hi Gerd > > > > Great but as you confusing, although typically Garmin ;) > > > > I noticed some are called map_mdr.img. > > > > I'll check some other pc s tomorrow; I suppose you are specifically > > looking for mdr16 > > > > Nick > > > > > > On 28/12/2021 18:17, Gerd Petermann wrote: > > > Hi Nick, > > > > > > thanks, the mdr file looks like a very early version with a very > > > different structure. Should help to understand the remaining bits > > > :) > > > > > > Gerd > > > > > > > > > Von: mkgmap-dev im > > > Auftrag von nick > > > Gesendet: Dienstag, 28. Dezember 2021 19:00 > > > An: mkgmap-dev@lists.mkgmap.org.uk > > > Betreff: Re: [mkgmap-dev] Please help > > > > > > Hi Gerd > > > > > > I have done a few for you, including one which causes a java > > > error so > > > added the mdr > > > > > > https:\pinns.co.uk\2812\mdrmap.zip > > > > > > Wishing you and Ticker every success! Great Job ! > > > > > > r > > > > > > Nick > > > > > > On 28/12/2021 14:55, Gerd Petermann wrote: > > > > java -ea -Xmx6800m -cp > > > > d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar > > > > test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt > > > ___ > > > mkgmap-dev mailing list > > > mkgmap-dev@lists.mkgmap.org.uk > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > ___ > > > mkgmap-dev mailing list > > > mkgmap-dev@lists.mkgmap.org.uk > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Gerd OK thanks will check that tomorrow. I think it's amazing how far both of you got. Nick On 28/12/2021 18:26, Gerd Petermann wrote: Hi Nick, yes, and esp. those MDR 16 which do not have a 0x15 at offset 2 like in this example: 03fa | 00 | aa 04 15 1b 15 08 cf 00 | record 0 (len: 300, 0x12c) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd Great but as you confusing, although typically Garmin ;) I noticed some are called map_mdr.img. I'll check some other pc s tomorrow; I suppose you are specifically looking for mdr16 Nick On 28/12/2021 18:17, Gerd Petermann wrote: Hi Nick, thanks, the mdr file looks like a very early version with a very different structure. Should help to understand the remaining bits :) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd I have done a few for you, including one which causes a java error so added the mdr https:\pinns.co.uk\2812\mdrmap.zip Wishing you and Ticker every success! Great Job ! r Nick On 28/12/2021 14:55, Gerd Petermann wrote: java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Nick, yes, and esp. those MDR 16 which do not have a 0x15 at offset 2 like in this example: 03fa | 00 | aa 04 15 1b 15 08 cf 00 | record 0 (len: 300, 0x12c) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd Great but as you confusing, although typically Garmin ;) I noticed some are called map_mdr.img. I'll check some other pc s tomorrow; I suppose you are specifically looking for mdr16 Nick On 28/12/2021 18:17, Gerd Petermann wrote: > Hi Nick, > > thanks, the mdr file looks like a very early version with a very different > structure. Should help to understand the remaining bits :) > > Gerd > > > Von: mkgmap-dev im Auftrag von nick > > Gesendet: Dienstag, 28. Dezember 2021 19:00 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Please help > > Hi Gerd > > I have done a few for you, including one which causes a java error so > added the mdr > > https:\pinns.co.uk\2812\mdrmap.zip > > Wishing you and Ticker every success! Great Job ! > > r > > Nick > > On 28/12/2021 14:55, Gerd Petermann wrote: >> java -ea -Xmx6800m -cp >> d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar >> test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Gerd Great but as you confusing, although typically Garmin ;) I noticed some are called map_mdr.img. I'll check some other pc s tomorrow; I suppose you are specifically looking for mdr16 Nick On 28/12/2021 18:17, Gerd Petermann wrote: Hi Nick, thanks, the mdr file looks like a very early version with a very different structure. Should help to understand the remaining bits :) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd I have done a few for you, including one which causes a java error so added the mdr https:\pinns.co.uk\2812\mdrmap.zip Wishing you and Ticker every success! Great Job ! r Nick On 28/12/2021 14:55, Gerd Petermann wrote: java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Nick, thanks, the mdr file looks like a very early version with a very different structure. Should help to understand the remaining bits :) Gerd Von: mkgmap-dev im Auftrag von nick Gesendet: Dienstag, 28. Dezember 2021 19:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Hi Gerd I have done a few for you, including one which causes a java error so added the mdr https:\pinns.co.uk\2812\mdrmap.zip Wishing you and Ticker every success! Great Job ! r Nick On 28/12/2021 14:55, Gerd Petermann wrote: > java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar > test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Gerd I have done a few for you, including one which causes a java error so added the mdr https:\pinns.co.uk\2812\mdrmap.zip Wishing you and Ticker every success! Great Job ! r Nick On 28/12/2021 14:55, Gerd Petermann wrote: java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Hi Carlos, see https://files.mkgmap.org.uk/detail/542 Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Dienstag, 28. Dezember 2021 16:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help Could you provide display.jar binary? I can't find it in the web, sorry. El 28/12/21 a las 15:55, Gerd Petermann escribió: > Hi all, > > those who have original garmin maps for the PC and know how to compile > display tool: > Update to r575 or higher. > Please execute the program MdrDisplay on the global index of the map (e.g > mdrmap.img) like this: > java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar > test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt > > (fix the paths to the two jar files, replace the ; by : on linux) > > The expected result is a rather small text file (~32k) or a crash. > Please reply with your results, possibly zipped. I am esp. interested in > crashes, but good data also might help to understand a few missing bits. > > This is about a compression algorithm that is used in some old Garmin maps > and I plan to implement that in mkgmap > to reduce file size of the global index file. > > I've attached a sample output for the Adria Topo 2.4 map. > > Gerd > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help
Could you provide display.jar binary? I can't find it in the web, sorry. El 28/12/21 a las 15:55, Gerd Petermann escribió: Hi all, those who have original garmin maps for the PC and know how to compile display tool: Update to r575 or higher. Please execute the program MdrDisplay on the global index of the map (e.g mdrmap.img) like this: java -ea -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar test.display.MdrDisplay MDRMAP.img --print=16 > mdr16.txt (fix the paths to the two jar files, replace the ; by : on linux) The expected result is a rather small text file (~32k) or a crash. Please reply with your results, possibly zipped. I am esp. interested in crashes, but good data also might help to understand a few missing bits. This is about a compression algorithm that is used in some old Garmin maps and I plan to implement that in mkgmap to reduce file size of the global index file. I've attached a sample output for the Adria Topo 2.4 map. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help with news about new DEM options
Hi Gerd, I think that it is better to get a rational set of option names than worry about causing confusion due to minor changes. I would think there are only a handful of people using the DEM options at the moment, and I don't believe anyone who is not on the development list will be using them yet. If there is anyone who has picked up the options and is not on the development list, they will get an error message saying they have an unrecognised option and will very quickly sort out what has changed. I think it needs to be explained that only one DEM overview is needed, despite the fact that there may be multiple overview levels. Arndt Röhrig suggested to me that the splitter output poly file be used when I asked for a DEM Noddy Guide - if it makes more sense to use the one provided as input to splitter then I suggest that be added to the documentation instead, and possibly suggesting that the areas.poly from splitter should not be used. I have been using areas.poly, but have not tried with no --dem-poly option, so don't know whether it makes any difference. Is this option intended to be used only when you want areas of the map to not have DEM data? If that is the case, then the documentation needs to say that in general this option need not be used (presumably using the one provided as input to splitter will also have no effect in that case). The wording of "If not given, the DEM data will cover the full tile area" is not sufficiently clear to me. Cheers, Mike Regards, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 03 February 2018 08:52 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Please help with news about new DEM options Hi Mike, - I also wondered if mkgmap should produce more DEM levels when --dem-dists is missing, the problem is that I was unsure about the values to use. - I like your suggested option names but I'd prefer not to change the options this late to avoid confusion. - There is only one overview-dem-dist because MapSource and Basecamp don't need more and the overview map is not used on the GPS. - Can you explain what effect you expect when you use --dem-poly with the areas.poly from splitter? My understanding is that this should not change the map, at least not visibly, as the areas.poly simply describes the outline of the rectangular tiles. On the other hand it makes sense to use the poly file that was used as input for splitter. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <m...@tvage.co.uk> Gesendet: Samstag, 3. Februar 2018 09:29 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options Having read the explanation of --dem-dists I think that the default for when the option is not provided needs to be changed. The explanation says "mkgmap tries to determine a reasonable value based on the resolution found in the *.hgt files", but it also says "for gps devices you need one for each resolution given with the --levels option". It seems to me the default behaviour should be to produce a map suitable for GPS devices, and hence it should determine a set of values. I suggest renaming this option --dem-distances as its meaning is clearer. Also I suggest capitalising GPS. I suggest renaming --overview-dem-dist to --dem-overview-distance so that all the DEM options begin with --dem. I also suggest moving the explanation to immediately after --dem-dists. As --overview-levels allows multiple values, does the DEM overview level also allow multiple levels (in which case the name needs to be --dem-overview-distances)? If not, we need a mention why only a single value is needed. For the --dem-poly option, I suggest adding a mention that the areas.poly file produced by splitter can be used. Hope this helps, Mike -Original Message- From: Carlos Dávila [mailto:cdavi...@orangecorreo.es] Sent: 02 February 2018 21:33 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Please help with news about new DEM options El 30/01/18 a las 09:41, Gerd Petermann escribió: > Hi all, > > with r4093 I've merged the dem-tdb branch into trunk. I think it would be good to mention this in the > "Latest news" on [1] , maybe with one or two screen shots, but I have no idea how to write this "from a users view". > Do we need a how-to that describes the sources for hgt files and maybe more about the new options? > It would be great if somebody could help with that. > > Gerd > > [1] http://www.mkgmap.org.uk/ > > > Attached patch is not exactly what you asked for, but I hope it adds some useful information about DEM. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailm
Re: [mkgmap-dev] Please help with news about new DEM options
Second version, adding your comments El 03/02/18 a las 07:33, Gerd Petermann escribió: Hi Carlos, thanks again. Seems I need new glasses when I look at all those typos :O I like the introducing chapter about DEM, but I don't fully agree reg. dem-dists: "Reasonable values for the highest resolution are somewhere between 1648 and 5520 for 1'' hgt input files (3312 is often used), and 9942 for 3'' hgt input files." Since 9942 is close to the resolution of the 3'' hgt I think 5520 is also suitable for a 3'' file. Maybe we should add that 1'' means ~ 3314 distance and 3'' means ~ 9942 and that the 1st dist value should not be much smaller than 50% of that distance? Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavi...@orangecorreo.es> Gesendet: Freitag, 2. Februar 2018 22:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options El 30/01/18 a las 09:41, Gerd Petermann escribió: Hi all, with r4093 I've merged the dem-tdb branch into trunk. I think it would be good to mention this in the "Latest news" on [1] , maybe with one or two screen shots, but I have no idea how to write this "from a users view". Do we need a how-to that describes the sources for hgt files and maybe more about the new options? It would be great if somebody could help with that. Gerd [1] http://www.mkgmap.org.uk/ Attached patch is not exactly what you asked for, but I hope it adds some useful information about DEM. Index: resources/help/en/options === --- resources/help/en/options (revisión: 4102) +++ resources/help/en/options (copia de trabajo) @@ -439,15 +439,22 @@ Note that in resolution 24 the filter is not used. Hill Shading (DEM) options: + Hill Shading is rendered by PC programs (MapSource or BaseCamp) or GPS devices +when the map includes a Digital Elevation Model (DEM). Use the following options +to add a DEM to the map and control its characteristics. DEM creation requires +files containing height information for the area covered by the map, the so +called hgt files, which typically cover 1 degree latitude * 1 degree longitude +and are named by the coordinates of their bottom left corner (eg. N53E009). They +contain height information in a grid of points. Typical hgt files contain either +1'' or 3'' data. 3'' files have 1201 * 1201 points, which gives +2 * 1201 * 1201 = 2.884.802 bytes. 1'' files have 3601 * 3601 points, which gives +2 * 3601 * 3601 = 25.934.402 bytes. Other files are supported as long as the +formular sqrt(size/2) gives an integer value. --dem=path[,path] The option expects a comma separated list of paths to directories or zip - files containing *.hgt files (SRTM). Directories are searched for *.hgt - files and also for *.hgt.zip and *.zip files where * means a name like - N53E009. Typical hgt files contain either 1'' or 3'' data. - 3'' files have 2 * 1201 * 1201 = 2.884.802 bytes, 1'' files have - 2 * 3601 * 3601 = 25.934.402 bytes. Other files are supported as long as the - formular sqrt(size/2) gives an integer value. + files containing *.hgt files. Directories are searched for *.hgt files and + also for *.hgt.zip and *.zip files. The list is searched in the given order, so if you want to use 1'' files make sure that they are found first. There are different sources for *.hgt files, some have so called voids which are areas without data. @@ -456,18 +463,21 @@ --dem-dists=number[,number] If given, the option specifies the resolution(s) or zoom level for the DEM data. If not given, mkgmap tries to determine a reasonable value based on - the resolution found in the *.hgt files. For PC programs like MapSource or - Basecamp you only need one zoom level, for gps devies you need one for each + the resolution found in the *.hgt files. For desktop programs like MapSource or + Basecamp you only need one zoom level, for GPS devices you need one for each resolution given with the --levels option. The actual values are given as - distance between two DEM points. Higher disances mean lower resolution and - thus fewer bytes in the map. Reasonable values for the highest resolution - are somewhere between 1648 and 5520, 3312 is often used. + distance between two DEM points and should be a multiple or submultiple of + the distance between two points in the hgt file, that is 3314 for 1'' and 9942 + for 3''. Higher distances mean lower resolution and thus fewer bytes in the + map. Reasonable values for the highest resolution should not be much smaller + than 50% hgt resolution, that is somewhere between 1648 and 5520 for 1'' hgt + input files (3312 is often used), and 5520 to 9942 for 3'' hgt input files. Example which should work with levels="0:24, 1:22, 2:20, 3:18": --dem-dists=3312,132
Re: [mkgmap-dev] Please help with news about new DEM options
Hi Mike, - I also wondered if mkgmap should produce more DEM levels when --dem-dists is missing, the problem is that I was unsure about the values to use. - I like your suggested option names but I'd prefer not to change the options this late to avoid confusion. - There is only one overview-dem-dist because MapSource and Basecamp don't need more and the overview map is not used on the GPS. - Can you explain what effect you expect when you use --dem-poly with the areas.poly from splitter? My understanding is that this should not change the map, at least not visibly, as the areas.poly simply describes the outline of the rectangular tiles. On the other hand it makes sense to use the poly file that was used as input for splitter. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <m...@tvage.co.uk> Gesendet: Samstag, 3. Februar 2018 09:29 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options Having read the explanation of --dem-dists I think that the default for when the option is not provided needs to be changed. The explanation says "mkgmap tries to determine a reasonable value based on the resolution found in the *.hgt files", but it also says "for gps devices you need one for each resolution given with the --levels option". It seems to me the default behaviour should be to produce a map suitable for GPS devices, and hence it should determine a set of values. I suggest renaming this option --dem-distances as its meaning is clearer. Also I suggest capitalising GPS. I suggest renaming --overview-dem-dist to --dem-overview-distance so that all the DEM options begin with --dem. I also suggest moving the explanation to immediately after --dem-dists. As --overview-levels allows multiple values, does the DEM overview level also allow multiple levels (in which case the name needs to be --dem-overview-distances)? If not, we need a mention why only a single value is needed. For the --dem-poly option, I suggest adding a mention that the areas.poly file produced by splitter can be used. Hope this helps, Mike -Original Message- From: Carlos Dávila [mailto:cdavi...@orangecorreo.es] Sent: 02 February 2018 21:33 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Please help with news about new DEM options El 30/01/18 a las 09:41, Gerd Petermann escribió: > Hi all, > > with r4093 I've merged the dem-tdb branch into trunk. I think it would be > good to mention this in the > "Latest news" on [1] , maybe with one or two screen shots, but I have no idea > how to write this "from a users view". > Do we need a how-to that describes the sources for hgt files and maybe more > about the new options? > It would be great if somebody could help with that. > > Gerd > > [1] http://www.mkgmap.org.uk/ > > > Attached patch is not exactly what you asked for, but I hope it adds some useful information about DEM. ___ 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] Please help with news about new DEM options
Having read the explanation of --dem-dists I think that the default for when the option is not provided needs to be changed. The explanation says "mkgmap tries to determine a reasonable value based on the resolution found in the *.hgt files", but it also says "for gps devices you need one for each resolution given with the --levels option". It seems to me the default behaviour should be to produce a map suitable for GPS devices, and hence it should determine a set of values. I suggest renaming this option --dem-distances as its meaning is clearer. Also I suggest capitalising GPS. I suggest renaming --overview-dem-dist to --dem-overview-distance so that all the DEM options begin with --dem. I also suggest moving the explanation to immediately after --dem-dists. As --overview-levels allows multiple values, does the DEM overview level also allow multiple levels (in which case the name needs to be --dem-overview-distances)? If not, we need a mention why only a single value is needed. For the --dem-poly option, I suggest adding a mention that the areas.poly file produced by splitter can be used. Hope this helps, Mike -Original Message- From: Carlos Dávila [mailto:cdavi...@orangecorreo.es] Sent: 02 February 2018 21:33 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Please help with news about new DEM options El 30/01/18 a las 09:41, Gerd Petermann escribió: > Hi all, > > with r4093 I've merged the dem-tdb branch into trunk. I think it would be > good to mention this in the > "Latest news" on [1] , maybe with one or two screen shots, but I have no idea > how to write this "from a users view". > Do we need a how-to that describes the sources for hgt files and maybe more > about the new options? > It would be great if somebody could help with that. > > Gerd > > [1] http://www.mkgmap.org.uk/ > > > Attached patch is not exactly what you asked for, but I hope it adds some useful information about DEM. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help with news about new DEM options
Hi Carlos, thanks again. Seems I need new glasses when I look at all those typos :O I like the introducing chapter about DEM, but I don't fully agree reg. dem-dists: "Reasonable values for the highest resolution are somewhere between 1648 and 5520 for 1'' hgt input files (3312 is often used), and 9942 for 3'' hgt input files." Since 9942 is close to the resolution of the 3'' hgt I think 5520 is also suitable for a 3'' file. Maybe we should add that 1'' means ~ 3314 distance and 3'' means ~ 9942 and that the 1st dist value should not be much smaller than 50% of that distance? Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavi...@orangecorreo.es> Gesendet: Freitag, 2. Februar 2018 22:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options El 30/01/18 a las 09:41, Gerd Petermann escribió: > Hi all, > > with r4093 I've merged the dem-tdb branch into trunk. I think it would be > good to mention this in the > "Latest news" on [1] , maybe with one or two screen shots, but I have no idea > how to write this "from a users view". > Do we need a how-to that describes the sources for hgt files and maybe more > about the new options? > It would be great if somebody could help with that. > > Gerd > > [1] http://www.mkgmap.org.uk/ > > > Attached patch is not exactly what you asked for, but I hope it adds some useful information about DEM. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help with news about new DEM options
El 30/01/18 a las 09:41, Gerd Petermann escribió: Hi all, with r4093 I've merged the dem-tdb branch into trunk. I think it would be good to mention this in the "Latest news" on [1] , maybe with one or two screen shots, but I have no idea how to write this "from a users view". Do we need a how-to that describes the sources for hgt files and maybe more about the new options? It would be great if somebody could help with that. Gerd [1] http://www.mkgmap.org.uk/ Attached patch is not exactly what you asked for, but I hope it adds some useful information about DEM. Index: resources/help/en/options === --- resources/help/en/options (revisión: 4097) +++ resources/help/en/options (copia de trabajo) @@ -439,15 +439,22 @@ Note that in resolution 24 the filter is not used. Hill Shading (DEM) options: + Hill Shading is rendered by PC programs (MapSource or BaseCamp) or GPS devices +when the map includes a Digital Elevation Model (DEM). Use the following options +to add a DEM to the map and control its characteristics. DEM creation requires +files containing height information for the area covered by the map, the so +called hgt files, which typically cover 1 degree latitude * 1 degree longitude +and are named by the coordinates of their bottom left corner (eg. N53E009). They +contain height information in a grid of points. Typical hgt files contain either +1'' or 3'' data. 3'' files have 1201 * 1201 points, which gives +2 * 1201 * 1201 = 2.884.802 bytes. 1'' files have 3601 * 3601 points, which gives +2 * 3601 * 3601 = 25.934.402 bytes. Other files are supported as long as the +formular sqrt(size/2) gives an integer value. --dem=path[,path] The option expects a comma separated list of paths to directories or zip - files containing *.hgt files (SRTM). Directories are searched for *.hgt - files and also for *.hgt.zip and *.zip files where * means a name like - N53E009. Typical hgt files contain either 1'' or 3'' data. - 3'' files have 2 * 1201 * 1201 = 2.884.802 bytes, 1'' files have - 2 * 3601 * 3601 = 25.934.402 bytes. Other files are supported as long as the - formular sqrt(size/2) gives an integer value. + files containing *.hgt files. Directories are searched for *.hgt files and + also for *.hgt.zip and *.zip files. The list is searched in the given order, so if you want to use 1'' files make sure that they are found first. There are different sources for *.hgt files, some have so called voids which are areas without data. @@ -457,17 +464,18 @@ If given, the option specifies the resolution(s) or zoom level for the DEM data. If not given, mkgmap tries to determine a reasonable value based on the resolution found in the *.hgt files. For PC programs like MapSource or - Basecamp you only need one zoom level, for gps devies you need one for each + Basecamp you only need one zoom level, for gps devices you need one for each resolution given with the --levels option. The actual values are given as - distance between two DEM points. Higher disances mean lower resolution and + distance between two DEM points. Higher distances mean lower resolution and thus fewer bytes in the map. Reasonable values for the highest resolution - are somewhere between 1648 and 5520, 3312 is often used. + are somewhere between 1648 and 5520 for 1'' hgt input files (3312 is often + used), and 9942 for 3'' hgt input files. Example which should work with levels="0:24, 1:22, 2:20, 3:18": --dem-dists=3312,13248,26512,53024 This was found in a Garmin Demo map for transalpin data created 2009. --dem-interpolation=auto|bicubic|bilinear - Use this option to speciy the method that is used to interpolate + Use this option to specify the method that is used to interpolate data from hgt raster to the DEM raster. The value bicubic gives the highest precision but is slower, bilinear is faster but less precise, it tends to smooth the profile and thus also reduces DEM size compared to ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help with news about new DEM options
Thanks Gerd One certainly gets more of the lumps and bumps with a distance of 1664 Nick On 31/01/2018 13:20, Gerd Petermann wrote: Hi Nick, well, Andrzej reported that this oversampling might improve precision. My understanding is that it reduces the error that is added by interpolation. For sure it adds a lot of bytes to the img file, so one has to find out what is more imprtant. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von osm@pinns <o...@pinns.co.uk> Gesendet: Mittwoch, 31. Januar 2018 13:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options Hi Gerd Thanks for the detailed explanations. ' if you want more precision and map size doesn't matter half of it' I'm not quite sure how halving these values produce greater precision for resolution 24. Interestingly , you mention 1664 . One of my topos has 1648 as in 1648,3312,13248,53024 Nick On 31/01/2018 11:03, Gerd Petermann wrote: Hi Minko, I'd also like to know a good rule how to calculate the dem-dists values. Again the basic formulars: Typical hgt formats use a raster with either 1200 (3'') or 3600 (1'') points/degree as resolution. The corresponding resolutions for DEM are 2^32/(1200*360) ~ 9942 or 2^32(3600 * 360) ~ 3314 It is quite obvious that the first value in dem-dists depends on the resolution of the input hgt file(s). My understanding is that you might use a value near the hgt resolution or maybe - if you want more precision and map size doesn't matter - half of it, so 3'' hgt means dem-dist ~ 9942 (or 9942/2 = 4971) 1'' hgt means dem-dist ~ 3314 (or 3314/2 = 1657) Since mkgmap now rounds these values to multiples of 16 you get 2^32/(1200*360) ~ 9942 -> 9936 rounded 2^32/(1200*360) / 2 ~ 4971 -> 4976 rounded 2^32/(3600*360) ~ 3314 -> 3312 rounded 2^32/(3600*360) / 2 ~ 1657 -> 1664 rounded These are the values for resolution 24. What still seems unclear is how you calculate the values for lower resolutions. Up to now I see no reason to duplicate data with e.g. dem-dists=3312,3312,... but I see this in Arndts "Speichenkarte" which uses resolution 23 for level 1. I tried some different values on my Oregon 600 and I think the hill shading is not very useful on the device. Maybe that's the reason why the setting Map->Advanced Setup->Shaded relief->Auto means that hill shading is not used unless you zoom out to 5km? I also tried with only one or two DEM levels, e.g. --dem-dists=1664,3312 or just --dem-dists=3312 It works, the device just uses the DEM from the basemap when you zoom out to e.g. 500 m. The problem: The basemap has a very poor DEM resolution, so it looks wrong when hills suddenly disappear while zooming out. My current compromise for high precision with 1'' hgt input and default style: 1664,9936,26512,53024 Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von lig fietser <ligfiet...@hotmail.com> Gesendet: Mittwoch, 31. Januar 2018 09:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options Yes, it would be helpful if we mention where we can get the hgt files, a few examples of the dem-dist values and an explanation how to calculate it. This information is already there but mentioned in the many updates of the branch versions. I use http://www.javawa.nl/srtm/index.php?lang=nl because it has a good overview map, the disadvantage is that you need to download every single tile manually and not in one big download. Maybe there are better alternatives? - Gerd wrote: Hi all, with r4093 I've merged the dem-tdb branch into trunk. I think it would be good to mention this in the "Latest news" on [1] , maybe with one or two screen shots, but I have no idea how to write this "from a users view". Do we need a how-to that describes the sources for hgt files and maybe more about the new options? It would be great if somebody could help with that. Gerd [1] http://www.mkgmap.org.uk/ ___ 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 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help with news about new DEM options
Hi Nick, well, Andrzej reported that this oversampling might improve precision. My understanding is that it reduces the error that is added by interpolation. For sure it adds a lot of bytes to the img file, so one has to find out what is more imprtant. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von osm@pinns <o...@pinns.co.uk> Gesendet: Mittwoch, 31. Januar 2018 13:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options Hi Gerd Thanks for the detailed explanations. ' if you want more precision and map size doesn't matter half of it ' I'm not quite sure how halving these values produce greater precision for resolution 24. Interestingly , you mention 1664 . One of my topos has 1648 as in 1648,3312,13248,53024 Nick On 31/01/2018 11:03, Gerd Petermann wrote: > Hi Minko, > > I'd also like to know a good rule how to calculate the dem-dists values. > > Again the basic formulars: > Typical hgt formats use a raster with either 1200 (3'') or 3600 (1'') > points/degree as resolution. > The corresponding resolutions for DEM are 2^32/(1200*360) ~ 9942 or 2^32(3600 > * 360) ~ 3314 > > It is quite obvious that the first value in dem-dists depends on the > resolution of the input hgt file(s). > My understanding is that you might use a value near the hgt resolution or > maybe > - if you want more precision and map size doesn't matter - > half of it, so > 3'' hgt means dem-dist ~ 9942 (or 9942/2 = 4971) > 1'' hgt means dem-dist ~ 3314 (or 3314/2 = 1657) > Since mkgmap now rounds these values to multiples of 16 you get > 2^32/(1200*360) ~ 9942 -> 9936 rounded > 2^32/(1200*360) / 2 ~ 4971 -> 4976 rounded > 2^32/(3600*360) ~ 3314 -> 3312 rounded > 2^32/(3600*360) / 2 ~ 1657 -> 1664 rounded > > These are the values for resolution 24. > What still seems unclear is how you calculate the values for lower > resolutions. > Up to now I see no reason to duplicate data with e.g. dem-dists=3312,3312,... > but I see this in Arndts "Speichenkarte" which uses resolution 23 for level 1. > > I tried some different values on my Oregon 600 and I think the hill shading is > not very useful on the device. Maybe that's the reason why the setting > Map->Advanced Setup->Shaded relief->Auto > means that hill shading is not used unless you zoom out to 5km? > > I also tried with only one or two DEM levels, > e.g. --dem-dists=1664,3312 or just --dem-dists=3312 > It works, the device just uses the DEM from the basemap when you zoom out to > e.g. 500 m. > The problem: The basemap has a very poor DEM resolution, so it looks wrong > when hills > suddenly disappear while zooming out. > > My current compromise for high precision with 1'' hgt input and default style: > 1664,9936,26512,53024 > > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von lig > fietser <ligfiet...@hotmail.com> > Gesendet: Mittwoch, 31. Januar 2018 09:48 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Please help with news about new DEM options > > Yes, it would be helpful if we mention where we can get the hgt files, a few > examples of the dem-dist values and an explanation how to calculate it. This > information is already there but mentioned in the many updates of the branch > versions. > > I use http://www.javawa.nl/srtm/index.php?lang=nl because it has a good > overview map, the disadvantage is that you need to download every single tile > manually and not in one big download. Maybe there are better alternatives? > > - > > Gerd wrote: > > Hi all, > > with r4093 I've merged the dem-tdb branch into trunk. I think it would be > good to mention this in the > "Latest news" on [1] , maybe with one or two screen shots, but I have no idea > how to write this "from a users view". > Do we need a how-to that describes the sources for hgt files and maybe more > about the new options? > It would be great if somebody could help with that. > > Gerd > > [1] http://www.mkgmap.org.uk/ > ___ > 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 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] Please help with news about new DEM options
Hi Gerd Thanks for the detailed explanations. ' if you want more precision and map size doesn't matter half of it ' I'm not quite sure how halving these values produce greater precision for resolution 24. Interestingly , you mention 1664 . One of my topos has 1648 as in 1648,3312,13248,53024 Nick On 31/01/2018 11:03, Gerd Petermann wrote: Hi Minko, I'd also like to know a good rule how to calculate the dem-dists values. Again the basic formulars: Typical hgt formats use a raster with either 1200 (3'') or 3600 (1'') points/degree as resolution. The corresponding resolutions for DEM are 2^32/(1200*360) ~ 9942 or 2^32(3600 * 360) ~ 3314 It is quite obvious that the first value in dem-dists depends on the resolution of the input hgt file(s). My understanding is that you might use a value near the hgt resolution or maybe - if you want more precision and map size doesn't matter - half of it, so 3'' hgt means dem-dist ~ 9942 (or 9942/2 = 4971) 1'' hgt means dem-dist ~ 3314 (or 3314/2 = 1657) Since mkgmap now rounds these values to multiples of 16 you get 2^32/(1200*360) ~ 9942 -> 9936 rounded 2^32/(1200*360) / 2 ~ 4971 -> 4976 rounded 2^32/(3600*360) ~ 3314 -> 3312 rounded 2^32/(3600*360) / 2 ~ 1657 -> 1664 rounded These are the values for resolution 24. What still seems unclear is how you calculate the values for lower resolutions. Up to now I see no reason to duplicate data with e.g. dem-dists=3312,3312,... but I see this in Arndts "Speichenkarte" which uses resolution 23 for level 1. I tried some different values on my Oregon 600 and I think the hill shading is not very useful on the device. Maybe that's the reason why the setting Map->Advanced Setup->Shaded relief->Auto means that hill shading is not used unless you zoom out to 5km? I also tried with only one or two DEM levels, e.g. --dem-dists=1664,3312 or just --dem-dists=3312 It works, the device just uses the DEM from the basemap when you zoom out to e.g. 500 m. The problem: The basemap has a very poor DEM resolution, so it looks wrong when hills suddenly disappear while zooming out. My current compromise for high precision with 1'' hgt input and default style: 1664,9936,26512,53024 Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von lig fietser <ligfiet...@hotmail.com> Gesendet: Mittwoch, 31. Januar 2018 09:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options Yes, it would be helpful if we mention where we can get the hgt files, a few examples of the dem-dist values and an explanation how to calculate it. This information is already there but mentioned in the many updates of the branch versions. I use http://www.javawa.nl/srtm/index.php?lang=nl because it has a good overview map, the disadvantage is that you need to download every single tile manually and not in one big download. Maybe there are better alternatives? - Gerd wrote: Hi all, with r4093 I've merged the dem-tdb branch into trunk. I think it would be good to mention this in the "Latest news" on [1] , maybe with one or two screen shots, but I have no idea how to write this "from a users view". Do we need a how-to that describes the sources for hgt files and maybe more about the new options? It would be great if somebody could help with that. Gerd [1] http://www.mkgmap.org.uk/ ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help with news about new DEM options
Hi Minko, I'd also like to know a good rule how to calculate the dem-dists values. Again the basic formulars: Typical hgt formats use a raster with either 1200 (3'') or 3600 (1'') points/degree as resolution. The corresponding resolutions for DEM are 2^32/(1200*360) ~ 9942 or 2^32(3600 * 360) ~ 3314 It is quite obvious that the first value in dem-dists depends on the resolution of the input hgt file(s). My understanding is that you might use a value near the hgt resolution or maybe - if you want more precision and map size doesn't matter - half of it, so 3'' hgt means dem-dist ~ 9942 (or 9942/2 = 4971) 1'' hgt means dem-dist ~ 3314 (or 3314/2 = 1657) Since mkgmap now rounds these values to multiples of 16 you get 2^32/(1200*360) ~ 9942 -> 9936 rounded 2^32/(1200*360) / 2 ~ 4971 -> 4976 rounded 2^32/(3600*360) ~ 3314 -> 3312 rounded 2^32/(3600*360) / 2 ~ 1657 -> 1664 rounded These are the values for resolution 24. What still seems unclear is how you calculate the values for lower resolutions. Up to now I see no reason to duplicate data with e.g. dem-dists=3312,3312,... but I see this in Arndts "Speichenkarte" which uses resolution 23 for level 1. I tried some different values on my Oregon 600 and I think the hill shading is not very useful on the device. Maybe that's the reason why the setting Map->Advanced Setup->Shaded relief->Auto means that hill shading is not used unless you zoom out to 5km? I also tried with only one or two DEM levels, e.g. --dem-dists=1664,3312 or just --dem-dists=3312 It works, the device just uses the DEM from the basemap when you zoom out to e.g. 500 m. The problem: The basemap has a very poor DEM resolution, so it looks wrong when hills suddenly disappear while zooming out. My current compromise for high precision with 1'' hgt input and default style: 1664,9936,26512,53024 Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von lig fietser <ligfiet...@hotmail.com> Gesendet: Mittwoch, 31. Januar 2018 09:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Please help with news about new DEM options Yes, it would be helpful if we mention where we can get the hgt files, a few examples of the dem-dist values and an explanation how to calculate it. This information is already there but mentioned in the many updates of the branch versions. I use http://www.javawa.nl/srtm/index.php?lang=nl because it has a good overview map, the disadvantage is that you need to download every single tile manually and not in one big download. Maybe there are better alternatives? - Gerd wrote: Hi all, with r4093 I've merged the dem-tdb branch into trunk. I think it would be good to mention this in the "Latest news" on [1] , maybe with one or two screen shots, but I have no idea how to write this "from a users view". Do we need a how-to that describes the sources for hgt files and maybe more about the new options? It would be great if somebody could help with that. Gerd [1] http://www.mkgmap.org.uk/ ___ 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] Please help with news about new DEM options
Yes, it would be helpful if we mention where we can get the hgt files, a few examples of the dem-dist values and an explanation how to calculate it. This information is already there but mentioned in the many updates of the branch versions. I use http://www.javawa.nl/srtm/index.php?lang=nl because it has a good overview map, the disadvantage is that you need to download every single tile manually and not in one big download. Maybe there are better alternatives? - Gerd wrote: Hi all, with r4093 I've merged the dem-tdb branch into trunk. I think it would be good to mention this in the "Latest news" on [1] , maybe with one or two screen shots, but I have no idea how to write this "from a users view". Do we need a how-to that describes the sources for hgt files and maybe more about the new options? It would be great if somebody could help with that. Gerd [1] http://www.mkgmap.org.uk/ ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help: --generate-sea: No coastline
Daniela Duerbeck escribió: Hi! I am relatively new to mkgmap but I searched the archive and found no answers. So I try to find help in this mailing list. I know that generate-sea is still buggy but I cannot achieve any blue sea. I try to generate a routable map of the Canary Islands. With the mkgmap version 1580 I do not even get the coast lines. With 1484 I got blue islands on yellow sea. Can there be any interaction between style-files and the generate-sea option? I used these style files: http://dev.openstreetmap.de/aio/styles/styles.tar.bz2 The latest splitter.jar. and the needed files from this tarball I copied into the directory, where I then ran this script: -- wget http://www.informationfreeway.org/api/0.6/map?bbox=-18.55,27.29,-12.82,29.89 -O canarias.osm mkdir tiles cp splitter.jar tiles cd tiles $JAVA_BINDIR/java -Xmx2000M -jar splitter.jar --mapid=63240347 --max-nodes=100 ../canarias.osm cd .. mkdir gbasemap; mkdir gaddr; mkdir gboundary cp mkgmap.jar gbasemap; cp mkgmap.jar gaddr; cp mkgmap.jar gboundary; cp -r addresslayer_style gaddr cp -r boundary_style gboundary cp -r masterstyle gbasemap cp -r addr.TYP gaddr cp -r boundary.TYP gboundary cp -r master.TYP gbasemap cd gbasemap $JAVA_BINDIR/java -Xmx2000M -jar mkgmap.jar --max-jobs --style-file=masterstyle --description='Openstreetmap' --country-name=spain --country-abbr=ES --family-id=4 --product-id=45 --series-name='OSM-AllInOne-ES-bmap' --family-name=OSM --area-name=EU --latin1 --mapname=63240345 --draw-priority=10 --add-pois-to-areas --make-all-cycleways --link-pois-to-ways --remove-short-arcs --net --route --ignore-osm-bounds --generate-sea='polygons' --gmapsupp ../tiles/*.osm.gz master.TYP cd .. cd gaddr $JAVA_BINDIR/java -Xmx2000M -jar mkgmap.jar --max-jobs --style-file=addresslayer_style --description='Adressen' --country-name=spain --country-abbr=ES --family-id=5 --product-id=40 --series-name='OSM-AllInOne-ES-Addr' --family-name=ADRESSEN --area-name=EU --latin1 --mapname=63241345 --draw-priority=20 --no-poi-address --no-sorted-roads --add-pois-to-areas --transparent --gmapsupp ../tiles/*.osm.gz addr.TYP cd .. cd gboundary $JAVA_BINDIR/java -Xmx2000M -jar mkgmap.jar --max-jobs --style-file=boundary_style --description='Boundary_Layer' --country-name=spain --country-abbr=ES --family-id=6 --product-id=30 --series-name='OSM-AllInOne-ES-boundary' --family-name=boundary --area-name=EU --latin1 --mapname=63240625 --draw-priority=21 --no-poi-address --no-sorted-roads --transparent --gmapsupp ../tiles/*.osm.gz boundary.TYP cd .. ./gmt -jo gmapsupp.img gbasemap/gmapsupp.img gaddr/gmapsupp.img gboundary/gmapsupp.img - Are there any additional options I should try to get at least a buggy sea? Thanks a lot in advance, Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev I build routable maps of Canary Islands with sea with no problem. You can see them at [1]. They are built with the following commands: wget http://download.geofabrik.de/osm/africa/canary_islands.osm.bz2 bunzip2 -f canary_islands.osm.bz2 java -Xmx400m -enableassertions -jar mkgmap.jar --generate-sea=polygons --route --tdbfile --latin1 --code-page=1252 --description=OpenStreetMap-Canarias --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --family-name=Open Street Map --family-id=16 --product-id=1 --series-name=OSM-Canarias --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=1 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mine canary_islands.osm typ/SPAIN-16.TYP As you can see I use a custom style, but it should work with default as well. You need to have natural=sea [0x32 resolution 10] or similar in your polygons style file. [1] http://mapas.alternativaslibres.es -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please help: --generate-sea: No coastline
On Feb 21, 2010, at 1:38, Daniela Duerbeck wrote: I know that generate-sea is still buggy but I cannot achieve any blue sea. I try to generate a routable map of the Canary Islands. With the mkgmap version 1580 I do not even get the coast lines. With 1484 I got blue islands on yellow sea. Can there be any interaction between style-files and the generate-sea option? I used these style files: http://dev.openstreetmap.de/aio/styles/styles.tar.bz2 The last time I looked at the all-in-one (aio) styles, there was no land polygon defined in the polygons style (and I presume in the TYP file). You need this for --generate-sea=polygons to work correctly. See the documentation in the options file for more details. You may wish to try --generate-sea without the polygon option (using the multipolygon option by default). The following works quite well for me: --generate-sea=extend-sea-sectors (And by the way, are you sure you need to run splitter on the Canary Islands? I would imagine that the data is small enough not to warrant splitting.) Cheers ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
