April 2011 - mkgmap-dev - The mkgmap lists

[PATCH v1] Simple profiler
by WanMil 17 Apr '11

17 Apr '11

The patch adds a quite simple profiler. It can be enabled by setting its log level to uk.me.parabola.util.Profiler.level=INFO. Adds some time measurings for different tasks to the end of the logfile. More time measurings can and should be added easily. Please send suggestions (patches?). WanMil

1 0

Commit: r1916: Correct the description of --style=routes.
by svn commit 16 Apr '11

16 Apr '11

Version 1916 was commited by marko on 2011-04-16 09:46:26 +0100 (Sat, 16 Apr 2011) Correct the description of --style=routes.

1 0

Commit: r1914: Thin out builtin-tag-list file
by svn commit 13 Apr '11

13 Apr '11

Version 1914 was commited by wanmil on 2011-04-13 18:54:26 +0100 (Wed, 13 Apr 2011) Thin out builtin-tag-list file This slightly reduces memory consumption and processing time.

1 0

[PATCH v1] Thin out builtin-tag-list
by WanMil 13 Apr '11

13 Apr '11

I want to remove all tags that are not necessarily needed but are still remaining in the builtin-tag-list. From my point of view the following tags can be removed: day_off day_on hour_off hour_on => They are only used in the RestricationRelation class to warn the user that these tags are not supported. addr:phone openGeoDB:sort_name => they are not referenced by any java class natural => only accessed by the SeaGenerator and that adds the tag dynamically osm:id? => It is added by the HighwayHook but does it really exists in the source data? barrier cycleway fixme FIXME => only accessed by the HighwayHooks and are added dynamically using the attached patch WanMil

4 7

Commit: r1913: Avoid needless multipolygon handling
by svn commit 12 Apr '11

12 Apr '11

Version 1913 was commited by wanmil on 2011-04-11 21:57:49 +0100 (Mon, 11 Apr 2011) Avoid needless multipolygon handling Multipolygons are no longer processed if they don't contain any tag that is defined in the style or is used in another context by mkgmap.

4 4

maps on 180 degree
by ValentinAK 12 Apr '11

12 Apr '11

I tried to understand the old problem with 180 degree of longitude. The most eastern region of Russia located on the boundary of eastern and western parts of the earth. At this point, Splitter and Mkgmap make the maps divided into 2 parts. Both of these tiles are made with errors. The left tile disappears in Mapsource with overzoom message and looks like without background. See saple images: http://maptourist.org/files/noBackground.png http://maptourist.org/files/overzoom.png Right tile does not appear on the map due to compile errors in Mkgmap: java -Xmx1024m -jar E:\OSM\mkgmap\mkgmap-locator-r1912.jar --output-dir =C:\Garmin\OSM_Russia\mkgmap\ --description="OSM test" --family-name="OSM test 12.04.2011" --series-name="OSM test 12.04.2011" --overview-mapname="OSM_test" --area-name="OSM 12. 04.2011" --family-id=480 --read-config=optionsfile.args --keep-going --st yle-file=E:\OSM\mkgmap\myConfigs --style=myConfigs --gmapsupp E:\OSM\mkgmap\myConf igs\M00001e0.TYP 63240001.osm.gz ... uk.me.parabola.imgfmt.MapFailedException: There is not enough room in a single garmin map for all th e input data The .osm file should be split into smaller pieces first. at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.ensureSize(BufferedImgFileWriter.java:192 ) at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.putChar(BufferedImgFileWriter.java:117) at uk.me.parabola.imgfmt.app.trergn.Polyline.write(Polyline.java:138) at uk.me.parabola.imgfmt.app.trergn.RGNFile.addMapObject(RGNFile.java:140) at uk.me.parabola.imgfmt.app.map.Map.addMapObject(Map.java:242) at uk.me.parabola.mkgmap.build.MapBuilder$ShapeAddFilter.doFilter(MapBuilder.java:1092) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57) at uk.me.parabola.mkgmap.filters.RemoveEmpty.doFilter(RemoveEmpty.java:61) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57) at uk.me.parabola.mkgmap.filters.PolygonSplitterFilter.doFilter(PolygonSplitterFilter.java:5 7) at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57) at uk.me.parabola.mkgmap.build.LayerFilterChain.startFilter(LayerFilterChain.java:75) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:961) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:667) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:601) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:203) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:101) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:65) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:224) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:221) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) I found a temporary solution. If you edit the coordinates of the borders of the two tiles in the file areas.kml (generated by Splitter with option "--split-file=areas.kml") replacing 180.000000 to 179.999998 for the left tile and -180.000000 to -179.999998 for the right tile. Then run Splitter with "--split-file=areas.kml" option. Now both the tiles are compiled correctly. But "Overzoom" area had not gone - it just reduced to 2 km stripe. http://maptourist.org/files/spacing.png I take the OSM data here - http://gis-lab.info/data/osm/full.osm.bz2 My erroneous tiles: Left - http://maptourist.org/files/63240042.osm.gz Right - http://maptourist.org/files/63240001.osm.gz Parameters of the splitter: java-Xmx1024m-jar splitter171.jar ^ - geonames-file = cities1000.zip ^ - overlap = 20000 < - max-nodes = 1000000 ^ - no-trim ^ - write-kml = areas.kml ^ full.osm optionsfile.args: max-jobs: 2 code-page: 1251 tdbfile index country-name: RUSSIA country-abbr: RUS lower-case route net drive-on-right remove-short-arcs location-autofill = 2 generate-sea = extend-sea-sectors, close-gaps = 300,000, floodblocker -- View this message in context: http://gis.638310.n2.nabble.com/maps-on-180-degree-tp6266087p6266087.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

