Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap?
Hi Andrzej, I don't understand. What layers do you mean? How does it help? Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Sonntag, 28. Januar 2018 00:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap? Hi Gerd, I think resolution in bits is a clever idea. This way we can get a tile, where border of all layers is exactly the same. Maybe this is not requirement for a map, but it seems to be a neat solution. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap?
Hi Gerd, I think resolution in bits is a clever idea. This way we can get a tile, where border of all layers is exactly the same. Maybe this is not requirement for a map, but it seems to be a neat solution. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 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 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
Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
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= 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 im Auftrag von Henning Scholland 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-tp5909756p5909801.html > > 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
Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
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
Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
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-tp5909756p5909801.html Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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-tp5909756p5909801.html > > 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
Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
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 im Auftrag von Gerd Petermann 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 im Auftrag von Thomas Morgenstern 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" Datum: Samstag, 27. Januar 2018 08:54 An: 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-tp5909756p5909801.html > > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 im Auftrag von Thomas Morgenstern 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" Datum: Samstag, 27. Januar 2018 08:54 An: 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-tp5909756p5909801.html > > 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
Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?
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" Datum: Samstag, 27. Januar 2018 08:54 An: 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-tp5909756p5909801.html 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
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" Datum: Samstag, 27. Januar 2018 08:54 An: 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-tp5909756p5909801.html 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] splitter r590: (undocumented) option align-for-dem was removed
Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=590 Please make sure to remove the option from your scripts. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[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-tp5909756p5909801.html Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap?
Hi Andrzej, I've thought about removing --resolution as well in the past, but for different reasons: I'd prefer to let splitter decide what resolution is reasonable. I also wonder if there is a good reason to store coordinates in map units instead of degrees in splitter, maybe this was only done to be able to reuse code from mkgmap, maybe it was done to make sure that mkgmap can use the bounding boxes "as is", but this cannot work since the bboxes are stored in the osm format (as bounds statements). Anyway, I think I'll remove most changes in splitter introduced with r585 and r586. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Freitag, 26. Januar 2018 12:29 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap? Hi Gerd, option probably won't be useful. Maybe you could change it to some kind of alternative to --resolution, where value is set in degree, but it still wouldn't look useful to me. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
