December 2012 - mkgmap-dev - The mkgmap lists

locator rules and transparent maps
by Thorsten Kukuk 01 Apr '13

01 Apr '13

Hi, I tried to create a transparent map (an additinal layer on top of my basemap) containing address informations, but this does not seem to work. If I include the locator rules (means only create mkgmap:* variables), the maps are no longer transparent, independent of what I use for options. If I remove all mkgmap:* assignements, the map is transparent again. Any idea about this? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

4 5

Polygons deformed
by --enrico 05 Mar '13

05 Mar '13

Hi, I see that the polygons are deformed in MapSource compared to the online openstreetmap view. When I draw a polygon, I make perfect line and angles but when I see it compiled in MapSource it is not the same form. I don’t understand why. Thanks

7 14

installer/license_template.txt should be revised
by Franco Bez 11 Jan '13

11 Jan '13

Hi everybody, I noticed that with every img I create there is a *_license.txt file generated that reads: Map data (c) OpenStreetMap and contributors http://www.openstreetmap.org/ Map data licenced under Creative Commons Attribution ShareAlike 2.0 See http://creativecommons.org/licenses/by-sa/2.0/ Map created with mkgmap-r2426 You know since quite some time the OSM Data is no longer licensed under Creative Commons Attribution ShareAlike 2.0, but there was a switch to Open Data Commons Open Database Lizenz <http://opendatacommons.org/licenses/odbl/> (ODbL) http://opendatacommons.org/licenses/odbl/ Ciao, Franco

3 4

Wiki: Remove translated pages
by WanMil 10 Jan '13

10 Jan '13

Hi, there are quite a few pages in the wiki with translations. I fear most of them (I don't understand all languages ;-) are not up to date and sometimes contain old and/or wrong information. Some examples with date of last change: http://wiki.openstreetmap.org/wiki/DE:Mkgmap Jan 2012 http://wiki.openstreetmap.org/wiki/FR:Mkgmap Nov 2010 http://wiki.openstreetmap.org/wiki/JA:Mkgmap Jan 2010 http://wiki.openstreetmap.org/wiki/NL:Mkgmap Jan 2010 http://wiki.openstreetmap.org/wiki/RU:Mkgmap Aug 2011 http://wiki.openstreetmap.org/wiki/Zh-hans:Mkgmap Apr 2011 I would like to remove them all to avoid misinformation. Any objections or idea how to avoid the problem of unmaintained localized pages? WanMil

3 2

Norway not buildable with the no-trim option
by toc-rox 08 Jan '13

08 Jan '13

I'm not able to build the map for Norway with the "no-trim" option. - Source:norway extract from geofabrik from 22.12.2012 - Bounds from 18.11.2012, Sea Tiles from 12.12.2012 - mkgmap 2412 / splitter 263 Splitter options: Splitter version 263 compiled 2012-12-17T19:04:48+0000 cache= description= geonames-file=/home/kto/Freizeitkarte-Entwicklung-1212/cities/cities15000.zip keep-complete=true mapid=65780001 max-areas=512 max-nodes=800000 max-threads=3 mixed=false no-trim=true output=xml output-dir=/home/kto/Freizeitkarte-Entwicklung-1212/work/Freizeitkarte_Norwegen overlap=-1 polygon-file= problem-file= problem-report= resolution=13 split-file= status-freq=120 stop-after=dist write-kml= This seems to be the problem area (which spans over a large area): Area 65780001 covers (57.568359375,11.689453125) to (61.5234375,31.552734375) and contains 674846 nodes (84 %) Area 65780001 covers (0x28f000,0x85000) to (0x2bc000,0x167000) RU-Saint Petersburg I let splitter calculate the tiles: # List of areas # Generated Sat Dec 22 09:39:42 UTC 2012 # 65780001: 2682880,544768 to 2867200,1470464 # : 57.568359,11.689453 to 61.523438,31.552734 65780002: 3205120,544768 to 3340288,765952 # : 68.774414,11.689453 to 71.674805,16.435547 65780003: 3205120,765952 to 3223552,864256 # : 68.774414,16.435547 to 69.169922,18.544922 mkgmap refuses to build the tile 65780001: java -Xmx6000M -jar /home/kto/Freizeitkarte-Entwicklung-1212/tools/mkgmap/mkgmap.jar --max-jobs=3 -c Freizeitkarte_Norwegen.cfg Time started: Sat Dec 22 09:48:08 UTC 2012 There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first. Perhaps a problem within the map data ... how to investigate it ? Screenshots with the trim option: <http://gis.19327.n5.nabble.com/file/n5741482/Map-Norway-trim.png> <http://gis.19327.n5.nabble.com/file/n5741482/Tiles-Norway-trim.png> Screenshot with the no-trim option: <http://gis.19327.n5.nabble.com/file/n5741482/Map-Norway-notrim.png> <http://gis.19327.n5.nabble.com/file/n5741482/Tiles-Norway-notrim.png> Regards Klaus PS: With the trim option the map is successfully buildable. -- View this message in context: http://gis.19327.n5.nabble.com/Norway-not-buildable-with-the-no-trim-option… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 20

There is not enough room in a single garmin map for all the input data
by GerdP 05 Jan '13

05 Jan '13

I still get this message in mkgmap when processing data that was created with splitter r275 and --precomp-sea option. It seems that it is not sufficient to count the nodes in the precompiled sea data, which leads me to the assumption that this is a general problem with polygons. I don't know what else we could do to handle this problem :-) I've added a few lines of code to get a stacktrace (see attached patch): uk.me.parabola.imgfmt.app.BufferedImgFileWriter.ensureSize(BufferedImgFileWriter.java:197) uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put(BufferedImgFileWriter.java:160) uk.me.parabola.imgfmt.app.trergn.Polyline.write(Polyline.java:145) uk.me.parabola.imgfmt.app.trergn.RGNFile.addMapObject(RGNFile.java:140) uk.me.parabola.imgfmt.app.map.Map.addMapObject(Map.java:242) uk.me.parabola.mkgmap.build.MapBuilder$ShapeAddFilter.doFilter(MapBuilder.java:1156) uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57) uk.me.parabola.mkgmap.build.LayerFilterChain.addElement(LayerFilterChain.java:66) uk.me.parabola.mkgmap.filters.PolygonSplitterFilter.doFilter(PolygonSplitterFilter.java:88) uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57) uk.me.parabola.mkgmap.build.LayerFilterChain.startFilter(LayerFilterChain.java:75) uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1027) uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:712) uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:646) uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:200) uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:97) uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:61) uk.me.parabola.mkgmap.main.Main$1.call(Main.java:208) uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1) java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) java.util.concurrent.FutureTask.run(FutureTask.java:138) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) java.lang.Thread.run(Thread.java:662) stacktrace.patch <http://gis.19327.n5.nabble.com/file/n5741801/stacktrace.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/There-is-not-enough-room-in-a-single-garmin-… Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 17

