- mkgmap-dev - The mkgmap lists

duplicate evaluation of tags
by Gerd Petermann 05 May '14

05 May '14

Hi all, there is still potential for optimisation: To be able to create an index which gives all rules for a tag like surface=gravel, we order the expressions in the rules so that they start with a tagkey=* or tagkey=value. We use the existing tags of an element to find the rules that have to be checked. Now, if we find two rule like surface=gravel | surface=cobblestone {...} surface=* & surface ~'(abc|xyz)' {...} after searching for rules with tagkey surface=gravel we should save the info that the 1st term in the expression is true. However, there is more to it: Other rules may delete or chang the tag surface=gravel, so this may require too much logic. Maybe it can be done with the new cacheId. Gerd

1 0

r3257 in performance2 branch
by Gerd Petermann 04 May '14

04 May '14

Hi all, today I've fixed one error and added a few more improvements. I've tested r3257 with the styles from Minko, Bernd, Henning and the default style and found no changes between trunk r3248 and the branch, but I only used some tiles from Germany to test. If I hear no complains (and don't find errors) I'll merge to trunk on tuesday. Gerd

1 0

error in performance2 branch
by Gerd Petermann 04 May '14

04 May '14

Hi all, I found an error in the branch regarding the detection of common expressions in or-combined expressions like this: landuse=abc | man_made = xyz [0x640c resolution 23 continue] I'm looking for a fix now... Gerd

1 1

access_country for default style
by Stéphane MARTIN 03 May '14

03 May '14

Hi, Does this proposal makes sense for France ? # France (FRA) highway=trunk & mkgmap:country=FRA { add bicycle=no; add foot=no } highway=cycleway & bicycle=designated & mkgmap:country=FRA { add foot=no } highway=cycleway & mkgmap:country=FRA { set mkgmap:foot=yes; } highway=bridleway & horse=designated & mkgmap:country=FRA { add bicycle=no; add foot=no } highway=bridleway & mkgmap:country=FRA { set mkgmap:foot=yes; set mkgmap:bicycle=yes; } According to http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions… Steph

7 8

r3251 in performance2 branch
by Gerd Petermann 03 May '14

03 May '14

Hi all, please test / review the changes in the branch, because I don't plan any further optimizations for now. You should see no different output compared with r3248 in trunk, but around 15% faster execution time and also a reduction in peak memory usage. @WanMil, Steve: Please let me know if you see problems with the usage of the new TagDict class or the RuleSet.compile() method. The latter uses the toString() method to identify what an Op is doing. Is that okay for you or should I create a different method like getOpIdentifier() to make it clearer that the method should not be changed without good reason? If I hear no complains I'll merge the version to trunk next monday. Gerd

3 3

The --route option
by Gerd Petermann 03 May '14

03 May '14

Hi all, if I got that right, mkgmap doesn't create usable maps without the --route option (index is not complete) On the other hand, StyledConverter doesn't evaluate the option, it just analyses if a line could be routable . A lot of routines are only executed for routable ways, e.g. the housenumber code. I think we should remove (ignore) the --route option, as it is mandantory. If possible, we should allow to create maps that don't contain a NOD section, I think this is wanted by some users. Gerd

7 8

Commit: r3248: improve WrongAngleFixer
by svn commit 02 May '14

02 May '14

Version mkgmap-r3248 was committed by gerd on Fri, 02 May 2014 improve WrongAngleFixer - don't modify lines which are overlays for roads, no matter whether the corresponding road was modified or not. This makes sure that overlay lines are on top of or below the road, not next to it. - use flag to mark overlay lines, this saves quite a lot of HashMap.containsKey() calls

1 0

strange routing
by Minko 02 May '14

02 May '14

Since trunk mkgmap-r3230 the routing has apperently changed and routing has completely gone wrong on my OFM styles. My last Benelux maps are made with mkgmap-r3193 and there the routing seems ok. Gerd, do you have made any important changes between r3193 and r3230 that could cause this? Which version could I test? I also tried mkgmap-performance2-r3245, time reduction is 12% but the routing is still weird.

6 26

Bounds and Sea Data on mkgmap.org.uk -- still old creation process.
by Felix Hartmann 02 May '14

02 May '14

Just a question - is it planned to change the bounds and sea data that is available via mkgmap.org.uk to be update to the high precision format? or maybe put a link to Thorstens site if not? http://osm.thkukuk.de/data/ -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

3 4

r3239 in performance2 branch
by Gerd Petermann 02 May '14

02 May '14

Hi all, I've coded what I described here: http://gis.19327.n5.nabble.com/possible-tuning-for-evaluation-of-tags-tp580… Depending on the options and style I see improvements between 1 % and 15 %. (1% for default style and options --route --preserve-element-order, up to 15% for complex styles like those from Minko or Henning) The more complex the style the more improvement you should see. The cache works like this: - common expressions (e.g. the barrier=* term in my example) in rules are detected when the style is read in, each of them has an int field that identifies a valid cache and the result of the evaluation (true/false) - when a new element is processed, the cache is reset (this just means one int value is incremented) - when a common expression is evaluated for the first time, the normal evaluation happens and the result is cached. - when the same expression is evaluated again the cached value is returned if the cache was not already reset - if an action adds or changes or deletes a tag, the cache is reset again (the more often this happens the less efective is the cache) All this requires more or less no extra heap. One remark regarding rules in <finalize> section: If I got that right, they are all evaluated, no matter what tags the OSM element has. For the "normal" rules we use a filter so that rules which cannot match are not evaluated. If you have time, please check if the branch really is faster and - even more important at this point - produces equal output. Gerd

3 5