- mkgmap-dev - The mkgmap lists

mkgmap r4025 implements --x-dem-poly option
by Gerd Petermann 06 Jan '18

06 Jan '18

Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4025 this is useful if you create a map for a country extract like nepal (nepal-latest.osm.pbf) Here is a screenshot of a map created with the option --x-dem-poly=nepal.poly http://files.mkgmap.org.uk/download/378/nepal-with-poly.jpg The screenshot also shows some wrong reliefs, and I think I used files without many holes :-( So, next step is to find out what goes wrong with DEM in low resolutions. This might take longer, I hope Frank has an idea. It seems to be a good idea to use a rather high res for the overview map for now. For the screenshot I used --x-overview-dem-dist=276160, with --x-overview-dem-dist=88000 the problems are gone and DEM file is still only ~300KB. Gerd P.S. See also http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&path=%2F&rev=40… I've moved some messages into the logger, so there will be less noise from mkgmap.

5 18

Problem with --x-dem-poly
by Gerd Petermann 06 Jan '18

06 Jan '18

Hi all, I've noticed a few cases where DEM data contains "white lines" at tile borders. They are probably caused by rounding problems when calculating the intersection of the bounding polygon (--x-dem-poly) and the tile boundary. Working on it .... Gerd

3 7

some improvements with mkgmap r4027
by Gerd Petermann 05 Jan '18

05 Jan '18

Hi, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4027 It seems that there is no need for further options, so I'll document the dem options next. Gerd

1 0

sea hgt files
by nwillink 04 Jan '18

04 Jan '18

Hi Gerd I think there is still an issue when --x-dem searches for sea hgt files which by design don't exist . After splitting the UK with maxnodes at 160000 and selecting the far south west (Cornwall) tile I get an error - see below. Its looking for N49W008.hgt which is just sea. Would it be possible to ignore a .hgt if it doesn't exist or use Frank's dummyvalues idea? r Nick java.lang.RuntimeException: failed to open E:\Dem\europe/N49W008.hgt at uk.me.parabola.mkgmap.reader.hgt.HGTReader.<init>(HGTReader.java:45) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.<init>(HGTConverter.jav a:43) at uk.me.parabola.imgfmt.app.dem.DEMSection.<init>(DEMSection.java:51) at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:44) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:284) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.io.FileNotFoundException: E:\Dem\europe\N49W008.hgt (The system cannot find the file specified) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(Unknown Source) at java.io.FileInputStream.<init>(Unknown Source) at java.io.FileInputStream.<init>(Unknown Source) at uk.me.parabola.mkgmap.reader.hgt.HGTReader.<init>(HGTReader.java:38) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 1

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 114, Issue 5
by EthnicFood IsGreat 04 Jan '18

04 Jan '18

