February 2012 - mkgmap-dev - The mkgmap lists

Suggestion for more flexibility in locator part of mkgmap
by Clifford Nolan 19 Sep '12

19 Sep '12

Hi Greg, Just to clarify ... the admin_levels for Ireland described here http://wiki.openstreetmap.org/wiki/Ireland/Boundaries#Boundary_Types don't seem to mention things like village boundaries - there's a big gap between admin_level=8 and admin_level=10. In situations like this, maybe the locator could be more flexible and use other kinds of boundaries too. Regards, Cliff

3 7

Overview map
by Steve Ratcliffe 19 Jun '12

19 Jun '12

Hi I have started to implement adding features into the overview map. You can find ready built jar files on the download page and in the 'overview' branch in subversion. It creates the overview map from the .img (as before) and so it is very quick to try out even on a set of tiles covering a whole country. There is no configuration yet, it just takes everything (lines and polygons) that is in the least detailed layer of the detailed maps and adds it into the overview. You will immediately notice a big problem in that the overview map shows up even when the detailed maps are being displayed, so you get ugly jagged lines across the top of the map. I remember this happening the last time we has an overview map and I wonder if anyone can remember if there was a solution then? I'm going to start by trying the (so-called) POI flags, as one of those has been noted to be set differently on detail and base maps before. ..Steve

5 15

[PATCH v1] Subdivision splitting
by WanMil 28 May '12

28 May '12

Attached patch should fix (all?) subdivision splitting problems. Error like "Area too small to split at ..." cannot occur any more because the way how subdivisions are split is changed. I think it's still not the optimal way but there should be no loss in highly densed areas any more. This is a first patch not ready to commit because there are some performance penalties which can be reduced. But I want you to test the patch before optimization. WanMil

5 13

NSIS 64bit installer
by Valeriy Pekarskyy 24 May '12

24 May '12

Hi All! So, the bug is that NSIS generates installers that work only at 32bit Windows systems (can anyone confirm?), so I developed a patch for latest version of mkgmap which includes changes to default nsi script and NsisBuilder.java. Can anyone look through? The main difference is that Registry path should be changed if that is x64. Patch link: http://dl.dropbox.com/u/11265861/nsis.patch or http://pastebin.com/pwnptH27 Best Regards, Larry0ua

3 4

gpx track files do not work on routable maps
by Eric Fernandez 08 Mar '12

08 Mar '12

Hi, I have an issue with OSM maps converted using --route and GPX track files, on an Edge 705. When reloading a "Saved Ride" (a GPX track file) on the GPS, the Begin and End points are superimposed (at the location of the End point on the map). I tried with many GPX files, some created on GPsies, some on Bikehike, using various routes (some with cycle ways, some others with only main roads) with the same result. This does not occur with the stock Garmin City Navigator NT maps, or with OSM maps compiled without the --route option (I guess this is normal, it does not do a proper routing in that case). The strange thing is that the routing "on the fly" (using "Where to?" of the GPS unit) works well and uses cycleways as legitimate routes. But using a saved GPX track file fails. This happens with maps compiled using "java -jar mkgmap-r2226/mkgmap.jar --route --gmapsupp -c template.args", no other options are used. Is it a problem with the routing building? Or am I doing something wrong? Thanks, Eric

6 36

[Patch] Add Spanish to nsis installer
by Carlos Dávila 05 Mar '12

05 Mar '12

Attached patch adds Spanish to nsis installer template and extends "AlreadyInstalled" message for the three languages currently available. One issue found is that when reinstalling a map, the "AlreadyInstalled" message shows estrange symbols instead of the special characters such as ó, á or similar. Tested on windows xp and linux (wine).

4 6

Holes in the Sea
by RheinSkipper 05 Mar '12

05 Mar '12

