January 2012 - mkgmap-dev - The mkgmap lists

[PATCH v1] LocationHook speedup
by WanMil 03 Jan '12

03 Jan '12

Gerds patches inspired me to look for more things that could be improved. I found that the Quadtree used in the LocationHook is not very optimal. The patch is a first try to increase the performance. The time required for the LocationHook is reduced by 10-50% which is great. Warning: I haven't checked so far if the results are equal. So maybe there are big bugs in the patch... (and the speedup comes from the poor implementation) I will do some more tests and optimizations but maybe some of you can have a look on it, test it and comment it. Have fun! WanMil

4 32

Commit: r2158: Optimizing the speed of the style rule system
by svn commit 02 Jan '12

02 Jan '12

Version 2158 was commited by wanmil on 2012-01-02 21:05:04 +0000 (Mon, 02 Jan 2012) Optimizing the speed of the style rule system The internal data structures are changed from Set<Integer> to BitSet. This improves the performance of the detection which style rules need to be applied for an element. --GerdP

1 0

[PATCH] LocationHook performance
by GerdP 02 Jan '12

02 Jan '12

Hello WanMil, attached is a small patch that reduces the number of loops in hasAllTags() to detect if an element is fully worked out. Idea: We do not have to check all tags in remainingLevels, instead we have to check those tags in remainingLevels that are not set be the current boundary. This list is typically much smaller and often empty. http://gis.638310.n2.nabble.com/file/n7143332/LocationHook.patch LocationHook.patch Ciao, Gerd -- View this message in context: http://gis.638310.n2.nabble.com/PATCH-LocationHook-performance-tp7143332p71… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 1

Commit: r2157: Reduce the number of loops to detect if an element is fully worked out in the LocationHook
by svn commit 02 Jan '12

02 Jan '12

Version 2157 was commited by wanmil on 2012-01-02 19:56:41 +0000 (Mon, 02 Jan 2012) Reduce the number of loops to detect if an element is fully worked out in the LocationHook This slightly improves the performance of the LocationHook. --GerdP

1 0

[PATCH]mkgmap performance part 2
by GerdP 02 Jan '12

02 Jan '12

Hello list, I got no feedback regarding my last performance patch for mkgmap, so I don't know if nobody tested it. Anyway, here are a few more small suggestions for changes (can be applied http://gis.638310.n2.nabble.com/file/n7123938/mkgmap_performance_2.patch mkgmap_performance_2.patch on r2145 and gmap-mdr branch 2144 as well) : On my dual-core machine, creating a gmapsupp.img of ~ 91MB (Niedersachsen) with max-jobs=2 required ~ 352 secs with r2145, and 268 secs (~ 25% less) with my previous patch + this one, so I think it is worth trying. For removeShortArcsByMergingNodes: - The IdentityHashMap arcCounts counts arcs, but the only result that is used is wether or not an arc was found. My patch replaces this frequently used map and uses a bit in Coord instead. - the current algorithmn tries to find replacements for each point, this is quite costly. One more bit in Coord reduces the number of loops from > 1.000.000 to ~1000. For LocationHook: I've replaced the getUsedLocationTags() by testHasAllTags(). This just returns true if all tags in List remainingLevels are existing, instead of merging HashSets to get the same result. For RuleSet / RuleIndex: I've replaced the HashSet<Integer> by BitSet. This is faster because we don't have to use Collections.sort(candidates); to handle duplicate rules. Gerd -- View this message in context: http://gis.638310.n2.nabble.com/PATCH-mkgmap-performance-part-2-tp7123938p7… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 22

pbf files
by steve sgalowski 02 Jan '12

02 Jan '12

i downloaded a australia-oceania.osm.pbf from http://download.geofabrik.de/osm/, but when i went to un compress it it says it has to many white spaces and the job crashed . any ideas ? stephen

2 1

Draw priority of lines
by toc-rox 01 Jan '12

01 Jan '12

In the same map I have sometimes the unwanted effect that a stream (river) overlays a way. That's what I want: http://gis.638310.n2.nabble.com/file/n7078255/Bridge-OK.png But often I get this: http://gis.638310.n2.nabble.com/file/n7078255/Bridge-NOK.png The streams are defined after the ways in the lines files. mkgmap = 2136 splitter = 194 Has someone an idea what's going wrong? Regards - Klaus -- View this message in context: http://gis.638310.n2.nabble.com/Draw-priority-of-lines-tp7078255p7078255.ht… Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 14

Garmin codes for Great Britain National Grid
by Roger Calvert 01 Jan '12

01 Jan '12

Last spring, I made an OSM compatible file available to superimpose the GB National Grid on OSM maps using mkgmap. At that time I used Garmin codes 0x1c to 0x1e. These are normally used for administrative boundaries, but I was unable to find any sensible alternative codes. I have now found that it is possible to use high numbered codes which are not allocated, or are allocated to marine applications. I have successfully applied codes in the 0x10300 range: national_grid=100km [0x10302 level 3] national_grid=10km [0x10301 level 2] national_grid=1km [0x10300 level 1] These seem to work correctly in MapSource and on a GPS 60CSx. I have also made suitable TYP file entries, which are available on my download site http://www.rogercalvert.me.uk/OSM/grid, and are compatible with the TYP compiler in recent versions of mkgmap. Note that the compiled IMG file in the download package still uses the previous codes. Regards Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

1 0

Commit: r2156: Optimize the removal of elements from the ElementQuadTree used by the LocationHook
by svn commit 01 Jan '12

01 Jan '12

Version 2156 was commited by wanmil on 2012-01-01 19:05:44 +0000 (Sun, 01 Jan 2012) Optimize the removal of elements from the ElementQuadTree used by the LocationHook

1 0

Commit: r2155: Performance improvements in the LocationHook
by svn commit 01 Jan '12

01 Jan '12

Version 2155 was commited by wanmil on 2012-01-01 12:38:59 +0000 (Sun, 01 Jan 2012) Performance improvements in the LocationHook - The quadtree used in the LocationHook was reimplemented using a more optimal data structure. All functionality not really used was removed from this quadtree. - Checking if the boundary directory contains bounds is now done once only.

1 0