Hi all, I am not aware of any erros in r4091, so I think it is time to merge it into trunk. I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity. [1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5... Gerd
Maybee we can create a ready to use DEM-model, store it like the bounds.zip and see.zip ? The user can download it and mkgmap reads the DEM from downloaded #DEM.ZIP# ? This method would be a graet advantage for users, who not so familiar with the DEM . Regards Thomas -------------------------------------------------- Von: "Gerd Petermann" <GPetermann_muenchen@hotmail.com> Datum: Samstag, 27. Januar 2018 08:54 An: <mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
Hi all,
I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity.
[1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi The idea of a dem.zip sounds would have some major disadvantages 1) Data can only be 3arc or 1 arc not both 2) 1 arc data to me is more preferable but contains void data which have to be replaced with 3arc data Nick On 27/01/2018 09:40, Thomas Morgenstern wrote:
Maybee we can create a ready to use DEM-model, store it like the bounds.zip and see.zip ? The user can download it and mkgmap reads the DEM from downloaded #DEM.ZIP# ? This method would be a graet advantage for users, who not so familiar with the DEM . Regards Thomas -------------------------------------------------- Von: "Gerd Petermann" <GPetermann_muenchen@hotmail.com> Datum: Samstag, 27. Januar 2018 08:54 An: <mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
Hi all,
I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity.
[1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Thomas, I see two major problems with this: 1) A file containing all DEM data for e.g. dem-dist=9936 would be huge, and most users only need a small portion of it 2) I am not sure if it is allowed to publish this data when input comes from e.g. 1'' hgt files which are not free. My understanding is that you may need a licence for this. Besides that my idea of a container format would be close to that. Maybe it would allow to create a download service, something like "request the precompiled DEM data for dem-dist x for a given bounding box or polygon". Unfortunately it seems impossible to reuse complete DEM files unless you also re-use the tile boundaries. If I got that right only a few users are using splitter with the split-file option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern <webmaster@img2ms.de> Gesendet: Samstag, 27. Januar 2018 10:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ? Maybee we can create a ready to use DEM-model, store it like the bounds.zip and see.zip ? The user can download it and mkgmap reads the DEM from downloaded #DEM.ZIP# ? This method would be a graet advantage for users, who not so familiar with the DEM . Regards Thomas -------------------------------------------------- Von: "Gerd Petermann" <GPetermann_muenchen@hotmail.com> Datum: Samstag, 27. Januar 2018 08:54 An: <mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
Hi all,
I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity.
[1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, just to make this clear: The proposed container format is something for the future. I think we should wait at least 6 month to be sure that the encoder is working well, else we would end up with huge files containing wrong data. I think such a container format would require some kind of version management so that we can handle known encoder problems. If you like the idea I can start coding soon after the merge. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 27. Januar 2018 11:21 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ? Hi Thomas, I see two major problems with this: 1) A file containing all DEM data for e.g. dem-dist=9936 would be huge, and most users only need a small portion of it 2) I am not sure if it is allowed to publish this data when input comes from e.g. 1'' hgt files which are not free. My understanding is that you may need a licence for this. Besides that my idea of a container format would be close to that. Maybe it would allow to create a download service, something like "request the precompiled DEM data for dem-dist x for a given bounding box or polygon". Unfortunately it seems impossible to reuse complete DEM files unless you also re-use the tile boundaries. If I got that right only a few users are using splitter with the split-file option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern <webmaster@img2ms.de> Gesendet: Samstag, 27. Januar 2018 10:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ? Maybee we can create a ready to use DEM-model, store it like the bounds.zip and see.zip ? The user can download it and mkgmap reads the DEM from downloaded #DEM.ZIP# ? This method would be a graet advantage for users, who not so familiar with the DEM . Regards Thomas -------------------------------------------------- Von: "Gerd Petermann" <GPetermann_muenchen@hotmail.com> Datum: Samstag, 27. Januar 2018 08:54 An: <mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
Hi all,
I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity.
[1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, first I would suggest to wait for Steve is merging the block size branch and just afterwards merge DEM branch to trunk. I think it's causing trouble merging DEM branch before, as user might end up with errors. Later start another branch for DEM-optimization. I don't know how other global map providers are working. If they all reusing the tile boundaries. In my opinion it's the fastest way and they are definitely don't change often. Of course it would be nice to have a option for mkgmap, writing .DEM files only and read them again later. You pointed out before it's possible already by a hack, (It's working, I just remember I forgot to gave the feedback to you), but of course it's strange to use than 3rd party tools to finalize the map. But of course, I can understand if it's a lot of programming work and not useful for many users properly. As you only can reuse DEM-data, if you keep the tile boundaries, you still need to process DEM-data somehow. Do you think there will be an speed up compared to using uncompressed hgt files? I mean if I only need hgt files for a small area, it doesn't matter so much, if they are zipped or not. In general I don't like your idea about such a container. I have concerns regarding changing a small amount of hgt-tiles with better sources. There will be an issue and the complete container needs to be rewritten. I think it's better to stay with the 1° grid of hgt files and just have an converter to an intermediate format. This makes it much easier to exchange hgt-data later. Just my spontaneous thoughts Henning On 27.01.2018 16:54, Gerd Petermann wrote:
Hi all,
I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity.
[1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Henning, Steve and I agreed that it is okay to merge auto-block into dem-tdb branch instead of trunk. This already happened, so there is no plan to merge auto-block into trunk. I think you are right, it should be easier to reuse complete DEM files. Maybe I can implement this as a faster alternative, e.g. a new option --reuse-dem=<path-to-old-map> where input could be a gmapsupp or gmapi or a directory containing *.img files. When calculating DEM for tile xyz the program would first to find tile xyz in that map, check if position and size matches, and then simply copy the file. This should not require much new code. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Samstag, 27. Januar 2018 14:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ? Hi Gerd, first I would suggest to wait for Steve is merging the block size branch and just afterwards merge DEM branch to trunk. I think it's causing trouble merging DEM branch before, as user might end up with errors. Later start another branch for DEM-optimization. I don't know how other global map providers are working. If they all reusing the tile boundaries. In my opinion it's the fastest way and they are definitely don't change often. Of course it would be nice to have a option for mkgmap, writing .DEM files only and read them again later. You pointed out before it's possible already by a hack, (It's working, I just remember I forgot to gave the feedback to you), but of course it's strange to use than 3rd party tools to finalize the map. But of course, I can understand if it's a lot of programming work and not useful for many users properly. As you only can reuse DEM-data, if you keep the tile boundaries, you still need to process DEM-data somehow. Do you think there will be an speed up compared to using uncompressed hgt files? I mean if I only need hgt files for a small area, it doesn't matter so much, if they are zipped or not. In general I don't like your idea about such a container. I have concerns regarding changing a small amount of hgt-tiles with better sources. There will be an issue and the complete container needs to be rewritten. I think it's better to stay with the 1° grid of hgt files and just have an converter to an intermediate format. This makes it much easier to exchange hgt-data later. Just my spontaneous thoughts Henning On 27.01.2018 16:54, Gerd Petermann wrote:
Hi all,
I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity.
[1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I think before having such a container we would need to have a clear idea what hgt sources are best. I have no objective method to compare hgt sources (is there any?) but I have done some test comparing contour lines generated from different sources. Copernicus (EU-DEM) data has been commented to be better than viewfinderpanoramas (VFP), but at least visually, the later seems better to me. The problem with VFP is that 1'' data is available only in a few places. SRTM1 seems to produce better results than EU-DEM, but in some places it has a lot of voids. Just my findings. If you are interested, I can post some screenshots for comparison. El 27/01/18 a las 09:54, Gerd Petermann escribió:
Hi all,
I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer to have a container format that allows mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file. Such a container could contain the DEM data for one or more dem-dist values. It could be empty first and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would check if the container already contains the data for the wanted area. Advantage would be a faster tile compilation and less power consumption, disadvantage would be the additional disk space and higher complexity.
[1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5...
Gerd
Some results from my .hgt-tests: I wanted to find usable .hgt files for my web-application zu add height data to .gpx http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXclean.html ==> look at: "Spezialisten-Funktionen per Aufrufparameter" ==> sorry, only German ... ==> The results are in the attachment. In short form: ----------------------------------------------------- Viewfinderpanoramas Medium Europe 3sec: ==> lots of voids and too low height values. NASA_USGS 1sec: ==> no voids, but some too low height values. not too bad, but easily correctable by directly adjacent height values. BUT only up to N59 in the north. Viewfinderpanoramas Northern Europe 1/3 sec: ==> some voids in Island in the overlay row/col, but easily correctable by directly adjacent height values. To sum up: More then 3100 .hgt files without real problems. As far as available these are 1sec files. Only in the very north 3sec .hgt files. I'm happy with the NASA_USGS 1sec .hgt files :-) Peter http://www.danninger.eu Am 27.01.2018 um 15:06 schrieb Carlos Dávila:
El 27/01/18 a las 14:57, Carlos Dávila escribió:
I have no objective method to compare hgt sources (is there any?)
Well, a method I have already used is to get the number of voids in a hgt file using QGIS.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks for sharing your results. Have you tested data from http://opendem.info/opendemeu_download_4326.html ? El 27/01/18 a las 15:56, Peter Danninger escribió:
Some results from my .hgt-tests:
I wanted to find usable .hgt files for my web-application zu add height data to .gpx
http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXclean.html ==> look at: "Spezialisten-Funktionen per Aufrufparameter" ==> sorry, only German ...
==> The results are in the attachment.
In short form: ----------------------------------------------------- Viewfinderpanoramas Medium Europe 3sec: ==> lots of voids and too low height values.
NASA_USGS 1sec: ==> no voids, but some too low height values. not too bad, but easily correctable by directly adjacent height values. BUT only up to N59 in the north.
Viewfinderpanoramas Northern Europe 1/3 sec: ==> some voids in Island in the overlay row/col, but easily correctable by directly adjacent height values.
To sum up: More then 3100 .hgt files without real problems. As far as available these are 1sec files. Only in the very north 3sec .hgt files.
I'm happy with the NASA_USGS 1sec .hgt files :-)
Peter
Am 27.01.2018 um 15:06 schrieb Carlos Dávila:
El 27/01/18 a las 14:57, Carlos Dávila escribió:
I have no objective method to compare hgt sources (is there any?)
Well, a method I have already used is to get the number of voids in a hgt file using QGIS.
I've downloaded and testet. look at attachment. In short-form: ----------------------------------------- really good, comparable with the USGS-NASA .hgt-files. N74E018, N74E019: Bjornoya (Bäreninsel) missing, only "0", files deactivated N52E006, N51E005, N51E008, N50E005: some void's, easily correctable comparisation with USGS-NASA files only in the Alps-area and only regarding min/max-values: majority are nearly identical, some differ by 20-30m regarding the min/max-values, but which are "better" ??? regards Peter Am 27.01.2018 um 17:50 schrieb Carlos Dávila:
Thanks for sharing your results. Have you tested data from http://opendem.info/opendemeu_download_4326.html ?
El 27/01/18 a las 15:56, Peter Danninger escribió:
Some results from my .hgt-tests:
I wanted to find usable .hgt files for my web-application zu add height data to .gpx
http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXclean.html ==> look at: "Spezialisten-Funktionen per Aufrufparameter" ==> sorry, only German ...
==> The results are in the attachment.
In short form: ----------------------------------------------------- Viewfinderpanoramas Medium Europe 3sec: ==> lots of voids and too low height values.
NASA_USGS 1sec: ==> no voids, but some too low height values. not too bad, but easily correctable by directly adjacent height values. BUT only up to N59 in the north.
Viewfinderpanoramas Northern Europe 1/3 sec: ==> some voids in Island in the overlay row/col, but easily correctable by directly adjacent height values.
To sum up: More then 3100 .hgt files without real problems. As far as available these are 1sec files. Only in the very north 3sec .hgt files.
I'm happy with the NASA_USGS 1sec .hgt files :-)
Peter
Am 27.01.2018 um 15:06 schrieb Carlos Dávila:
El 27/01/18 a las 14:57, Carlos Dávila escribió:
I have no objective method to compare hgt sources (is there any?)
Well, a method I have already used is to get the number of voids in a hgt file using QGIS.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks for the info!! El 28/01/18 a las 14:20, Peter Danninger escribió:
I've downloaded and testet.
look at attachment.
In short-form: ----------------------------------------- really good, comparable with the USGS-NASA .hgt-files.
N74E018, N74E019: Bjornoya (Bäreninsel) missing, only "0", files deactivated
N52E006, N51E005, N51E008, N50E005: some void's, easily correctable
comparisation with USGS-NASA files only in the Alps-area and only regarding min/max-values:
majority are nearly identical, some differ by 20-30m regarding the min/max-values, but which are "better" ???
regards Peter
Am 27.01.2018 um 17:50 schrieb Carlos Dávila:
Thanks for sharing your results. Have you tested data from http://opendem.info/opendemeu_download_4326.html ?
El 27/01/18 a las 15:56, Peter Danninger escribió:
Some results from my .hgt-tests:
I wanted to find usable .hgt files for my web-application zu add height data to .gpx
http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXclean.html ==> look at: "Spezialisten-Funktionen per Aufrufparameter" ==> sorry, only German ...
==> The results are in the attachment.
In short form: ----------------------------------------------------- Viewfinderpanoramas Medium Europe 3sec: ==> lots of voids and too low height values.
NASA_USGS 1sec: ==> no voids, but some too low height values. not too bad, but easily correctable by directly adjacent height values. BUT only up to N59 in the north.
Viewfinderpanoramas Northern Europe 1/3 sec: ==> some voids in Island in the overlay row/col, but easily correctable by directly adjacent height values.
To sum up: More then 3100 .hgt files without real problems. As far as available these are 1sec files. Only in the very north 3sec .hgt files.
I'm happy with the NASA_USGS 1sec .hgt files :-)
Peter
Am 27.01.2018 um 15:06 schrieb Carlos Dávila:
El 27/01/18 a las 14:57, Carlos Dávila escribió:
I have no objective method to compare hgt sources (is there any?)
Well, a method I have already used is to get the number of voids in a hgt file using QGIS.
Hi all, I think nobody is unhappy with the idea of merging soon? Is anybody aware of problems with r4091 that should be solved first? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Sonntag, 28. Januar 2018 15:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ? Thanks for the info!! El 28/01/18 a las 14:20, Peter Danninger escribió:
I've downloaded and testet.
look at attachment.
In short-form: ----------------------------------------- really good, comparable with the USGS-NASA .hgt-files.
N74E018, N74E019: Bjornoya (Bäreninsel) missing, only "0", files deactivated
N52E006, N51E005, N51E008, N50E005: some void's, easily correctable
comparisation with USGS-NASA files only in the Alps-area and only regarding min/max-values:
majority are nearly identical, some differ by 20-30m regarding the min/max-values, but which are "better" ???
regards Peter
Am 27.01.2018 um 17:50 schrieb Carlos Dávila:
Thanks for sharing your results. Have you tested data from http://opendem.info/opendemeu_download_4326.html ?
El 27/01/18 a las 15:56, Peter Danninger escribió:
Some results from my .hgt-tests:
I wanted to find usable .hgt files for my web-application zu add height data to .gpx
http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXclean.html ==> look at: "Spezialisten-Funktionen per Aufrufparameter" ==> sorry, only German ...
==> The results are in the attachment.
In short form: ----------------------------------------------------- Viewfinderpanoramas Medium Europe 3sec: ==> lots of voids and too low height values.
NASA_USGS 1sec: ==> no voids, but some too low height values. not too bad, but easily correctable by directly adjacent height values. BUT only up to N59 in the north.
Viewfinderpanoramas Northern Europe 1/3 sec: ==> some voids in Island in the overlay row/col, but easily correctable by directly adjacent height values.
To sum up: More then 3100 .hgt files without real problems. As far as available these are 1sec files. Only in the very north 3sec .hgt files.
I'm happy with the NASA_USGS 1sec .hgt files :-)
Peter
Am 27.01.2018 um 15:06 schrieb Carlos Dávila:
El 27/01/18 a las 14:57, Carlos Dávila escribió:
I have no objective method to compare hgt sources (is there any?)
Well, a method I have already used is to get the number of voids in a hgt file using QGIS.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I've noticed that mkgmap cannot process the files that you can download from http://opendem.info/opendemeu_download_4326.html because they are zip files containing a directory that contains the needed file. I've added support for this in r4092 now: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4092 BTW: The files contain different readme.txt that explain the source, all seem to say this: The following credit must be displayed when using these data: "Produced using Copernicus data and information funded by the European Union - EU-DEM layers." Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Samstag, 27. Januar 2018 17:50 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ? Thanks for sharing your results. Have you tested data from http://opendem.info/opendemeu_download_4326.html ? El 27/01/18 a las 15:56, Peter Danninger escribió:
Some results from my .hgt-tests:
I wanted to find usable .hgt files for my web-application zu add height data to .gpx
http://peter.myds.me/HDS/Tipps_Tricks/GPS/GPXclean/GPXclean.html ==> look at: "Spezialisten-Funktionen per Aufrufparameter" ==> sorry, only German ...
==> The results are in the attachment.
In short form: ----------------------------------------------------- Viewfinderpanoramas Medium Europe 3sec: ==> lots of voids and too low height values.
NASA_USGS 1sec: ==> no voids, but some too low height values. not too bad, but easily correctable by directly adjacent height values. BUT only up to N59 in the north.
Viewfinderpanoramas Northern Europe 1/3 sec: ==> some voids in Island in the overlay row/col, but easily correctable by directly adjacent height values.
To sum up: More then 3100 .hgt files without real problems. As far as available these are 1sec files. Only in the very north 3sec .hgt files.
I'm happy with the NASA_USGS 1sec .hgt files :-)
Peter
Am 27.01.2018 um 15:06 schrieb Carlos Dávila:
El 27/01/18 a las 14:57, Carlos Dávila escribió:
I have no objective method to compare hgt sources (is there any?)
Well, a method I have already used is to get the number of voids in a hgt file using QGIS.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (7)
-
Carlos Dávila -
Gerd Petermann -
Gerd Petermann
-
Henning Scholland -
osm＠pinns -
Peter Danninger -
Thomas Morgenstern