- mkgmap-dev - The mkgmap lists

Commit r4168: img_io4_incr.patch by Steve Ratcliffe
by svn commit 18 Apr '18

18 Apr '18

Version mkgmap-r4168 was committed by gerd on Wed, 18 Apr 2018 img_io4_incr.patch by Steve Ratcliffe "I think we should remove the commented out code and I noticed a few unneeded casts remaining (some maybe not actually as a result of the patch), and some javadoc errors." http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4168

1 0

Commit r4167: img_io_3.patch : introduce signed / unsinged write + read methods
by svn commit 18 Apr '18

18 Apr '18

Version mkgmap-r4167 was committed by gerd on Wed, 18 Apr 2018 img_io_3.patch : introduce signed / unsinged write + read methods Patch based on img_io_2.patch by Ticker Berkin http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4167

1 0

methods to write signed / unsigned integers
by Gerd Petermann 17 Apr '18

17 Apr '18

Hi, we have various methods to write an integer with 1, 2, 3, or 4 bytes to an img file. I always feel unsure what method to use because none of them makes clear what happens with negative values. Besides that some of the existing routines seem to throw misleading exceptions, e.g. FileBackedImgFileWriter seems to assume that it is only used for the mdr tmp file and creates texts like this: throw new MapFailedException("could not write3 to mdr tmp file"); throw new MapFailedException("could not write put3 to mdr tmp file"); Only the javadoc for put1() and put2() tell me the range (0..255 or 0..65535) . If I got that right put3() allows negative values, so I think it is NOT 0..16777215 but -8388608 .. 8388607 ? I'd like to improve the readability of the code, but I don't want to mess up anything. Would it be possible to add comments to all the methods? Gerd

5 20

Clarification regarding --make-cycleways
by Lorenzo Mastrogiacomi 16 Apr '18

16 Apr '18

Just a little clarification: Is --make-cycleways option completely ignored or still evaluated for some use? Thanks Lorenzo

2 2

area size in r4160
by Harri Suomalainen 16 Apr '18

16 Apr '18

I have this rule in my style (polygons-file): area_size() < 25000 & (fixme = * | FIXME=* |Fixme=*) {name '${fixme}' | '${FIXME}' | '${Fixme}' } [0x53 resolution 24] It gives an error: Error in style: Error: (polygons:8): Expression cannot be indexed I think this has started in last dev version (or at least within a day or so) -- Harri

4 11

Commit r4165: Fix for expression bug introduced in r4158
by svn commit 16 Apr '18

16 Apr '18

Version mkgmap-r4165 was committed by steve on Mon, 16 Apr 2018 Fix for expression bug introduced in r4158 r4158 was itself an expression fix, but introduced its own problems. There was also a bug that no one noticed involving double negation expressions eg: "!!(a<3)" that was introduced separately. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4165

1 0

Commit r4164: RulesTest: clarify that all errors found are bugs in mkgmap
by svn commit 15 Apr '18

15 Apr '18

Version mkgmap-r4164 was committed by steve on Sun, 15 Apr 2018 RulesTest: clarify that all errors found are bugs in mkgmap In previous versions it was not possible to tell if an expression should work or not, so some syntax errors reported by this test program were not really bugs. In the current version only expressions that should work are generated so any error or crash found is a mkgmap bug. There is now no need to treat SyntaxException differently as they are always bugs as well as crashes. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4164

1 0

Again - java.lang.ArrayIndexOutOfBoundsException: on DEM creation
by Felix Hartmann 13 Apr '18

13 Apr '18