Idea: common string suffix elimination
by Marko Mäkelä 11 Apr '11

11 Apr '11

In the .img files, I see many strings that end in a common suffix. I wonder how hard it would be to maintain an index of string suffixes and point to an existing string instead of storing a new one. For example, if there is a "INFORMAL STREET", the names "FORMAL STREET" and "AL STREET" could point into the string, provided that it is in the 8-bit encoding (or, in the 6-bit encoding, but the encoded string suffix starts at a byte boundary). To save processing time, we could do a "best effort" suffix compression. That is, if "FORMAL STREET" happens to be written before "INFORMAL STREET", then we would not be producing the optimal result. In order to take full advantage of the suffix compression, I think that the display_name for major highways in the default style should lose the (${ref}) suffix. Best regards, Marko

1 0

[PATCH v1] Avoid needless multipolygon handling
by WanMil 11 Apr '11

11 Apr '11

The patch (based on an idea of Marko) checks if a multipolygon and its potential outer members has tags that are defined in the style. If not the multipolygon processing is not performed. This reduces processing time for small styles with a limited set of tags. The effect is not as big as one might expect. Although the style contains one tag only (example maxheight=*) the 53 tags defined in resources/styles/builtin-tag-list are additionally loaded. This reduces the number of skipped multipolygons quite much. Anyhow a little improvement is an improvement :-) WanMil

2 1

Can Extra Resolutions be Implemented
by Bill Lancashire 10 Apr '11

10 Apr '11

It is clear when zooming in on my GPSMAP 62s that Garmin can make use of resolutions greater than 24 with regard to 'styling': I have a map in which I go with the default 'styling' for 'Residential Roads (0x06)' by not specifying this in my TYP file. I zoom-in to the point where I know that level=0 (resolution 24) is displayed and then when I zoom-in further, the thickness of the 0x06 road in the Garmin style definitely gets increases. I can clearly see this if examine with or without a magnifying glass on the screen. So Garmin have definitely got a way to extend their variation of line thickness's beyond the resolution 24 level that is available for us to configure with mkgmap. This maybe something new implemented on the newer Garmin GPS devices that have higher resolution screens. Can mkgmap be extended so that the user can specify styles to appear when zoomed-in over resolution 24 like Garmin do?. /* Bill.*/

1 0

Opening gmapsupp.img with Basecamp?
by Andy Allan 09 Apr '11

09 Apr '11

Hi All, I've been experimenting with Garmin BaseCamp opening gmapsupp.img files that I create. It works fine for some files (even getting the .TYP styling correct) but not for others. After a few hours of testing it seems that it'll open gmapsupp.img files created from 1-20 .osm files but not 30+ .osm files. I'm not certain yet if it's the exact number of files, or the combined size that triggers the failure. Does anyone have any experience with this? or know if there's a particular limit? Anyone been able to generate gmapsupp.img covering (say) the whole UK and get them to open with BaseCamp? I'm willing to do more troubleshooting if that'll help. Cheers, Andy Using mkgmap-r1867 Files split with splitter.jar --max-nodes=900000 java -Xmx3000M -jar ../../mkgmap-r1867/mkgmap.jar \ --family-name="OSM" \ --series-name="OSM" \ --family-id=88 \ --product-id=77 \ --gmapsupp \ --country-abbr="GBR" \ --route --net --remove-short-arcs \ --style-file=../../mkgmap-r1867/resources/styles/cyclemap \ /home/andy/uk/533300[123]*.osm.gz \ ../M0000058.TYP

4 10