> Date: Wed, 3 Jan 2018 04:42:50 -0600 (CST) > From: franco_bez <franco.bez(a)web.de> > To: mkgmap-dev(a)lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ? > > Frank Stinner wrote >> At the moment we have to translate the tiffs from EPSG:3035 to EPSG:4326, >> then the segmentation in 1?x1? tiffs an at last the conversion to hgt >> files. This should not be a very great problem with gdal-tools or so, but >> it is additional work. > Hi Frank, > > thanks for the hint > > It was a long process (some hours), but in the end I succeeded in converting > 4 of the giant copernicus tiff-tiles to 627 small (1?x1?) hgt files. > > 1. I joined the 4 tiles to one monster-file using gdal_merge > 2. I converted the coordiante system with "gdalwarp -s_srs EPSG:3035 -t_srs > EPSG:4326" > 3. with a small shell script the file got cut to 1?x1? tiles using > gdal_translate > i.e. "gdal_translate -strict -q -eco -projwin 10 48 11 47 " for the > N47E010 tile > 4. with another script the tiles were converted from tif to hgt format also > using gdal_translate > "gdal_translate -strict -q -eco -of SRTMHGT -outsize 3601 3601 " > > the scripts I used are only "quick 'n' dirty" hacks. > > a few notes: > There were a few problems to work around > the coordinate system in use by copernicus does not follow the > latitude/longitude degrees > Corner Coordinates of the eu_dem_v11_E30N30.TIF: > Upper Left ( 3000000.000, 4000000.000) ( 12?15'58.58"W, 57?13'49.19"N) > Lower Left ( 3000000.000, 3000000.000) ( 8? 7'39.52"W, 48?38'23.47"N) > Upper Right ( 4000000.000, 4000000.000) ( 4?25'17.11"E, 58?59'15.42"N) > Lower Right ( 4000000.000, 3000000.000) ( 5?31' 4.07"E, 50? 1'26.83"N) > > in EPSG:3035 coordinate it's a perfect square, but in EPSG:4326 it's a > wedge. > I decided to join the copernicus tiles before converting the coordinate > system in order not to run into any problems at the original tile borders. > > the hgt files must start precisely at the degree borders, so the tiles need > to be cut at the precise "projwin" coordinates > > last the hgt tiles must be 3601x3601 pixel > > Ciao, > Franco > I've been following this thread and I want to send congratulations for all the hard work to everyone who has made this DEM feature possible. I look forward to giving it a try when Gerd finishes the documentation. Mark

1 0

Any examples for routing with DEM data ? Anyone ?
by franco_bez 04 Jan '18

04 Jan '18

happy GNU year ! now that we have the possibility to build maps with dem-data I wanted to find out how the Oregon makes use of this data for routing. I tried very hard to find an example where the Oregon would calculate a different route for "minimal ascent" and "minimal distance". I did not succeed :-( I tried routing with several modes (bicycle, mountain bike, tour-cycling); I just cannot find any prove that the Oregon considers the dem-data at all :-( Can anyone give me an example route that shows a difference between routing "minimal ascent" or "minimal distance" ? Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

1 1

problem with names of custom lines on GPSmap 62s
by Philip Homburg 02 Jan '18

02 Jan '18

Hi, I have a problem that the names of some lines do not show up on my GPSmap 62s. They are fine in basecamp. I'm using the following rules: piste:type=downhill & piste:difficulty=easy { name '${piste:name}' | '${name}' | 'piste'; echotags 'easy' } [0x10702 resolution 22] piste:type=downhill & piste:difficulty=advanced { name '${piste:name}' | '${name }' | 'piste'; echotags 'advanced' } [0x10704 resolution 22] The weird thing is that piste:difficulty=easy seems to work fine, but for piste:difficulty=advanced the names do not show up. The lines themselves show up fine (blue and black lines, as custom in Europe). Here is the echotags output of a line that does not show its name: Way 88492394 [mkgmap:admin_level2=AUT, mkgmap:admin_level4=Tirol, mkgmap:admin_l evel6=Bezirk Schwaz, mkgmap:admin_level8=Gerlos, mkgmap:label:1=36, mkgmap:postc ode=6281, name=36, piste:difficulty=advanced, piste:type=downhill] advanced Any idea what I could be doing wrong? Maybe the wrong number for the line? I can't find a clear guide what numbers are supposed to work. (In case it matters, I'm using version 3997 of mkgmap)

2 3

Re: [mkgmap-dev] DEM and "holes"
by Frank Stinner 02 Jan '18

02 Jan '18

This is my tool: https://github.com/FSofTlpz/gdal4hgt https://github.com/FSofTlpz/gdal4hgt/blob/master/bin/Release/Gdal4Hgt.exe It also need gdal-tools like tif2hgt. Frank

1 0

DEM and "holes"
by Frank Stinner 01 Jan '18

01 Jan '18

Unfortunately we have no chance for a good shading if the HGT's have so much "holes" (no data values) like nepal. I have made this picture with QGIS. The blue areas are "no data". I don't know, what makes mapsource with this. Frank --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus

3 5

DEM-file generation from geo-tiff sources ?
by franco_bez 01 Jan '18

01 Jan '18

I'm using phygtmap http://katze.tfiu.de/projects/phyghtmap/ <http://katze.tfiu.de/projects/phyghtmap/> for the creation of contourlines maps. phygtmap automatically downloads the elevation data from several sources. Some sources provide the data in the geo-tiff format, others in the hgt format. phygtmap can handle both formats. Are there any plans for mkgmap to also support the geo-tiff format ? Sources for geo-tiff elevation data https://land.copernicus.eu/pan-european/satellite-derived-products/eu-dem/e… <https://land.copernicus.eu/pan-european/satellite-derived-products/eu-dem/e…> https://earthexplorer.usgs.gov/ <https://earthexplorer.usgs.gov/> -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

1 0