Draw Order, Precompiled sea and Mapsource
by Roger Calvert 30 Dec '12

30 Dec '12

I am having problems with viaducts and road bridges over tidal water not appearing in Mapsource, though they do appear in Basecamp and on my 60CSx. I suspect this is a draw order problem, and it may be related to Precompiled Sea, and/or to my inclusion of a GBGrid file. I gather Mapsource draw order depends on Mapname. Does the Precompiled Sea have a Mapname built in to mkgmap? Or can/should it be given one? Is it transparent? Should it appear before or after other input files? Some combinations of input show the bridges but not the grid lines where they cross the sea, others show the gridlines but not the bridges. Transparent seems to make no difference. The only sequence I have found which shows both grid lines and bridges over sea is: mapname:60000002 description: Grid-File input-file: GBGrid.osm precomp-sea=..\resources\sea mapname: 60000001 description: GB-Carlisle input-file: 60923011.osm.pbf input-file: ..\resources\style.txt Any guidance would be welcome. Thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

2 4

Input file has a different sort order
by Thomas 28 Dec '12

28 Dec '12

I am trying to creat a sample map with a custom TYP file. Running mkgmap.jar -c 5060.cfg 5060.TYP *.osm.pbf results in an error message which says: WARNING: input file ... has a different sort order (20007 rather than 0 The 5060.cfg file contains the following lines: description=Liechtenstein country-name=Liechtenstein family-name=Liechtenstein series-name=Liechtenstein overview-mapname=Liechtenstein country-abbr=LI mapname=40000001 overview-mapnumber=40000001 family-id=5060 latin1 bounds=bounds name-tag-list="name,name:de,int_name" product-id=1 index route tdbfile gmapsupp draw-priority=25 transparent make-all-cycleways keep-going preserve-element-order generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000 coastlinefile=coastlines_europe-latest.osm.pbf location-autofill=is_in,nearest style-file=/mkgmap/ style=thomas-style show-profiles=1 I have read the thread started Dec. 22nd but the error message doesn't disappear. The gmapsupp file is not routable and searchable. The map is also not searchable in QLandkarte. Any suggestions? Thank you. Thomas

2 2

Commit: r2427: When a typ file is first, before the map files, an incorrect message
by svn commit 28 Dec '12

28 Dec '12

Version 2427 was committed by steve on 2012-12-28 13:57:35 +0000 (Fri, 28 Dec 2012) When a typ file is first, before the map files, an incorrect message is triggered about different sort-orders. Worse it uses the "no sort order" value for the generated index, and so the index will not work.

1 0

[PATCH v1] Rename internal mkgmap tag from display_name to mkgmap:display_name
by WanMil 28 Dec '12

28 Dec '12

The style uses a tag display_name. This is an internal mkgmap tag and should therefore be name mkgmap:display_name. Attached patch changes this but still accepts the old display_name (issuing a warning). WanMil

1 0