Re: [mkgmap-dev] DEM File Format and mkgmap
Hi Andreas I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes. I think you are right ; there is an issue. On 15/12/2017 19:30, Andreas Schmidt wrote:
Hi Frank,
with ypur great tool I am able to
- have3d - View in basecamp - hillshading on Oregon600
Thats really amazing !
In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information.
Could you make it work on your device?
Andreas
Gesendet mit der Telekom Mail App <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>
-----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk Hi,
i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases.
My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values".
For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue.
Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.
Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?
Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's?
In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps?
I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0
By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense.
Frank
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, FYI: I have started to add code in the dem-tdb branch which was created by Steve. Up to now the code in the branch is completely experimental and it doesn't write anything to the img files. At the moment I am looking at Franks code to understand how to fill the DEM header structures based on the (knwon) information in TRE, next I have to write the code to read and transform the hgt files, this looks rather simple compaired to the DEM structures. One open question is if splitter has to be changed so that it doesn't calculate tiles which are too large for DEM. Maybe we have something useful in mkgmap till the end of the year... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von osm@pinns <osm@pinns.co.uk> Gesendet: Freitag, 15. Dezember 2017 20:34:39 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Hi Andreas I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes. I think you are right ; there is an issue. On 15/12/2017 19:30, Andreas Schmidt wrote: Hi Frank, with ypur great tool I am able to - have3d - View in basecamp - hillshading on Oregon600 Thats really amazing ! In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information. Could you make it work on your device? Andreas Gesendet mit der Telekom Mail App<http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm> -----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de><mailto:frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> Hi, i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases. My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values". For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue. Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0. Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights? Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's? In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps? I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0 By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense. Frank _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
That would be brilliant, Gerd. Frank's dems seem to work well enough to ignore, for the time being, cases which are as yet unclear and go beyond his algos. Even with the dems that work I'm sure there is still a certain amount of tweaking necessary: On my GPS ,( not in basecamp) I get a certain amount of 'streaking' on hills, ie stripes; this might have something to do with the pixel size. r Nick On 16/12/2017 09:57, Gerd Petermann wrote:
Hi all,
FYI: I have started to add code in the dem-tdb branch which was created by Steve. Up to now the code in the branch is completely experimental and it doesn't write anything to the img files.
At the moment I am looking at Franks code to understand how to fill the DEM header structures based on the (knwon) information in TRE, next I have to write the code to read and transform the hgt files, this looks rather simple compaired to the DEM structures. One open question is if splitter has to be changed so that it doesn't calculate tiles which are too large for DEM.
Maybe we have something useful in mkgmap till the end of the year...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von osm@pinns <osm@pinns.co.uk> Gesendet: Freitag, 15. Dezember 2017 20:34:39 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap
Hi Andreas
I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes.
I think you are right ; there is an issue.
On 15/12/2017 19:30, Andreas Schmidt wrote: Hi Frank,
with ypur great tool I am able to
- have3d - View in basecamp - hillshading on Oregon600
Thats really amazing !
In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information.
Could you make it work on your device?
Andreas
Gesendet mit der Telekom Mail App<http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>
-----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de><mailto:frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> Hi,
i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases.
My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values".
For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue.
Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.
Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?
Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's?
In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps?
I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0
By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense.
Frank
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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
Interestingly I don't get the error message. I click on 3d View (available on oregons but not GPS64) then get this http://files.mkgmap.org.uk/download/373/oregon6003dview.jpg On 16/12/2017 10:12, andreas.schmidt.hetschbach@t-online.de wrote:
HI,
not sure if we meant the same thing:
Map displayed with hillshading (Looks ok):
* http://files.mkgmap.org.uk/download/370/2017-12-16_10-57-56_194.jpeg
Menu item 3d-view
* http://files.mkgmap.org.uk/download/371/2017-12-16_10-58-44_277.jpeg
Error
* http://files.mkgmap.org.uk/download/372/2017-12-16_10-58-56_743.jpeg
Regards
Andreas
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Freitag, 15. Dezember 2017 20:34 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Hi Andreas
I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes.
I think you are right ; there is an issue.
On 15/12/2017 19:30, Andreas Schmidt wrote:
Hi Frank,
with ypur great tool I am able to
- have3d - View in basecamp - hillshading on Oregon600
Thats really amazing !
In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information.
Could you make it work on your device?
Andreas
Gesendet mit der Telekom Mail App <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>
-----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk Hi,
i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases.
My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values".
For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue.
Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.
Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?
Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's?
In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps?
I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0
By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense.
Frank
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@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
If you are having problems with dem not showing for 1 level then it may be due to you not using --usedummydata=true I find this is essential else indeed it produces dem files which have no effect at all ! I also have --lastcolstd --overwrite=true On 16/12/2017 12:04, andreas.schmidt.hetschbach@t-online.de wrote:
…I´m not too sure how this works at all 😊.
But what is (if there is one at all) the relation of the number of dlon-parameters and the so called Levels? I´ve found out that with only one dlon-parameter even the hiillshadung doens´t work. So I choosed the same numbers of Parameters as there are Levels in Options-file
Options-file:
levels = 0:24, 1:23, 2:22, 3:21, 4:20, 5:19
overview-levels = 6:17,7:14
BuildDEMFile.exe:
C:\Garmin\bin\BuildDEMFile.exe -O -d %%i\%%i.DEM --hgtpath=%hgtpath% --tre=%%i\%%i.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017 --dlon=0.0025
Is this correct?
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Samstag, 16. Dezember 2017 12:35 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Interestingly I don't get the error message.
I click on 3d View (available on oregons but not GPS64)
then get this
http://files.mkgmap.org.uk/download/373/oregon6003dview.jpg
On 16/12/2017 10:12, andreas.schmidt.hetschbach@t-online.de wrote:
HI,
not sure if we meant the same thing:
Map displayed with hillshading (Looks ok):
* http://files.mkgmap.org.uk/download/370/2017-12-16_10-57-56_194.jpeg
Menu item 3d-view
* http://files.mkgmap.org.uk/download/371/2017-12-16_10-58-44_277.jpeg
Error
* http://files.mkgmap.org.uk/download/372/2017-12-16_10-58-56_743.jpeg
Regards
Andreas
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Freitag, 15. Dezember 2017 20:34 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Hi Andreas
I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes.
I think you are right ; there is an issue.
On 15/12/2017 19:30, Andreas Schmidt wrote:
Hi Frank,
with ypur great tool I am able to
- have3d - View in basecamp - hillshading on Oregon600
Thats really amazing !
In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information.
Could you make it work on your device?
Andreas
Gesendet mit der Telekom Mail App <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>
-----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk Hi,
i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases.
My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values".
For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue.
Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.
Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?
Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's?
In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps?
I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0
By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense.
Frank
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@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
I have generated Italy map with DEM. Hillshading is correctly displayed, but 3D option is disabled in BaseCamp. BuildDEMFile command for map tiles was: for i in 551${FID}* ; do wine ../../../../dist/BuildDEMFile.exe -O --usedummydata=true -d ${i}/${i}.DEM --hgtpath=../../../../DEM/hgt/ --tre=${i}/${i}.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017; done And for overview map: BuildDEMFile.exe -O --usedummydata=true -d $ABR-1${FID}/551${FID}000.DEM --hgtpath=../../../../DEM/hgt/ --tre=$ABR-1${FID}/551${FID}000.TRE --dlon=0.005 My options file contains the following levels: levels = 0:24, 1:22, 2:21, 3:20, 4:18 overview-levels = 5:17, 6:16, 7:15, 8:14, 9:12 Any idea why 3D doesn't work in BaseCamp? El 16/12/17 a las 14:05, andreas.schmidt.hetschbach@t-online.de escribió:
Thx for the hints, but the Problem was I myself. The 3d-view is only avaiable for the actual Position, i.e. you must have a dem-capable map installed for the actual position – this works now for me too.
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Samstag, 16. Dezember 2017 13:15 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
If you are having problems with dem not showing for 1 level then it may be due to you not using
--usedummydata=true
I find this is essential else indeed it produces dem files which have no effect at all !
I also have
--lastcolstd --overwrite=true
On 16/12/2017 12:04, andreas.schmidt.hetschbach@t-online.de wrote:
…I´m not too sure how this works at all 😊.
But what is (if there is one at all) the relation of the number of dlon-parameters and the so called Levels? I´ve found out that with only one dlon-parameter even the hiillshadung doens´t work. So I choosed the same numbers of Parameters as there are Levels in Options-file
Options-file:
levels = 0:24, 1:23, 2:22, 3:21, 4:20, 5:19
overview-levels = 6:17,7:14
BuildDEMFile.exe:
C:\Garmin\bin\BuildDEMFile.exe -O -d %%i\%%i.DEM --hgtpath=%hgtpath% --tre=%%i\%%i.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017 --dlon=0.0025
Is this correct?
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Samstag, 16. Dezember 2017 12:35 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Interestingly I don't get the error message.
I click on 3d View (available on oregons but not GPS64)
then get this
http://files.mkgmap.org.uk/download/373/oregon6003dview.jpg
On 16/12/2017 10:12, andreas.schmidt.hetschbach@t-online.de wrote:
HI,
not sure if we meant the same thing:
Map displayed with hillshading (Looks ok):
* http://files.mkgmap.org.uk/download/370/2017-12-16_10-57-56_194.jpeg
Menu item 3d-view
* http://files.mkgmap.org.uk/download/371/2017-12-16_10-58-44_277.jpeg
Error
* http://files.mkgmap.org.uk/download/372/2017-12-16_10-58-56_743.jpeg
Regards
Andreas
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Freitag, 15. Dezember 2017 20:34 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Hi Andreas
I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes.
I think you are right ; there is an issue.
On 15/12/2017 19:30, Andreas Schmidt wrote:
Hi Frank,
with ypur great tool I am able to
- have3d - View in basecamp - hillshading on Oregon600
Thats really amazing !
In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information.
Could you make it work on your device?
Andreas
Gesendet mit der Telekom Mail App <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>
-----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk Hi,
i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases.
My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values".
For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue.
Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.
Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?
Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's?
In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps?
I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0
By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense.
Frank
Andreas, I have the same issue with some of my pcs and put it down to the capabilities of the pc's graphics card - but I could be wrong On 18/12/2017 15:37, Carlos Dávila wrote:
I have generated Italy map with DEM. Hillshading is correctly displayed, but 3D option is disabled in BaseCamp. BuildDEMFile command for map tiles was: for i in 551${FID}* ; do wine ../../../../dist/BuildDEMFile.exe -O --usedummydata=true -d ${i}/${i}.DEM --hgtpath=../../../../DEM/hgt/ --tre=${i}/${i}.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017; done And for overview map: BuildDEMFile.exe -O --usedummydata=true -d $ABR-1${FID}/551${FID}000.DEM --hgtpath=../../../../DEM/hgt/ --tre=$ABR-1${FID}/551${FID}000.TRE --dlon=0.005 My options file contains the following levels: levels = 0:24, 1:22, 2:21, 3:20, 4:18 overview-levels = 5:17, 6:16, 7:15, 8:14, 9:12 Any idea why 3D doesn't work in BaseCamp?
El 16/12/17 a las 14:05, andreas.schmidt.hetschbach@t-online.de escribió:
Thx for the hints, but the Problem was I myself. The 3d-view is only avaiable for the actual Position, i.e. you must have a dem-capable map installed for the actual position – this works now for me too.
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Samstag, 16. Dezember 2017 13:15 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
If you are having problems with dem not showing for 1 level then it may be due to you not using
--usedummydata=true
I find this is essential else indeed it produces dem files which have no effect at all !
I also have
--lastcolstd --overwrite=true
On 16/12/2017 12:04, andreas.schmidt.hetschbach@t-online.de wrote:
…I´m not too sure how this works at all 😊.
But what is (if there is one at all) the relation of the number of dlon-parameters and the so called Levels? I´ve found out that with only one dlon-parameter even the hiillshadung doens´t work. So I choosed the same numbers of Parameters as there are Levels in Options-file
Options-file:
levels = 0:24, 1:23, 2:22, 3:21, 4:20, 5:19
overview-levels = 6:17,7:14
BuildDEMFile.exe:
C:\Garmin\bin\BuildDEMFile.exe -O -d %%i\%%i.DEM --hgtpath=%hgtpath% --tre=%%i\%%i.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017 --dlon=0.0025
Is this correct?
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Samstag, 16. Dezember 2017 12:35 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Interestingly I don't get the error message.
I click on 3d View (available on oregons but not GPS64)
then get this
http://files.mkgmap.org.uk/download/373/oregon6003dview.jpg
On 16/12/2017 10:12, andreas.schmidt.hetschbach@t-online.de wrote:
HI,
not sure if we meant the same thing:
Map displayed with hillshading (Looks ok):
* http://files.mkgmap.org.uk/download/370/2017-12-16_10-57-56_194.jpeg
Menu item 3d-view
* http://files.mkgmap.org.uk/download/371/2017-12-16_10-58-44_277.jpeg
Error
* http://files.mkgmap.org.uk/download/372/2017-12-16_10-58-56_743.jpeg
Regards
Andreas
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Freitag, 15. Dezember 2017 20:34 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Hi Andreas
I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes.
I think you are right ; there is an issue.
On 15/12/2017 19:30, Andreas Schmidt wrote:
Hi Frank,
with ypur great tool I am able to
- have3d - View in basecamp - hillshading on Oregon600
Thats really amazing !
In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information.
Could you make it work on your device?
Andreas
Gesendet mit der Telekom Mail App <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>
-----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk Hi,
i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases.
My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values".
For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue.
Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.
Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?
Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's?
In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps?
I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0
By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense.
Frank
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
That may be the problem here, as I can't update graphic card driver in the virtual machine. I'll try to test in a different pc. El 18/12/17 a las 16:42, osm@pinns escribió:
Andreas, I have the same issue with some of my pcs and put it down to the capabilities of the pc's graphics card - but I could be wrong
On 18/12/2017 15:37, Carlos Dávila wrote:
I have generated Italy map with DEM. Hillshading is correctly displayed, but 3D option is disabled in BaseCamp. BuildDEMFile command for map tiles was: for i in 551${FID}* ; do wine ../../../../dist/BuildDEMFile.exe -O --usedummydata=true -d ${i}/${i}.DEM --hgtpath=../../../../DEM/hgt/ --tre=${i}/${i}.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017; done And for overview map: BuildDEMFile.exe -O --usedummydata=true -d $ABR-1${FID}/551${FID}000.DEM --hgtpath=../../../../DEM/hgt/ --tre=$ABR-1${FID}/551${FID}000.TRE --dlon=0.005 My options file contains the following levels: levels = 0:24, 1:22, 2:21, 3:20, 4:18 overview-levels = 5:17, 6:16, 7:15, 8:14, 9:12 Any idea why 3D doesn't work in BaseCamp?
El 16/12/17 a las 14:05, andreas.schmidt.hetschbach@t-online.de escribió:
Thx for the hints, but the Problem was I myself. The 3d-view is only avaiable for the actual Position, i.e. you must have a dem-capable map installed for the actual position – this works now for me too.
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Samstag, 16. Dezember 2017 13:15 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
If you are having problems with dem not showing for 1 level then it may be due to you not using
--usedummydata=true
I find this is essential else indeed it produces dem files which have no effect at all !
I also have
--lastcolstd --overwrite=true
On 16/12/2017 12:04, andreas.schmidt.hetschbach@t-online.de wrote:
…I´m not too sure how this works at all 😊.
But what is (if there is one at all) the relation of the number of dlon-parameters and the so called Levels? I´ve found out that with only one dlon-parameter even the hiillshadung doens´t work. So I choosed the same numbers of Parameters as there are Levels in Options-file
Options-file:
levels = 0:24, 1:23, 2:22, 3:21, 4:20, 5:19
overview-levels = 6:17,7:14
BuildDEMFile.exe:
C:\Garmin\bin\BuildDEMFile.exe -O -d %%i\%%i.DEM --hgtpath=%hgtpath% --tre=%%i\%%i.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017 --dlon=0.0025
Is this correct?
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Samstag, 16. Dezember 2017 12:35 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Interestingly I don't get the error message.
I click on 3d View (available on oregons but not GPS64)
then get this
http://files.mkgmap.org.uk/download/373/oregon6003dview.jpg
On 16/12/2017 10:12, andreas.schmidt.hetschbach@t-online.de wrote:
HI,
not sure if we meant the same thing:
Map displayed with hillshading (Looks ok):
* http://files.mkgmap.org.uk/download/370/2017-12-16_10-57-56_194.jpeg
Menu item 3d-view
* http://files.mkgmap.org.uk/download/371/2017-12-16_10-58-44_277.jpeg
Error
* http://files.mkgmap.org.uk/download/372/2017-12-16_10-58-56_743.jpeg
Regards
Andreas
Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10
*Von: *osm@pinns <mailto:osm@pinns.co.uk> *Gesendet: *Freitag, 15. Dezember 2017 20:34 *An: *mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
Hi Andreas
I have been able to make it work (tapping on the arrows) on my Oregon 600 but its very sluggish and at one stage it just freezes.
I think you are right ; there is an issue.
On 15/12/2017 19:30, Andreas Schmidt wrote:
Hi Frank,
with ypur great tool I am able to
- have3d - View in basecamp - hillshading on Oregon600
Thats really amazing !
In Oregon there is also a menu item „3D“. Even if the map Shows Up hillshading,, this function doesnt work. Oregon complains that the map does Not have enough hight information.
Could you make it work on your device?
Andreas
Gesendet mit der Telekom Mail App <http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>
-----Original-Nachricht----- Von: Frank Stinner <frank.stinner@leipzig.de> Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap Datum: 08.12.2017, 09:27 Uhr An: mkgmap-dev@lists.mkgmap.org.uk Hi,
i must confess, i have never tried to decompilea garmin dem map. I have only playing with bit-patterns and then lookingfor the result in mapsource. But i'm sure, that we have different algorithmsor one algorithm with different special cases.
My description in the pdf is (only) validfor the „TOPO Deutschland v3“. Please see the pages 3 and 4. There area few "unknown values".
For example see "Codierungstyp"(coding type) for a 64x64 tile. I found in different garmin maps valuesfrom 0 to 6. 0 is the standard. It seems to be, that the coding type haveno influence of the algorithm, but i'm not sure. Presumable is this typeonly important for different interpretations of the height values. BuildDEMFileuse type 1 for areas with "unknown height". This is in this casethe interpretation for height=maxvalue.
Unknown is also the byte on position 0x25in the dem header. In the „TOPO Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.
Interesting is also the word in 0x12 in evereyzoomlevel definition (see page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?
Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" to a maplevel. But i don'treally understand the sense ot that. We can have 6 maplevels and we cansay the maplevel 2 and 4 are without dem's?
In a little demo map from garmin i have see"twins" of zoomlevelnumbers, one with value 0 on 0x0 and onewith 1 on 0x0. Perhaps 0x0 is for different and optimized output on pcand gps?
I think, a decompiler with the algo frommy pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0
By the way, have anybody see a dem with valuesin foot? The values in such a dem should be greater then for a dem in meter.Have anybody height values with a precision of foot? The conversion fromfoot to meter would be a first compression step. If garmin really use "foot",then a different/better compression algo make sense.
Frank
participants (4)
-
andreas.schmidt.hetschbach＠t-online.de -
Carlos Dávila -
Gerd Petermann -
osm＠pinns