August 2020 - mkgmap-dev - The mkgmap lists

Fwd: Re: "Small" SRTM1 files and DEM maps
by Carlos Dávila 05 Oct '20

05 Oct '20

Hi Gerd I replied to your patch a couple of months ago, but I have now realized it didn't arrive to the list (it seems I used and old address). I was surprised you didn't say anything, but didn't want to bother... I used your binary for my test. Today I have tried to apply your patch, but it seems to be generated against a different version of files in trunk. -------- Mensaje reenviado -------- Asunto: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps Fecha: Tue, 21 Apr 2020 17:38:19 +0200 De: Carlos Dávila <cdavilam(a)orangecorreo.es> Para: mkgmap-dev(a)lists.mkgmap.org.uk Hi Gerd I have tested it in an area of 4x10 degrees, in the North of China, and it worked fine. El 21/4/20 a las 14:40, Gerd Petermann escribió: > Hi Carlos, > > please try the attached patch or this binary based on r4483: > http://files.mkgmap.org.uk/download/468/mkgmap.jar > I hope I found all the places that need to be changed. I've only > tested with a map around the point N50 E118. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag > von Carlos Dávila <carlos(a)alternativaslibres.org> > Gesendet: Dienstag, 21. April 2020 11:27 > An: mkgmap-dev(a)lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps > > Great new!! Thanks for your support > > El 21/4/20 a las 11:19, Gerd Petermann escribió: >> Hi Carlos, >> >> yes, I see that the source code handles this format. I finally found >> https://dds.cr.usgs.gov/srtm/version2_1/Documentation/MIL-PDF-89020B.pdf >> I think "TABLE I. Matrix intervals for DTED Level 0." >> shows how to interpret the data. It seems there are a few more >> variants... >> For now I'll try to support also the 1801 * 3601 * 2 format >> >> Gerd >> >> ________________________________________ >> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag >> von Carlos Dávila <carlos(a)alternativaslibres.org> >> Gesendet: Donnerstag, 16. April 2020 17:41 >> An: mkgmap-dev(a)lists.mkgmap.org.uk >> Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps >> >> HI Gerd >> I don't think conversion is wrong. If input geotiff file is 24MB, output >> hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB >> I use this command on Linux: >> for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i >> `basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml >> BTW, gdal is also able to deal with small SRTM files >> >> El 16/4/20 a las 11:31, Gerd Petermann escribió: >>> Hi Carlos, >>> >>> so your conversion routine is wrong. The file size is 12.970.802 >>> bytes. There is no integer n for which 2 * n^2 results in this value. >>> >>> Gerd >>> >>> ________________________________________ >>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag >>> von Carlos Dávila <cdavilam(a)orangecorreo.es> >>> Gesendet: Donnerstag, 16. April 2020 11:19 >>> An: mkgmap-dev(a)lists.mkgmap.org.uk >>> Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps >>> >>> Hi Gerd >>> Forgot to mention files are downloaded as geotiff, but I then convert >>> them to hgt, sorry. >>> You can download a sample one from >>> https://alternativaslibres.org/tmp/N50E118.hgt >>> >>> El 16/4/20 a las 9:18, Gerd Petermann escribió: >>>> Hi Carlos, >>>> >>>> are you talking about geotiff format? I think someone documented >>>> how that format can be converted to *.hgt. >>>> Can you post a link to such a file? >>>> >>>> Gerd >>>> >>>> >>>> >>>> ________________________________________ >>>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag >>>> von Carlos Dávila <cdavilam(a)orangecorreo.es> >>>> Gesendet: Montag, 13. April 2020 14:08 >>>> An: mkgmap-dev(a)lists.mkgmap.org.uk >>>> Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps >>>> >>>> Hi Gerd >>>> They are downloaded by phyghtmap. This is what I found digging into >>>> phyghtmap files: >>>> |def getSRTMFileServer(self, resolution, srtmVersion):|| >>>> || if srtmVersion == 2.1:|| >>>> || return >>>> "https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)|| >>>> || elif srtmVersion == 3.0:|| >>>> || if resolution == 1:|| >>>> || urlRe = >>>> "https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE"|| >>>> || elif resolution == 3:|| >>>> || urlRe = >>>> "https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE"|| >>>> || return urlRe| >>>> They should come from the second URL above. >>>> >>>> El 13/4/20 a las 8:24, Gerd Petermann escribió: >>>>> Hi Carlos, >>>>> >>>>> sorry for the late response. I found no hint on the phyghtmap page >>>>> http://katze.tfiu.de/projects/phyghtmap/ >>>>> regarding a new format for srtm data. The hgt format is not >>>>> compressed. Do you know from where these 12.4 MB files came from? >>>>> >>>>> Gerd >>>>> >>>>> ________________________________________ >>>>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im >>>>> Auftrag von Carlos Dávila <cdavilam(a)orangecorreo.es> >>>>> Gesendet: Samstag, 11. April 2020 17:09 >>>>> An: Development list for mkgmap >>>>> Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps >>>>> >>>>> I use phyghtmap to build contour lines and also to download hgt data >>>>> that I then use to build DEM maps with mkgmap. For a long time, SRTM1 >>>>> files (and also VFP1) have all been ~24.7 MB in size, but lately (I >>>>> don't remember since when) SRTM1 are also served as 12.4 MB files. >>>>> phyghtmap is able to generate contour lines from those small files, as >>>>> they seem to contain the same information but with a different >>>>> compression ratio, but mkgmap fails to read them, and report them as >>>>> missing. Would it be possible to get support for such files in mkgmap? >>>>> _______________________________________________ >>>>> mkgmap-dev mailing list >>>>> mkgmap-dev(a)lists.mkgmap.org.uk >>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>>>> _______________________________________________ >

2 2