On compiling contourlines with DEM of Antarctica - I get this error: java.lang.ArrayIndexOutOfBoundsException: 7 at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.prepReader(HGTConverter.java:408) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.fillArray(HGTConverter.java:269) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getElevation(HGTConverter.java:149) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getHeights(HGTConverter.java:633) at uk.me.parabola.imgfmt.app.dem.DEMSection.calcTiles(DEMSection.java:139) at uk.me.parabola.imgfmt.app.dem.DEMSection.<init>(DEMSection.java:84) at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:112) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:341) 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:290) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:286) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) java.lang.ArrayIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException It happens with: java -ea -jar -Xmx20000M /home/contourlines/mkgmap.jar --dem=/home/contourlines/hgt/VIEW1/,/home/contourlines/hgt/SRTM1v3.0/,/home/contourlines/hgt/VIEW3/,/home/contourlines/hgt/SRTM3v3.0/ --dem-dists=5520 --dem-poly=/home/contourlines/bounds/antarctica.poly --max-jobs=1 --reduce-point-density=3.6 --transparent --description=openmtbmap-srtm-ANTA-13-Apr-2018 --style-file=srtm --latin1 --draw-priority=24 --mapname=74990000 --family-id=7499 --keep-going --product-id=1 --series-name=openmtbmap-srtm-ANTA-13-Apr-2018 --family-name=mtbmap-srtm-ANTA-2018 --overview-mapname=mapsetz --tdbfile 74990034.osm.pbf 74990037.osm.pbf 74990038.osm.pbf I've uploaded the style srtm (though that is largely irrelevant I guess) and the 3 offending pbf files here: https://openmtbmap.org/broken.zip Even though I guess to reproduce you also need the hgt files. I also get this error on a couple of pbf tiles created by splitter and phyghtmap of Russia (and therefore also on Asia continent). I'm not sure if the fault is in the pbf or in the hgt - As I don't know which hgt file would be coressponding here is the command used with phyghtmap - it will download the relevant hgt files. phyghtmap --earthexplorer-user=XXXXX --earthexplorer-password=XXXXX --jobs=6 --polygon=/home/contourlines/bounds/antarctica.poly --step=20 --no-zero-contour --void-range-max=-420 --output-prefix=anta --line-cat=500,100 --start-node-id=10000000 --start-way-id=10000000 --source=view1,view3,srtm3,srtm1 --max-nodes-per-way=230 --max-nodes-per-tile=0 --pbf -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

2 2

Commit r4160: correct check for indexes when doing bicubic interpolation
by svn commit 13 Apr '18

13 Apr '18

Version mkgmap-r4160 was committed by gerd on Fri, 13 Apr 2018 correct check for indexes when doing bicubic interpolation http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4160

1 0

DEM bug at 50°N
by Bernhard Hiller 13 Apr '18

13 Apr '18

According to the DEM in the map, the Rhine river some 3 km away from my home is at an elevation of some 2600 m asl. I do not live in the Swiss alps, but some 50km west of Frankfurt, just north of 50°N... The correct elevation is about 80m. Near Bingen (just south of 50°N), the Rhine is at an elevation of ~500m, somewhere between Assmannshausen and Lorch it ascends suddenly and very steeply to almost 3000m. In Cologne still at 500 m asl. South of 48°N, the data seem OK; but in the north, I did not find reasonable values - the Elbe in Hamburg above 1000m asl. I exclude a problem in the DEM data: before creating the map of Germany and Czechia, I tested with Hessen only. And then, the DEM values looked reasonable. I use mkgmap 4143. The command includes parameters for DEM: --dem-poly=areas.poly ^ --dem=%DEMPATH% ^ --dem-dists=3314,4000,6000,8000,10000,15000,20000,30000 ^ areas.poly were created by splitter in the step before, SET DEMPATH=E:\Maps\Development\SRTM\L32.zip,E:\Maps\Development\SRTM\M32.zip,E:\Maps\Development\SRTM\N32.zip,E:\Maps\Development\SRTM\L33.zip,E:\Maps\Development\SRTM\M33.zip,E:\Maps\Development\SRTM\N33.zip contains DEM data from http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org… (while testing with Hessen, %DEMPATH% was E:\Maps\Development\SRTM\M32.zip only which contains data from N48E006 to N51E011). Or is it a matter of file size? The largest *.img file has 131256kB. Kind regards, Bernhard

3 9