- mkgmap-dev - The mkgmap lists

distance to road ERROR
by chris66 22 Mar '18

22 Mar '18

Hi, what does the error "distance to road to large" mean? SCHWERWIEGEND (ExtNumbers): 10000094.osm.gz: internal error, distance to road too large, road id=184899623, SS12 Strada Nazionale Del Canaletto Nord house 1070(47) http://www.openstreetmap.org/node/4712532420 Chris

2 3

Commit r4140: remove dead code
by svn commit 22 Mar '18

22 Mar '18

Version mkgmap-r4140 was committed by gerd on Thu, 22 Mar 2018 remove dead code The attribute linkRoad is never evalutated in the current code http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4140

1 0

Re: [mkgmap-dev] DEM Default Levels
by Felix Hartmann 22 Mar '18

22 Mar '18

Okay thanks, did anyone achieve a construction that shows shading on devices only when zoomed out far? On 22 Mar 2018 8:12 am, "Gerd Petermann" <gpetermann_muenchen(a)hotmail.com> 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 <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von osm@pinns <osm(a)pinns.co.uk> Gesendet: Donnerstag, 22. März 2018 08:06:53 An: mkgmap-dev(a)lists.mkgmap.org.uk 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 <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver(a)gmail.com> > 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 <extremecarver(a)gmail.com<mailto: extremecarver(a)gmail.com>> 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 <gpetermann_muenchen(a)hotmail.com <mailto:gpetermann_muenchen@hotmail.com>> 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 <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces(a)lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>> > 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 > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> > 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 > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 2

DEM Default Levels
by Felix Hartmann 22 Mar '18

22 Mar '18

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

3 8

Missing housenumbers in search index?
by Lorenzo Mastrogiacomi 20 Mar '18

20 Mar '18

Hi all, I noticed many missing housenumbers searching in the maps I am building (actually also with other maps retrieved from the web by other map providers). In this area for example number 20 is present but nearby numbers are missing: https://www.openstreetmap.org/#map=19/43.77845/12.89595 I tryed adding a stryle rule to show the numbers on the map and all of them are shown correctly. Here is a sample gmappsupp built by me in case you want to try: https://drive.google.com/file/d/15MVaJc04SBmGuvYFFOBQYV5Oyst6ejDe/view? usp=drivesdk Search: city=Cartoceto street=Via Sant'anna Thanks Lorenzo

2 7

battery low because of DEM?
by Gerd Petermann 20 Mar '18

20 Mar '18

Hi all, okay, it was quite cold when this happened, but I think my Oregon emptied the batteries (NI-MH accu) within less than 2.5 hours when I used a gmapsupp with DEM. In the summer they easily allow > 6 hours, maybe > 10. It happened two or three times so I tried again with an older gmapsupp without DEM and saw no more problems. I think my device was configured to display DEM "if available". I am not 100% sure that the pack was 100% fully loaded, maybe I forgot to switch off the device after experimenting with it. Did anybody else see similar results? Gerd

4 4

Failing to get size
by nwillink 18 Mar '18

18 Mar '18

Hi Gerd I'm now getting these msgs SEVERE (HGTReader): failed to get size for file N41W126.hgt from E:\Dem\NorthAmerica\N41W126.hgt.zip It seems to apply to zipped hgt files. How important is it to know file sizes? ie is there a need for such a message? Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

3 16

stdout, stderr and logging
by Mike Baggaley 15 Mar '18

15 Mar '18

Dear all, I redirect stdout and stderr to a file when running mkgmap, and then incorporate the file in a build log file that holds the output from my whole build process. I redirect using > mkgmap.log 2>& 1 at the end of the command line, however, I seem to get a few files of the form mkgmap.log.0, mkgmap.log.1 etc each containing just a few lines of echotags output. I suspect that this is due to System.out.println not being thread safe, and if two threads try to write at the same time, one of them ends up creating a separate file. I therefore suggest that we might consider using logging, which is thread safe, rather than System.out.println. There are also a number of other instances of error and warning messages being written using System.out.println, and System.err.println, but most use logging. I think we should standardise on one mechanism for outputting messages. Replacing all the calls to System.out.println and System.err.println would allow proper control using the -Dlog.config switch, which doesn't affect System.out.println and System.err.println calls, and allow all output to be directed to a file directly with that switch, instead of having to use redirection. Because the log.config file allows multiple handlers, this would not prevent the splitting of basic information to stdout with debug information going to a file, if that is required. Thoughts? Regards, Mike

2 3

Commit r4136: fix missing img file in gmapsupp when --max-jobs option is not given
by svn commit 15 Mar '18

15 Mar '18

Version mkgmap-r4136 was committed by gerd on Tue, 13 Mar 2018 fix missing img file in gmapsupp when --max-jobs option is not given http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4136

3 4

Hi have try again and again but cant add dem file to img generate by mkgmap-r4132
by truecrhirst 14 Mar '18

14 Mar '18

have download hgt files and run the following command java -ea -Xmx4000M -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors,close-gaps=6000 --reduce-point-density=5.4 --x-reduce-point-density-polygon=5.4 --index --transparent --adjust-turn-headings --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 --description=openmtbmap_de --location-autofill=1 --route --country-abbr=de --country-name=germany --mapname=12340000 --family-id=1234 --product-id=1 --series-name="openmtbmap_de_%date%" --family-name="mtbmap_de_%date%" --overview-mapname=mapset --area-name="Germany_%date%_openmtbmap.org" -c template.args --dem=c:/hgt the img are generate but without the relied shading and basecamp dnt show the relief shading and either 3d maps dnt work -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 2