Style-File not parsed from top to bottom - BUG:
Just to follow up the ignore-turn-restrictions discussion. I have done many more compilations with several different arguments to find out if there is any specific reason why this happens. But I couldn't find any. To me it seems now that the rules given in the stylefile (lines) are not really parsed like they should. This happened with or without the --not-sorted-roads argument (I first suspected that there might be an error, but this argument makes no changes). I assumed that if i give an argument like oneway=yes {set oneway=no} would only affect lines listed below the argument. This seems not to be the case. This is an abrigded lines style-file that does not work like it should (it should not touch the primary, secondary, tertiary oneway settings, but delete them from residential, living_street and : highway=primary [0x10 road_class=0 road_speed=2 resolution 19] highway=secondary [0x0d road_class=0 road_speed=2 resolution 19] highway=tertiary [0x06 road_class=1 road_speed=4 resolution 20] oneway=yes { set oneway=no } oneway=true { set oneway=no } oneway=1 { set oneway=no } oneway=-1 { set oneway=no } oneway=0 {set oneway=no} oneway=false {set oneway=no} highway=residential [0x07 road_class=1 road_speed=4 resolution 22] highway=living_street [0x07 road_class=1 road_speed=3 resolution 22] highway=unclassified [0x07 road_class=1 road_speed=4 resolution 22] Effectively what I get is that for some roads oneway attribute will be set to no, while on most roads the oneway attribute will be lost. Another error to verify: If I put oneway=* {set oneway=no} map generation takes literally ages (2 hours instead of 5 minutes). Using the alternatives as set above map rendering time does not increase significantly from the 5 minutes. the same happens if I put maxspeed=* {set maxspeed=no} into the beginning of the stylefile.
Hi Felix, from what I understand looking at the code, the actions (the part inside the { }) is applied before the data generating rules (the part with the [ ]) gets applied. So what you try to accomplish won't work. The long runtime for rules like maxspeed=* { set maxspeed=no } is a real headache for me. I do preprocessing of the osm files instead. Best regards Thilo
Hi
I assumed that if i give an argument like oneway=yes {set oneway=no} would only affect lines listed below the argument. This seems not to be the case.
The rules are not really read from top to bottom on every element. It is more like they are applied all at once and the resuling type definition that comes first in the rule file(s) is chosen. As a result all actions that are on rules that match are always run and so it is as if all actions occur at the top of the file. I don't see this behaviour changing for rules without a type (like your "oneway=yes { set oneway=no }" below). But for rules with a type, I agree it is a bug if the action is run on something other than the first matched rule. I'll think about this. Thanks, ..Steve
O.k so I was wrongly assuming that single rules, like rules with a type will be read from top to bottom. I would prefer that behaviour, because then it's much easier to apply rules to certain lines only. As I switched to generate my lines file via spreadsheet It's not too bad to implement for me (only prob that my lines file will then reach 5 digit lines, so I hope this will not cause problems instead). As for the long runtime. It works for some items like highway=* without any problem. But running it for oneway and maxspeed does lenghten the compile process for me so much, that I tried it out on maps of supersmall countires like Liechtenstein to see if it would run at all because I though it the compile process had crashed. This is on windows? Maybe we again have a problem with the "*" behaviour. It's definitely buggy using "*" right now when compiling on Windows. Steve Ratcliffe wrote:
Hi
I assumed that if i give an argument like oneway=yes {set oneway=no} would only affect lines listed below the argument. This seems not to be the case.
The rules are not really read from top to bottom on every element. It is more like they are applied all at once and the resuling type definition that comes first in the rule file(s) is chosen. As a result all actions that are on rules that match are always run and so it is as if all actions occur at the top of the file.
I don't see this behaviour changing for rules without a type (like your "oneway=yes { set oneway=no }" below). But for rules with a type, I agree it is a bug if the action is run on something other than the first matched rule.
I'll think about this.
Thanks, ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
__________ Information from ESET Smart Security, version of virus signature database 4081 (20090517) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature database 4081 (20090517) __________ The message was checked by ESET Smart Security. http://www.eset.com
participants (3)
-
Felix Hartmann -
Steve Ratcliffe -
Thilo Hannemann