Commit: r1544: Integrate continue with_actions to style branch.
Version 1544 was commited by steve on 2010-02-01 11:41:02 +0000 (Mon, 01 Feb 2010) BRANCH: style Integrate continue with_actions to style branch. This includes duplicating nodes/ways that are resulting in more than one element in the map. I belive that the branch is now feature comparable with the trunk. Only light testing so far.
Well for the first time the style branch kinda works for me.... Compile time increases by about 65% (that's acceptable) with my style (available under CCBYSA 2.0 here: http://openmtbmap.origo.ethz.ch/wiki/development ) Austria takes now 6:16 instead of 3:50 minutes. Max memory consumption (using max-processes=2) goes down from 2640MB to 2428MB, average memory consumption of java process remains pretty stable. I still have to add many !=* so I don't know if the positive effect will still remain. Even though my style has many !=* already implemented, I still have an overhead of around 1.5% of (mostly lines) increase in map data due to some continue rules that I have to prevent. What is really good, is that long rules now work well. Meaning no !=* being dropped anymore. * Problem that I still see vital to be solved before merge with trunk:* I do have problems regarding the action rules though (or better said, absolutely no improvement noticed here). What I would like is that action rules are run by default like [continue with_actions], meaning, that all matching action rules should be applied in order, and not only the first one that matches. Previously action rules were read like an upside down pyramid, the more matches, the higher the priority. Now one has to sort the action rules like an upside down pyramid (and this is really difficult if you have 300-400 action rules with many tags - meaning it is difficult to construct that upside down pyramid) Advantages would be: 1. easier integration of international names: 2. Better general support for naming 3. Easier setting of attributes like unpaved (without dropping another rule or making very very complex action rules 4. Would work better with current trunk styles (they are written as if any action rule would be matched already). * Example:* A way tagged with: highway=path; name=coutêaué; name:translit=couteaue (generated by translit program); mtb:scale=1; mtb:scale=uphill=4; route=mtb; route_name=up_the_hill Following action rules: name:translit=* {set name='${name:translit}'} mtb:scale=1 & mtb:scale:uphill=4 {set name='${name} mtb14' | 'mtb14'} route_name=* {set name='${name} ${route_name}' | '${route_name}' } mtb:scale=* {set mkgmap:paved=no} Current behaviour output: name=/couteaue/ /mkgmap:paved=no/ dropped Changed behaviour rules applied would result in: name=/couteaue mtb14 up the hill/ /mkgmap:paved=no/ applied.
On 01/02/10 13:05, Felix Hartmann wrote:
Well for the first time the style branch kinda works for me....
OK good, thanks for testing.
Compile time increases by about 65% (that's acceptable) with my style (available under CCBYSA 2.0 here:
For the default style there is no performance difference, but for larger styles, there is a noticable drop. I hope to be able to optimise later - anyway it is not going to get slower than that.
What is really good, is that long rules now work well. Meaning no !=* being dropped anymore.
Good.
*Problem that I still see vital to be solved before merge with trunk:* I do have problems regarding the action rules though (or better said, absolutely no improvement noticed here).
What I would like is that action rules are run by default like [continue with_actions], meaning, that all matching action rules should be applied in order, and not only the first one that matches.
That is exactly how it does work on the branch and how it is meant to work on trunk although as usual the random ordering of actions will make it unreliable. I've converted your example into a StyleTester file: WAY highway=path name=coutêaué name:translit=couteaue mtb:scale=1 mtb:scale:uphill=4 route=mtb route_name=up_the_hill #Following action rules: <<<lines>>> name:translit=* {set name='${name:translit}'} mtb:scale=1 & mtb:scale:uphill=4 {set name='${name} mtb14' | 'mtb14'} route_name=* {set name='${name} ${route_name}' | '${route_name}' } mtb:scale=* {set mkgmap:paved=no} highway=path & mkgmap:paved=no [0x7] highway=path [0x8] On the style branch: WAY 1: Line 0x7, name=<couteaue mtb14 up_the_hill>, ref=<null>, res=24-24 (1/1),(2/2), On trunk it doesn't work for the usual random reasons and I see: WAY 1: Line 0x7, name=<couteaue>, ref=<null>, res=24-24 (1/1),(2/2), FAIL. If rules were run strictly in order this would be: Line 0x7, name=<couteaue mtb14 up_the_hill>, ref=<null>, res=24-24 (1/1),(2/2), ..Steve
That is exactly how it does work on the branch and how it is meant to work on trunk although as usual the random ordering of actions will make it unreliable.
It is worth pointing out that the name command works like 'add' and not like 'set', so the correct result of: highway=path { name 'A' } highway=path { name 'B' } highway=path { name 'C' } is to set the name to 'A' and not 'C', whereas highway=path { set name=A } highway=path { set name=B } highway=path { set name=C } will result in ${name} being set to 'C'. In both cases all the actions are actually run in order (on the branch anyway). ..Steve
On 01.02.2010 15:56, Steve Ratcliffe wrote:
That is exactly how it does work on the branch and how it is meant to work on trunk although as usual the random ordering of actions will make it unreliable.
It is worth pointing out that the name command works like 'add' and not like 'set', so the correct result of:
highway=path { name 'A' } highway=path { name 'B' } highway=path { name 'C' }
is to set the name to 'A' and not 'C', whereas
highway=path { set name=A } highway=path { set name=B } highway=path { set name=C }
will result in ${name} being set to 'C'.
Thanks, will give it a try using set. So highway=path {set name=a} highway=path {set name='${name} path'} Should result in a path named: /a path/ whereas not using set the result would be a simple /a/ .....
In both cases all the actions are actually run in order (on the branch anyway).
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 01/02/10 15:03, Felix Hartmann wrote:
So highway=path {set name=a} highway=path {set name='${name} path'}
Should result in a path named: /a path/ whereas not using set the result would be a simple /a/
Yes exactly WAY 1 highway=path WAY 2 highway=footway <<<lines>>> highway=path {set name=a} highway=path {set name='${name} path'} [0x7] highway=footway {name a} highway=footway {name '${name} path'} [0x7] Gives: WAY 1: Line 0x7, name=<a path>, ref=<null>, res=24-24 (1/1),(2/2), WAY 2: Line 0x7, name=<a>, ref=<null>, res=24-24 (1/1),(2/2), ..Steve
participants (3)
-
Felix Hartmann -
Steve Ratcliffe -
svn commit