Bug Report: First rule matches in style files ... not quite!
It says in the documentation that the first rule in the style file that matches the elements is the one used. That is not quite true! The reason is, that the code handles the rules by putting them into baskets organized by the first condition of the rule (with some exceptions). There is for example a basket for all rules with the first condition "highway=residential". When deciding which rule to apply the code will iterate through all the tags of the osm element. It will determine whether there is a corresponding basket and then apply all the rules in that basket in sequence, until one fits. This does work only in simple cases. For example see a way with the following tags: highway=residential rcn=yes This is a residential way that is part of the regional cycle network. (Probably derived by using the "relations" style file to add the tag "rcn=yes" to all ways that are part of an rcn network.) The lines style file will look like -- rcn=yes [ ... some attributes for ways of the cycle network ... ] highway=residential [ ... some other attributes for generic residential roads ... ] -- If the documentation was right the way should always match the first rule (rcn=yes ...). But that is not the case, because it depends on which of the two tags is handled first. This in turn depends on which tag comes first in the osm data. If the tag "rcn=yes" is handled first, the first rule will match, because there is a fitting basket "rcn=yes". This would be according to the documentation. If the tag "highway=residential" is handled first, that rule will (unexpectedly) match, because there is also a fitting basket "highway=residential". To summarize the problem: The baskets are not ordered, therefore the application of the rules is only "until first hit" inside a basket. Between baskets it is "first tag in the osm data that fits". To make matters worse the code also tries to optimize the rules, so that the simple rule "first condition determines basket" does not hold. By inspecting the code it is possible to tweak the rules so that everything works ok, but if somebody can't read the code and tries to build complex style files he will run into serious trouble. Best regards Thilo
Hi On Mon, Apr 20, 2009 at 02:17:53PM +0200, Thilo Hannemann wrote:
It says in the documentation that the first rule in the style file that matches the elements is the one used. That is not quite true!
The reason is, that the code handles the rules by putting them into baskets organized by the first condition of the rule (with some exceptions). There is for example a basket for all rules with the first condition "highway=residential". When deciding which rule to apply the code will iterate through all the tags of the osm element. It will determine whether there is a corresponding basket and then apply all the rules in that basket in sequence, until one fits.
That is how it works, except that it is not just the first tag to match, but the best match. So for each tag, you get the first match within the basket as you say, but then all the other tags are matched against their own baskets and the one with the lowest priority is used. That is the rule earliest in the file. That is what is meant to happen anyway. I remember thinking that there could be a case where something unexpected happens but I can't think of it at this moment.
To summarize the problem: The baskets are not ordered, therefore the application of the rules is only "until first hit" inside a basket. Between baskets it is "first tag in the osm data that fits".
The rules within the baskets are in the order they are read and all baskets that match any tag are considered and not just the first. There could be problems, but I don't think that they are as pronounced as you are saying. Regards, ..Steve
Am 23.04.2009 um 00:06 schrieb Steve Ratcliffe:
On Mon, Apr 20, 2009 at 02:17:53PM +0200, Thilo Hannemann wrote:
It says in the documentation that the first rule in the style file that matches the elements is the one used. That is not quite true!
The reason is, that the code handles the rules by putting them into baskets organized by the first condition of the rule (with some exceptions). There is for example a basket for all rules with the first condition "highway=residential". When deciding which rule to apply the code will iterate through all the tags of the osm element. It will determine whether there is a corresponding basket and then apply all the rules in that basket in sequence, until one fits.
That is how it works, except that it is not just the first tag to match, but the best match. So for each tag, you get the first match within the basket as you say, but then all the other tags are matched against their own baskets and the one with the lowest priority is used. That is the rule earliest in the file.
That is what is meant to happen anyway.
You are completely right. I should learn to *really* read the code.
I remember thinking that there could be a case where something unexpected happens but I can't think of it at this moment.
How ActionRules are applied in order is still a mystery to me, but that was not what my mail was about.
To summarize the problem: The baskets are not ordered, therefore the application of the rules is only "until first hit" inside a basket. Between baskets it is "first tag in the osm data that fits".
The rules within the baskets are in the order they are read and all baskets that match any tag are considered and not just the first. There could be problems, but I don't think that they are as pronounced as you are saying.
Sorry for that. And many thanks for your clarification! Best regards, Thilo
Oh, sorry that my mails treated a subject that was already discussed. @Thilo - You are User:Radfahrer on the wiki, aren't you? You wrote that you could patch this behaviour and I assume that you do that for the maps of Germany that you offer on osm.ardnet . Could you put that patch upstream into mgkmap or are you preprocessing instead? Thilo Hannemann wrote:
It says in the documentation that the first rule in the style file that matches the elements is the one used. That is not quite true!
The reason is, that the code handles the rules by putting them into baskets organized by the first condition of the rule (with some exceptions). There is for example a basket for all rules with the first condition "highway=residential". When deciding which rule to apply the code will iterate through all the tags of the osm element. It will determine whether there is a corresponding basket and then apply all the rules in that basket in sequence, until one fits.
This does work only in simple cases. For example see a way with the following tags:
highway=residential rcn=yes
This is a residential way that is part of the regional cycle network. (Probably derived by using the "relations" style file to add the tag "rcn=yes" to all ways that are part of an rcn network.)
The lines style file will look like -- rcn=yes [ ... some attributes for ways of the cycle network ... ] highway=residential [ ... some other attributes for generic residential roads ... ] --
If the documentation was right the way should always match the first rule (rcn=yes ...). But that is not the case, because it depends on which of the two tags is handled first. This in turn depends on which tag comes first in the osm data. If the tag "rcn=yes" is handled first, the first rule will match, because there is a fitting basket "rcn=yes". This would be according to the documentation. If the tag "highway=residential" is handled first, that rule will (unexpectedly) match, because there is also a fitting basket "highway=residential".
To summarize the problem: The baskets are not ordered, therefore the application of the rules is only "until first hit" inside a basket. Between baskets it is "first tag in the osm data that fits".
To make matters worse the code also tries to optimize the rules, so that the simple rule "first condition determines basket" does not hold.
By inspecting the code it is possible to tweak the rules so that everything works ok, but if somebody can't read the code and tries to build complex style files he will run into serious trouble.
Best regards Thilo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, Am 18.05.2009 um 10:53 schrieb Felix Hartmann:
Oh, sorry that my mails treated a subject that was already discussed. @Thilo - You are User:Radfahrer on the wiki, aren't you?
Yes, that's me.
You wrote that you could patch this behaviour and I assume that you do that for the maps of Germany that you offer on osm.ardnet . Could you put that patch upstream into mgkmap or are you preprocessing instead?
I'm preprocessing. But I don't like preprocessing, because it is time- consuming and should better be done in mkgmap. Unfortunately the code dealing with the rules is too complex for me to come up with a better idea easily. So what I will do in the future is to patch the *behaviour* of mkgmap with regard to the tags, e.g. removing the code that makes the road_speed dependent on the maxspeed tag. That's quite important for cycle maps, isn't it ;). BTW, I was corrected in that thread: the first rule of the style file that fits gets applied. But that is only valid for way-generating rules. The code for the action rules is different and I don't really understand it. To me it seems that the action rules may get applied multiple times on each item - perhaps that is the reason why it is so slow for some rules? Regards Thilo
participants (3)
-
Felix Hartmann -
Steve Ratcliffe -
Thilo Hannemann