Hi Gerd, I think such a binary map should be efficient. Maybe the human readable list can be delivered in the zip-file of mkgmap or stored somewhere else.
Henning On 25.01.2018 19:40, Gerd Petermann wrote: > Hi all, > > I've played with the list of available hgt files created by Henning. > I've coded a reader for the list so that mkgmap can > check if a missing hgt file should exist or if it covers ocean. > The idea is to print a warning if a file was not found when it should be. > The check is fast, but the list is long, so I wonder > if I should store it "as is" in the mkgmap binary like we do with > LocatorConfig.xml > or if I should use another format. > The most obvious for me would be a binary file containing 180*360 bits, a 1 > bit for every > file that should exist. > > What do you think? > > Gerd > > > ________________________________________ > Von: mkgmap-dev <[email protected]> im Auftrag von Gerd > Petermann <[email protected]> > Gesendet: Montag, 15. Januar 2018 14:25 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] How to handle missing hgt files or files with > voids? > > Hi Henning, > > I'll see if I can use srtm.zip. > I think voids are interesting. When I started coding DEM support I searched > my PC for *.hgt files and found them in several places. > Later I found out that some of those files have voids and that better data > exists (assuming that files without voids have fewer errors) > So, I think it would be good to have a list of those files that have voids. > > I'll see what is needed for this. > > Gerd > > ________________________________________ > Von: mkgmap-dev <[email protected]> im Auftrag von > Henning Scholland <[email protected]> > Gesendet: Montag, 15. Januar 2018 12:21:09 > An: [email protected] > Betreff: Re: [mkgmap-dev] How to handle missing hgt files or files with voids? > > This would be the list of all hgt-files available on viewfinder. > > In each zip-file of viewfinder there are 6° in E-W direction and 3° in > N-S. The scheme of naming is also simple. That list I also attached. > > In general I think it's better to just output a list, which > hgt-files/viefinder-tiles are missing than writing a downloader. I mean > in total it's 13GB of data. If you need to download it manually, you are > more aware of what you are doing and not just download them all. > > Regarding voids: I think if there is a possibility the user can fix the > hgt file, A list can be helpful. Otherwise I don't know if a list would > be helpful. Only use case I see is to ask the user to use better data. > But then we need a list, which source is best in which area. And finally > all the different sources need to match each other. Otherwise it will > lead to a hard border between 2 sources. I think this will be much to > complicated... > > Maybe for advanced users there can be a Warning message, hgt-file > N00E100.hgt contains 3 voids. So user can compare different sources > manually. > > Henning > > On 15.01.2018 16:55, Gerd Petermann wrote: >> Hi Henning, >> >> checking data is not that easy, but I'll think about that option. >> >> I'd like to add a short howto that describes ways to get good hgt data, but >> I don't know any method for Windows users. >> phyghtmap is good, but installation on Win is complex and doc for that looks >> out-aged. >> Srtm2Osm seems out-dated, as well as Groundtruth. >> >> So, up to now I try to guess what areas I have to download from viewfinder. >> Any hints ? >> >> Gerd >> >> ________________________________________ >> Von: mkgmap-dev <[email protected]> im Auftrag von >> Henning Scholland <[email protected]> >> Gesendet: Montag, 15. Januar 2018 09:05:24 >> An: Development list for mkgmap >> Betreff: Re: [mkgmap-dev] How to handle missing hgt files or files with >> voids? >> >> Hi Gerd, >> >> regarding 1) I can create a list of existing tiles of Viewfinder (which >> covers all land area so far I see). But it will be a long list. I remember >> it's about 25000 files in total. So maybe it's easier to create a polygon or >> at least take the list and let software create the polygon. An easier way >> can be to check if data is available. No data might be sea. Of course it's >> not 100% sure, as there are deserts and ferries. >> >> Another idea I had during the weekend was to output a osm-file with missing >> areas. So then user can check. But I came to conclusion, that it's easily >> visible in the map later. So I'm not sure it's useful at all. >> >> Henning >> >> On 2018-01-15 15:45, Gerd Petermann wrote: >> >> Hi all, >> >> 1) The current code (only) writes a log message with severity WARNING for a >> missing hgt file: >> "file xxx.hgt not found. Is expected to cover sea." >> I wonder if we can create a list of files that can exist or maybe a polygon >> that can be tested so that >> tiles which are knwon to cover land are reported as errors. >> When you look at >> http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm >> you can see that such a polygon would be quite complex. >> Did anybody already try to define such a polygon or list of files that would >> cover only ocean? >> >> 2) Should mkgmap print a warning when voids in the hgt file(s) have an >> influence on the DEM data? >> I think yes, but it is a bit more complex to measure the real effect. >> Reason: We read the 4 hgt values next to the wanted DEM point and use >> interpolation to calculate the height >> that is stored in the DEM file. >> If one or two of the 4 points are voids they may still have no influence if >> the wanted point is very close to one that >> is not a void. Another problem is that a single void might be used several >> times. >> So, another option would be to add an option like --dem-check-hgt which >> could read all existing hgt files and >> report the number of voids for each. I'd prefer this because it would have >> no impact on performance for normal >> processing. Or maybe there is already a tool for this that works on all >> platforms (win,linux,mac) ? >> >> Comments? >> >> Gerd >> >> >> >> >> >> _______________________________________________ >> mkgmap-dev mailing list >> [email protected]<mailto:[email protected]> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> >> >> _______________________________________________ >> mkgmap-dev mailing list >> [email protected] >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > _______________________________________________ > mkgmap-dev mailing list > [email protected] > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > [email protected] > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
