Hi Nick, it was attached to the quoted post. It contains only these lines: <?xml version='1.0' encoding='UTF-8'?> <osm version='0.6' upload='true' generator='JOSM'> </osm>
________________________________________ Von: mkgmap-dev <[email protected]> im Auftrag von osm@pinns <[email protected]> Gesendet: Donnerstag, 22. März 2018 08:15:02 An: [email protected] Betreff: Re: [mkgmap-dev] DEM Default Levels Hi Gerd That sounds great; how do you create the empty osm file to be fed to splitter? Nick On 22/03/2018 07:12, Gerd Petermann wrote: > Hi Nick, > > when you feed splitter with an empty osm file and a split-file it will create > the empty osm files, only containing the bounds info. > This is all that is needed, and I'd prefer to use splitter to make sure that > the bounds are exactly the same as in the normal files. > > Gerd > > > ________________________________________ > Von: mkgmap-dev <[email protected]> im Auftrag von > osm@pinns <[email protected]> > Gesendet: Donnerstag, 22. März 2018 08:06:53 > An: [email protected] > Betreff: Re: [mkgmap-dev] DEM Default Levels > > Hi Felix > > As Gerd says, you can create dem only gmapsupps which work on devices. > > I use a slightly different method: > > I take the min max values for each tile from the areas.list then create > an empty osm file: > > Use these osm files to create your dem only imgs or gmapsups > > Example: > > Tile from the list has following minmax values: > > 23168581: 2334720,-223232 to 2392064,-169984 > # : 50.097656,-4.790039 to 51.328125,-3.647461 > > Converted to osm: > > <?xml version='1.0' encoding='UTF-8'?> > <osm version='0.6' generator='demonly'> > <bounds minlat='50.09766' minlon='-4.790039' maxlat='51.32813 ' > maxlon='-3.647461'/> > <node id='1092120000000000' lat='50.09766' lon='-4.790039' > timestamp='2017-11-20 11:10:43ZZ' version='1'/> > <node id='1092120000000001' lat='50.09766' lon='-3.647461' > timestamp='2017-11-20 11:10:43ZZ' version='1'/> > <node id='1092120000000002' lat='51.32813' lon='-3.647461' > timestamp='2017-11-20 11:10:43ZZ' version='1'/> > <node id='1092120000000003' lat='51.32813' lon='-4.790039' > timestamp='2017-11-20 11:10:43ZZ' version='1'/> > </osm> > > Nick > > > On 22/03/2018 05:57, Gerd Petermann wrote: >> I also think that hillshading on the device is only useful when you zoom out >> a lot, don't remember the actual values. >> I have a basemap on my oregon which seems good enough for that. >> I think there is no direct connection between DEM data and the (RGN) levels, >> but Frank Stinners pdf [1] claims that this is the case. >> See page 27 for more details. >> I might know more in a few months after my next long cycle tour. Basecamp is >> happy with only one DEM level but uses >> more if available, for example the DEM level used to calculate the elevation >> profile depends on the length of the route, >> the longer the more likely Basecamp selects DEM with lower resolution. Never >> tried that on the device. I also did not try >> any 3D functions so far. >> >> In [2] I described how you can create DEM only tiles and use them to reduce >> computation time. I think this should still work. >> >> Gerd >> >> [1] https://github.com/FSofTlpz/Garmin-DEM-Build/blob/master/DEM-Daten.pdf >> [2] >> http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5909801.html >> >> ________________________________________ >> Von: mkgmap-dev <[email protected]> im Auftrag von >> Felix Hartmann <[email protected]> >> Gesendet: Mittwoch, 21. März 2018 23:01:43 >> An: Development list for mkgmap >> Betreff: Re: [mkgmap-dev] DEM Default Levels >> >> oh yeah - how could I actually exclude DEM at level 24? (with intention to >> still show in Basecamp/Mapsource, but not on device for level 24). So a map >> with DEM only 23-19, while overall resolution of map is 24-18.... >> >> On 21 March 2018 at 23:00, Felix Hartmann >> <[email protected]<mailto:[email protected]>> wrote: >> Well I actually think hillshading is most useful when looking at zoom levels >> 20km to 200m or 120m - any closer and it just makes the map darker without >> actually improving to recognize contours at all. Right now with no input >> given I ended up with 20km to 200/300m no shading, then shading until the >> closest zoomed in. Exactly the opposite of what I would feel is ideal. >> Okay so I will try around a bit too. >> >> BTW - I tried to create empty map with DEM only. Basecamp and Mapsource >> don't like it (gave the typical error - there is not enough space on device, >> sending XX MB free XXXX). It does work without problems in >> Basecamp/Mapsource though for display. Would be quite practical to just hand >> mkgmap readymade empty DEM .img files for saving time on map compilation. >> >> On 21 March 2018 at 22:53, Gerd Petermann >> <[email protected]<mailto:[email protected]>> >> wrote: >> Hi Felix, >> >> I still have no idea how to calculate reasonable values. So far nobody >> proposed a formular, and Garmin also uses >> different values in different maps. So, I think the sample given in the help >> is a good start. I did not see a problem in >> my Oregon with a map having 4 levels and DEM with only 2 levels, I think it >> all depends on personal preferences. >> Anyway, I'd be happy to implement a default if the community agrees on >> something, so feel free to sugeest a formular. >> >> Gerd >> >> >> ________________________________________ >> Von: mkgmap-dev >> <[email protected]<mailto:[email protected]>> >> im Auftrag von Felix Hartmann >> <[email protected]<mailto:[email protected]>> >> Gesendet: Mittwoch, 21. März 2018 22:32:56 >> An: Development list for mkgmap >> Betreff: [mkgmap-dev] DEM Default Levels >> >> I'm a bit unclear about the --dem-dists command. >> It says that at default it chooses sensible values based on .hgt file. Could >> there be an option to by default choose sensible levels based on .hgt AND >> --levels command? >> >> As far as I can see depending on hgt default will go to show from very >> zoomed in to 200 or 300m on Oregon 600 (map detail=normal/default). >> >> Now should I just calculate the values for my levels based on the help file >> no matter the input files? Some maps of mine, e.g. Alps use Viewfinder 1" >> and 3" or SRTM 1" and 3" so if this is related to the .hgt file resolution >> it is not very clear what happens with mixed input files. >> >> >> Could the default be changed to calculate proper values for --levels or add >> a value like --dem-dists=levels that chooses sensible defaults? I guess that >> would be the easiest solution. >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> Schusterbergweg 32/8 >> 6020 Innsbruck >> Austria - Österreich >> _______________________________________________ >> mkgmap-dev mailing list >> [email protected]<mailto:[email protected]> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> Schusterbergweg 32/8 >> 6020 Innsbruck >> Austria - Österreich >> >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> Schusterbergweg 32/8 >> 6020 Innsbruck >> Austria - Österreich >> _______________________________________________ >> 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 _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