Hello again! I tried to follow all the hints, I got here. But I still cannot do proper sea generation. So I provide as much information as I can, to track down the problem. First I cut out a rectangular part from the osm file. I did not use the planet as source but the Europe extract from Geofabrik for time saving. It shouldn´t make any difference as my cutout is somewhere in the middle of the Geofabrik extract. I use the following command for this: set read=--read-pbf D:\OSM\Geofabrik\europe.osm.pbf set write=--write-pbf D:\OSM\planet\europe.osm.pbf set bbox=--bounding-box left=-0.4 right=11.3 bottom=39 top=45.4 D:\osm\osmosis\bin\osmosis.bat %read% %bbox% completeRelations=yes --tf accept-relations type=boundary,multipolygon --used-way --used-node outPipe.0=MP %read% %bbox% --tf reject-relations type=boundary,multipolygon outPipe.0=bbox --merge inPipe.0=MP inPipe.1=bbox %write% Then I run the splitter with --no-trim and overlap options: java -Xmx3000M -jar splitter\splitter.jar --max-nodes=500000 --no-trim --overlap=10000 --resolution=15 --geonames-file=cities15000.zip --output-dir=tiles planet\europe.osm.pbf 2>err1.txt After this, I make the map: cd img java -Xmx3000m -enableassertions -jar ..\mkgmap\mkgmap.jar -c ..\mkgmap_settings.txt -c ..\tiles\template.args 2>..\err2.txt cd .. And this is my mkgmap_settings.txt: style-file=..\styles style=marine_mode family-name=OSM_Marine series-name=OSM_Marine overview-mapname=OSM_Marine latin1 remove-short-arcs merge-lines reduce-point-density-polygon=4 reduce-point-density=5.4 lower-case add-pois-to-areas #coastlinefile=..\coastlines_europe.osm.pbf generate-sea=multipolygon,extend-sea-sectors,close-gaps=6000 name-tag-list='name,name:de,name:latin,name:en' #index tdbfile nsis The error file is attached. I understand that those ExtTypeAttributes errors come from unfinished code for the seamarks. I do not understand why I get the MapSplitter errors, as I already use very low max-nodes to save memory. And there are still those Polyline errors resulting from sea generation, even on the rectangular cutout. Also attached is a screenshot of those terrible holes in the sea. Everything is running under Win 7 x64 with 4 GB memory. (I know, you´d prefer Linux, but I don´t have a Linux system running.) If it´s a memory issue, which options can I modify to save memory? http://wiki.openstreetmap.org/wiki/User:RheinSkipper

6 24

NumberFormatException when making marine chart
by Jürgen Baumgartl 05 Mar '12

05 Mar '12

Hi, I am trying to make a marine chart out of the Europe file. When I use the marine style from resources/styles/marine, I get a lot of errors similar to this: SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240040.osm.pbf: OSM id 1460137282 (java.lang.NumberFormatException: For input string: "3+") With other styles I do not get this errors. I am running mkgmap under Windows 7 x64 with 4GB memory and -Xmx3000m option. Any suggestions? Regards RheinSkipper

6 13

[PATCH V1] Idea for minor speed improvement for boundary preprocessing
by GerdP 02 Mar '12

02 Mar '12

Hi WanMil, this was a very good hint :-) Time for african boundaries was 250 secs with /branch/performance/r2225, 267 secs with trunk, and with this patch it is now 152 secs - use simple quadtree in BoundarySaver.splitArea() - add try/catch in BoundaryPreparer.run() to allow e.g. usage of assert. Without that, an assertion was handled by the threading routines and caused program stop without any message. Please double check this, I am still not so experienced with try+catch and wrong placed Ciao, Gerd http://gis.19327.n5.nabble.com/file/n5512906/splitArea_v1.patch splitArea_v1.patch WanMil wrote > > Hi Gerd, > > boundary preprocessing takes quite a lot of time. That's not a big > problem because it's performed only by some people who publish their > results. > > But I think some speed improvements would not be bad anyhow?! > > While preprocessing asia and america I go an idea. The area of a > boundary is splitted into the raster. But each time the complete area is > intersected to the raster. In case an area is big and/or complex > (boundary of russia, USA, canada etc.) this takes a long time. It would > be possible first to cut the area into smaller pieces (columns or rows > of the raster) and then do the final cut to the raster. Maybe this saves > time because the column or row areas should be less complex. > > What do you think? > > WanMil > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-V1-Idea-for-minor-speed-improvement-fo… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 4

Commit: r2227: The class MapElement uses a HashMap with default size to store a max. of 8
by svn commit 29 Feb '12

29 Feb '12

Version 2227 was commited by steve on 2012-02-29 22:24:55 +0000 (Wed, 29 Feb 2012) The class MapElement uses a HashMap with default size to store a max. of 8 different, but hard coded String keys. The patch changes this to 8 different String fields which reduces the memory footprint as well as the CPU costs. - Gerd Petermann

1 0