February 2018 - mkgmap-dev - The mkgmap lists

mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
by Felix Hartmann 14 Nov '19

14 Nov '19

Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

5 44

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?
by Frank Stinner 05 May '18

05 May '18

For my opinion your data sources are very interesting. This is a short look to the alps, the tile E40N20 from https://land.copernicus.eu/. There seem's to be a little problem at the near of some coastlines, but we have on the other hand a high resolution of 25m. I belive, a bigger problem is the coordinate reference system. Copernicus data have EPSG:3035, garmin use EPSG:4326. It would be fine, if mkgmap could be read geotiffs and calculate with different coordinate reference systems. This would perhaps collect the interpolation for changing the coordinate reference system and for the garmin map. On the other hand: this is a lot of mathematical stuff. I'm not a java hacker and i don't know, if there are usable geografic librarys for this work. 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. Frank

5 13

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

Commit r3842: Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries
by svn commit 09 Apr '18

09 Apr '18

Version mkgmap-r3842 was committed by gerd on Sat, 11 Mar 2017 Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3842

8 15

Bug in Road Merging - actually doubling roads.
by Felix Hartmann 30 Mar '18

30 Mar '18

I just noticed that mkgmap sometimes creates a lot more routable roads for a certain stretch than actually defined in the style-file. https://www.openstreetmap.org/way/130665733 should be only once as a routable line in my map, however it ends up 6 times! Once is correct, but 5 iterations are actually the way from the south (3 times) and the way from the East (2 times). Now each of these ways should be created that often, however it should not overlay into this short stretch of way. While doubling up ways can be beneficial for routing, having a way more than 5 times on top of each other let's Garmin devices crash on routing over them. Also it leads to detours - as it will not always route straight from the Way from South to the Way going to the West, but follow along after the intersection for 4.3m until hitting up north, then reversing and finally going to the way in the West. I've uploaded the tile here: https://openmtbmap.org/gmapsupp_copied.img I'm pretty sure that with other style-files - the way will also be copied past the intersection and end up too often in the map for that 4.3m stretch... I kinda guess it is related to it being so short - that place has some remarkable micro-mapping detail. Or is this really expected? If needed I can try to create a reduced style to only create that problem - but I think the bug should be obvious. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

6 81

Relation type=area
by demon.box 01 Mar '18

01 Mar '18

Hi, excuse me, I mapped some large steps-area with this proposed scheme https://wiki.openstreetmap.org/wiki/Relations/Proposed/Area like a relation with type=area and this is an example https://www.openstreetmap.org/relation/8013769 but with mkgmap I can not render it in any way.... What can I do? There is a way to render it like a simple polygon? Thanks very much. --enrico -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

4 8

Error building DEM map
by Carlos Dávila 28 Feb '18

28 Feb '18

I'm facing an error compiling Algeria map with DEM, using SRTM1 hgt files. In a first run I use splitter as follows: java -Xmx6G -jar splitter.jar --max-nodes=2000000 --geonames-file=geonames/cities15000_$ABR.zip --mapid=551${FID}001 --output=o5m algeria.o5m It gives 5 tiles and when I run mkgmap on them [1], it takes a very long time and finally it fails with "Number of MapFailedExceptions: 1" and a huge (+7GB) log file I could not read. I have manually split problematic tile to a half its original size and then both resulting tiles fail to compile. After dividing them /2, 3 of the 4 tiles fail, but then mkgmap gives the following error: Exception in thread "main" java.lang.NegativeArraySizeException at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.<init>(HGTConverter.java:85) at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:76) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:341) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:191) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuilder.java:104) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:679) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143) at uk.me.parabola.mkgmap.main.Main.main(Main.java:114) And log contains over 10⁷ lines like this: WARNING (HGTConverter): 55129161.o5m: height interpolation returns void at 30.837045,2.094557 After 2 more /2 divisions I could build all tiles. The smallest failing tile can be downloaded from http://alternativaslibres.org/tmp/55129083.o5m [1] java -Xmx4500m -ea -Dlog.config=logging.properties -jar mkgmap.jar --block-size=2048 --dem=hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt --dem-poly=polygons/$pais.poly --dem-dists=3312,6624,9936,13248,26512 --overview-dem-dist=128000 --output-dir=./tmp --gmapi --show-profiles=1 --bounds=bounds.zip --precomp-sea=sea.zip --max-jobs --route --latin1 --code-page=1252 --country-name=$PAIS --country-abbr=$ABR --area-name=$MAPA --family-name="OSM $MAPA DEM" --family-id=5$FID --product-id=1 --product-version=$VERSION --series-name="OSM-$MAPA-DEM" --overview-mapname=$ABR-5$FID --overview-mapnumber=555${FID}000 --name-tag-list=$NAMETAG --index --process-destination --process-exits --housenumbers --reduce-point-density=4 --polygon-size-limits="24:12, 18:10, 16:0" --add-pois-to-areas --link-pois-to-ways --location-autofill=is_in,nearest --drive-on=detect,$DRIVEON --check-roundabouts --check-roundabout-flares --license-file=license_OSM_${HGT} --copyright-file=copyright $LANGUAGE --road-name-config=$CONFIG --x-mdr7-del=GRADE0,GRADE1,GRADE2,GRADE3,GRADE4,GRADE5,GRADE6,GRADE7,UNNAMED --style=mio --remove-ovm-work-files=true -c ${pais}-DEM.args

3 3

Found multiple points with equal coords
by Arndt Röhrig 27 Feb '18

27 Feb '18

2 2

line rule not being triggered
by Ticker Berkin 26 Feb '18

26 Feb '18

Hi I noticed that the default style was putting walkways around some piers because of the line rule: (man_made=pier | man_made=piste:halfpipe) & area!=yes {add highway=footway; name '${ref} ${name}' | '${ref}' | '${name}' } an example is: WAY: 469580183 (50.73379039764404/-1.2820744514465332) [man_made=pier, mkgmap:admin_level10=Whippingham, mkgmap:admin_level2=GBR, mkgmap:admin_level4=England, mkgmap:admin_level5=South East, mkgmap:admin_level6=Isle of Wight, name=Folly Pier] which is using a closed way to draw the pier (and also has a defined footpath along it) Earlier on in my lines file I have: # mark multipolygons as area mkgmap:mp_created=true {add area=yes} highway=* & area!=* & is_closed()=true {echotags 'closed() highway'; add area=yes} and so added the following to fix the problem: man_made=* & is_closed()=true {add area=yes; echotags 'mm'} but this rule isn't being triggered by my example, but if I replace it with: name="Folly Pier" & is_closed()=true {add area=yes; echotags 'fp'} Then it behaves as expected I'm using the latest svn trunk (4127) Any ideas? Thanks Ticker

5 6

Re: [mkgmap-dev] DEM test & artifacts
by David 25 Feb '18

25 Feb '18

Hello Gerd, Here is more information about how I obtained my result. I used mkgmap v4107 and splitter v590. My options for DEM are : dem=./MySrtm1Folder dem-dists=3312,13248,26512,53024,106048 dem-poly=./MyPolygon.poly dem-interpolation=auto overview-dem-dist=212096 I do not define any polygon option for splitter. As explained in my previous email, to avoid the generation of a shadow in plain ocean, I defined a new polygon inside the correct shadow rendering area and it solved my problem. For the artifacts I described, follow this link to see what I mean : http://emerald-island.eu/wikka/ShadowArtifacts It was made with mkgmap version 41067 and 4126 and splitter 590 with the same result. Again for your great work, chapeau bas, David

5 14