May 2011 - mkgmap-dev - The mkgmap lists

Tile splitter and merged maps?
by Dominik Röttsches 02 May '11

02 May '11

Hi, I created a merged map using osmosis: $ ./osmosis --rb finland.osm.pbf --rb germany.osm.pbf --rb us-west.osm.pbf --merge --merge --wx DE_FI_USW.osm which results in an uncompressed XML output map DE_FI_USW.osm of ~36G in size. So this maps contains three different countries which do not necessarily have any overlap or connections, and bounding rectangles far apart from each other. Now I try to create one single gmapsup.img out of it using the tile splitter and mkgmap: $ java -Xmx5000M -jar ../splitter.jar --mapid=63240345 --max-nodes=1000000 ../DE_FI_USW.osm after this step I get a list of tiles which is suspiciously small, about 165M. $ java -Xmx4000M -jar ../../mkgmap.jar --max-jobs --style-file=../../aiostyles/basemap_style/ --description='DeFiUs' --country-name=world --country-abbr=W --family-id=4 --product-id=45 --series-name='basemap' --family-name=OSM --area-name=W --latin1 --mapname=63240345 --draw-priority=10 --add-pois-to-areas --make-all-cycleways --link-pois-to-ways --remove-short-arcs --net --route --gmapsupp ../*.osm.gz ../../aiostyles/basemap.TYP When I install the map, I only get map data for Finland, nothing shown for Germany nor US West. So looks like the tile splitter took into account only the first part of the merged .osm map. Am I doing something wrong here? Or is this an incompatibility or a possible problem with the tile splitter? Thanks, Dominik

4 13

Strange behaviour with highway=pedestrain & area=yes
by Josef Latt 01 May '11

01 May '11

Hi, I tried this to mark those areas in my map (found it on several pages): In lines style: highway=pedestrian & area!=yes [0x0d level 2] In polygons style: highway=pedestrian & area=yes [0x13 level 2] Result is,that there is no marked area and the highway itself is not drawn with type 0x0d but with 0x03. What could be wrong? Greetings -- PGP Schlüssel: 311D1055 http://keyserver.pgp.com

1 1

[locator] r1931: PFB support added
by WanMil 01 May '11

01 May '11

r1931 adds PBF support for the boundary osm data that is read in with the --createboundsfile option. WanMil

1 0

Commit: r1932: gmapsupp size
by svn commit 01 May '11

01 May '11

Version 1932 was commited by steve on 2011-05-01 18:40:39 +0100 (Sun, 01 May 2011) gmapsupp size

1 0

[locator] Separate boundary files
by WanMil 01 May '11

01 May '11

I have committed changes to the locator branch which implements the usage of separate precompiled splitted boundary files. How does it work? * 1st step: Extract the boundary data Download an osm dump (e.g. the europe extract from geobfabrik). Extract the boundary data using osmosis: osmosis --rb europe.osm.pbf -tf accept-ways boundary=admistrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm (Maybe the osmosis parameters must be tuned to get *all* boundary data but I haven't investigated very long. Please send proposals how to improve it) * 2nd step: Start mkgmap with additional --createboundsfile option e.g. java -jar mkgmap.jar --createboundsfile=europe-boundaries.osm <... your other options ...> Before compiling the common tiles mkgmap reads the europe-boundaries.osm file, performs the multipolygon processing on it and saves special precompiled boundary tiles to the subdirectory bounds. The subdirectory can be changed by adding the new option --boundsdirectory=<directory> It is possible to precompile whole europe with less then 3GB main memory. The europe boundary tiles need around 330MB (bzip2 compressed ~120MB). * 3rd step: Use the precompiled boundary files After precompiling the bounds directory contains several "bounds_<lat>_<lon>.bnd" tile files. These are loaded and used automatically by the LocationHook. You need to compile the boundary tiles once only. Important: The LocationHook does no longer use the boundary information from the tiles. You need the precompiled boundary tiles. I have decided to go this way because I do not expect that splitter will be able to save tiles with complete multipolygons within a foreseeable period of time. WanMil

12 43

bug report - mkgmap processing of addr: tags
by Charlie Ferrero 01 May '11

01 May '11

Hello, There is a bug in the way mkgmap uses addr: tags to generate address info for POIs. Specifically, if addr:street is not set, then mkgmap will ignore addr:housename, even if it is set. However, if addr:street is not set but addr:housenumber is set, mkgmap will process addr:housenumber. 1) Example of bug name:Frankie's addr:housename=Cherry Cottage addr:city=London mkgmap processes this to Frankie's London 2) Example where things work as expected name:Frankie's addr:housenumber=Cherry Cottage addr:city=London mkgmap processes this to Frankie's Cherry Cottage London A workaround to this bug is to use the following additional style rule in the points file: addr:housename=* & addr:housenumber!=* & addr:street!=* {set addr:housenumber= '${addr:housename}'} But obviously fixing the bug would be nicer. -- Charlie PS I'm using mkgmap r1907

1 0