DEM There is not enough room in a single garmin map for all the input data
by Joao Almeida 15 Sep '20

15 Sep '20

Help please, could not find a solution that works. I'm trying to build a map that includes DEM shading. I've tried splitting the map with max nodes 800000, 600000 and this last time 400000. For some reason I always get the following message on the same tile regardless of the split maxnodes option. There is however a different behaviour, this only happens if I try to include different polygon areas, if I just try the same are by it self it does not throw the message about map too big. I'm happy to provide poly file and splitter settings and map build options to see if we can overcome this problem. Thanks a lot. Joao SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161838.o5m: exception while creating DEM file There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (thrown in MapBuilder.buildDem()) DEM SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161841.o5m: exception while creating DEM file There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (thrown in MapBuilder.buildDem()) DEM

3 7

Error in Africa?
by valentin3151＠gmail.com 14 Sep '20

14 Sep '20

Hi all, My daily compilation of Africa was stopped because error is appear: SEVERE (MapSplitter): 63240201.osm.pbf: Single item predicted to exceed subdivision http://www.openstreetmap.org/?mlat=10.412207&mlon=-13.010709&zoom=17 Number of MapFailedExceptions: 0 Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 113, Size: 3 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.java:116) at uk.me.parabola.imgfmt.app.map.MapReader.getRoads(MapReader.java:205) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:298) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:171) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onMapEnd(GmapsuppBuilder.java:164) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:665) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144) at uk.me.parabola.mkgmap.main.Main.main(Main.java:115) Link to my tile where the error is: https://maptourist.org/tmp/63240201.osm.pbf I tried to find the cause of this error in OSM but could not. The link from above error log points to the location with completely no data somewhere in the middle of Guinea. As an experiment, I loaded the problem tile into JOSM and fixed all automatically found errors. Then I tried to compile the corrected file. No positive effect. The error is still there. I use mkgmap-r4564, but I found there is no dependency with other versions. How do I find what exactly is causing this error in the OSM data? Previously, this map was compiled many times over a long time without such problem. -- Best regards, Valentin mailto:valentin3151@gmail.com

4 17

Excluding countries from map build or reduce details for some countries.
by Joao Almeida 01 Sep '20

01 Sep '20

Hi, I have an how to question. Hope someone can help. I use poly files to extract areas from the pbf files. but obviously unless you very meticulously outline the countries borders one will always have some of the neighboring country in a map. I would like to be able to have a general style for my map build but have a rule in the style that would remove most of the detail from the map. The general idea would be that one would have only the major highways, none or very few polygons and only the major cities for the country added to the map, in essence a bit like the global garmin basecamp which is very small but still gives us an overview of the whole planet. I tried a deleteall tags rule , but it still added the items but just didn't add the tags. something like (rough example) I know the code is not accurate but hopefully gives you an idea: mkgmap:country=PRT {deletealltags} mkgmap:country=ESP amenity=restaurant (0x000 resolution xx) For country portugal no points would be compiled into the map, for country Spain all items in the style would be compiled into the map. Thanks a lot.

2 1

DEM file options do not work
by Bernard Mai 30 Aug '20

30 Aug '20

Dear All, I am trying to generate a Garmin map containing not only the OSM data and contour lines but also some DEM data to display a hill shading in BaseCamp and on the Garmin device. The general map creation works fine (osm data + contour lines) using the process described on my website (www.maiwolf.de/gps) But so far I fail to use the previously described --dem options. I am using the latest mkgmap release and the following command line: java -Xmx2000M -jar D:[path to mkgmap]mkgmap.jar --dem=C:\hgt --dem-interpolation=auto --dem-dists=3312,3312,3312,13248,26512 --overview-dem-dist=88368 Some example .hgt files are found in the "C:\hgt" folder. Yet nothing happens. No error and no output. So I am wondering if my command line is wrong and if the latest mkgmap version is still having the capability to generate dem data files. I would appreaciate if somebody could describe a successful process in more detail. Regards, Bernard

5 9

PrecompSeaGenerator: update geotools dependency
by Lambertus IJsselstein 18 Aug '20

18 Aug '20

Hi Gerd, To build Mkgmap with the PrecompSeaGenerator additional dependecies are needed, like geotools. Currently (r4565) Mkgmap won't build because the location of geotools has been changed, see: http://geotoolsnews.blogspot.com/2020/04/change-to-maven-repositories.html?… To fix this, update in ivysettings.xml the following line from: <ibiblio name="geotools-resolver" m2compatible="true" root="http://download.osgeo.org/webdav/geotools/" /> To: <ibiblio name="geotools-resolver" m2compatible="true" root="https://repo.osgeo.org/repository/release/" /> Thanks! Regards, Lambertus

1 0

Device Crash Analysis
by jan meisters 16 Aug '20

16 Aug '20

I recently experienced a crash of my Oregon when passing this street <https://www.openstreetmap.org/way/6765658>s <https://www.openstreetmap.org/way/6765658>treet, and reproduced it several times. The device ran in tracking mode, no routing involved. I suspected the bridges on both sides, but found nothing suspicious concerning my style in OSM. Later simulations on device and BC gave no errors. Unfortunately it´s not nearby, so I can´t easily recheck on-site. What other options do I have for further analysis? Thanks Jan

4 4

garmin zumo XT
by brad 09 Aug '20

09 Aug '20

I was successfully building maps for a Montana with my own style. Since the Montana died, I replaced it with a Zumo XT. It isn't working so well now. I can use my map on qmapshack and it looks as expected, but on the Zumo it appears that Garmin does not recognize some (or all) my custom type codes. Any ideas what the limitations are, or how to work with this? They've added something called 'Map Theme', which is a small xml file. I don't see a way to load my typ file, but I didn't need to do that before since I included that with the mkgmap build. Brad

7 14