Style rules and 'generated' tags
Hi all, Ive been trying to work on some style rule files and am running into a few problems. The rules Im using (in lines) are this: ncn_ref=* { set ncn=yes; echo 'Converting from ${ncn_ref}'; } ( highway=bridleway | highway=byway | highway=cycleway | highway=track | highway=footway) & ( ncn=yes | rcn=yes ) { set offroad='yes'; echo 'Offroad route'; } ncn=yes { echo 'Is NCN'; } offroad=yes { echo 'Is offroad'; } ncn=yes & offroad=yes { echo 'NCN Offroad'; set highway=ncn_offroad; } ncn=yes & offroad!=* { echo 'NCN Onroad'; set highway=ncn_onroad; } (As you can see I added an echo statement to aid debugging... thats about the limit of my Java. :) ) Unfortunately, the penultimate rule (NCN Offroad) never fires. Instead, the next one (NCN Onroad) always does. The debug output for one way looks like this: 31346279: Is NCN testing for offroad <-- debug statement from get in Tags testing for offroad 31346279: NCN Onroad 31346279: Converting from 5 testing for offroad set offroad yes <-- debug statement from perform in AddTagAction 31346279: Offroad route 31346279: Creating NCN on-road with 5 <-- highway=ncn_onroad [0x01] 31346279: Is NCN testing for offroad testing for offroad 31346279: NCN Onroad 31346279: Is offroad 31346279: Creating NCN on-road with 5 So although the Is offroad test is working, the next line isnt. The fact its iterating over the rules a couple of times is a bit odd, too. From what I can tell, get (in Tags.java) isnt coping very well with the ExtraEntry tags. But despite poking around for a couple of hours, Ive not pinned it down - like I say my Java knowledge is verging on non-existent. Or maybe Im just doing something stupid with the rules. Any clues? cheers Richard
Hi Richard
The rules Im using (in lines) are this:
ncn_ref=* { set ncn=yes; echo 'Converting from ${ncn_ref}'; } ( highway=bridleway | highway=byway | highway=cycleway | highway=track | highway=footway) & ( ncn=yes | rcn=yes ) { set offroad='yes'; echo 'Offroad route'; } ncn=yes { echo 'Is NCN'; } offroad=yes { echo 'Is offroad'; } ncn=yes & offroad=yes { echo 'NCN Offroad'; set highway=ncn_offroad; } ncn=yes & offroad!=* { echo 'NCN Onroad'; set highway=ncn_onroad; }
There is nothing wrong with this and I would like it to work. However what currently happens is that for each node/way/relation I go through the tags exactly once and find the earliest rule that matches. Rules with actions have the actions run when seen. So in this case I believe that ncn is already set and has been processed so the change is too late. This is clearly unsatisfactory, but these tips might help: 1. Where possible always have the same tag on the left. This will make things more predictable. For example if you had 'offroad=yes & ncn=yes' the results would appear more consistant. Of course this is not always possible, including in this very case :( 2. Always set made-up tag names if you want to also match on them later. For example use mkgmap:ncn or something. Since the tag is not in the input it cannot possibly have been used yet and so will get its chance later on. It would have to be the left most term too. A final fix would either be about enforcing and clarifying restriction or would probably be slower. But as long as the normal case is a similar speed I don't mind.
(As you can see I added an echo statement to aid debugging... thats about the limit of my Java. :) )
Hey, that looks useful, could you send a patch? Cheers, ..Steve
Steve Ratcliffe wrote:
There is nothing wrong with this and I would like it to work.
However what currently happens is that for each node/way/relation I go through the tags exactly once and find the earliest rule that matches. Rules with actions have the actions run when seen. So in this case I believe that ncn is already set and has been processed so the change is too late.
Ah, that makes sense. Thanks very much for the tips - should really help in finding a way around it.
A final fix would either be about enforcing and clarifying restriction or would probably be slower. But as long as the normal case is a similar speed I don't mind.
I wonder if a "continue" action might be the most efficient way of doing it - i.e. only have the slow behaviour if explicitly requested?
(As you can see I added an echo statement to aid debugging... thats about the limit of my Java. :) )
Hey, that looks useful, could you send a patch?
EchoAction.java attached (to go in osmstyle/actions, of course). It's a bit of a worksforme so apologies for any inelegance. The only other change needed is to add } else if ("echo".equals(cmd)) { String str = scanner.nextWord(); actions.add(new EchoAction(str)); in readActions (ActionReader.java). cheers Richard
Steve Ratcliffe schrieb:
However what currently happens is that for each node/way/relation I go through the tags exactly once and find the earliest rule that matches. Rules with actions have the actions run when seen. So in this case I believe that ncn is already set and has been processed so the change is too late.
I still have some trouble understanding how the rules are working. In the default style there used to be a line highway=* {name '${name ... which included the ref tag into the highway names. If only the first rule is aplied, there would be no single highway transferred into the map. So what will happen with this example. highway=* {set tag_a=yes} tag_a!=yes {set tag_b=yes} tag_a=yes [0x01 resolution 20] tag_b=yes [0x02 resolution 20] highway=* [0x03 resolution 20] Will all highways be converted to 0x01, 0x02 or 0x03? Gruss Torsten
Hi
So what will happen with this example.
highway=* {set tag_a=yes} tag_a!=yes {set tag_b=yes} tag_a=yes [0x01 resolution 20] tag_b=yes [0x02 resolution 20] highway=* [0x03 resolution 20]
Will all highways be converted to 0x01, 0x02 or 0x03?
My guess was 0x01. But it turns out that I was wrong :) Actually it is not a valid style because you can't have tag_a!=yes all by itself. If it were tag_a=yes then the answer would still be 0x01 because that is the first rule with a definition that matches. It seems that the action rules are being used a lot more than I thought going some way beyond what they were designed for. We need to look at what the actions are being used for. I get the impression that a lot of it is to normalize inconsistent tagging, so perhaps we need a separate stage where that is done explicitly. ..Steve
Steve Ratcliffe wrote:
It seems that the action rules are being used a lot more than I thought going some way beyond what they were designed for. We need to look at what the actions are being used for.
If it helps, I finished (\o/) the map I was working on, and have uploaded both it and the source. http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Cycle_map http://svn.openstreetmap.org/applications/utils/export/garmincyclemap/networ... http://www.openstreetmap.org/user/Richard/diary/6949 (Thanks again for all the help!) cheers Richard
Hi
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Cycle_map http://svn.openstreetmap.org/applications/utils/export/garmincyclemap/networ... http://www.openstreetmap.org/user/Richard/diary/6949
Looks great! Is there anything that you would really like it to do that it doesn't yet? ..Steve
Steve Ratcliffe schrieb:
highway=* {set tag_a=yes} tag_a!=yes {set tag_b=yes} tag_a=yes [0x01 resolution 20] tag_b=yes [0x02 resolution 20] highway=* [0x03 resolution 20]
Will all highways be converted to 0x01, 0x02 or 0x03?
My guess was 0x01. But it turns out that I was wrong :) Actually it is not a valid style because you can't have tag_a!=yes all by itself.
In OSM you can have any tags you like, so there is no reason, why such a style would be invalid (e.g. you could use such a scheme, to set all highway=footway to highway=path and foot=designated). And I think, if I would change the second line to highway=* tag_a!=yes {set tag_b=yes} it wouldn't change anything, or would it? I am still trying to figure out, how the rules are working at the moment. So what is the result of the above? (I haven't tried it myself.) Which lines are processed in which are left out? What would happen, if the second lien would be changed to the following: tag_a!=yes {set tag_a=no; set tag_b=yes}
It seems that the action rules are being used a lot more than I thought going some way beyond what they were designed for. We need to look at what the actions are being used for. I get the impression that a lot of it is to normalize inconsistent tagging, so perhaps we need a separate stage where that is done explicitly.
I don't know, what is possible with the action rules right now, since I am still trying to figure out, how they are working. Right now I am trying to use the action rules, to generate a bicycle routing map, which uses the Garmin-Navi in car-mode, because of the better routing algorithms. Therefor I am tweeking the road classes and the access restrictions. So basically I am trying to use the action rules as a preprocessor for the OSM data. Oh, and by the way: Would it be possible, to add support for a "txt" extension for the style files? It is quite anoying on a windows system, that you always have to choose manually the application, when you open a style file. Gruss Torsten
2009/7/7 Torsten Leistikow <de_muur@gmx.de>
Steve Ratcliffe schrieb:
highway=* {set tag_a=yes} tag_a!=yes {set tag_b=yes} tag_a=yes [0x01 resolution 20] tag_b=yes [0x02 resolution 20] highway=* [0x03 resolution 20]
Will all highways be converted to 0x01, 0x02 or 0x03?
My guess was 0x01. But it turns out that I was wrong :) Actually it is not a valid style because you can't have tag_a!=yes all by itself.
In OSM you can have any tags you like, so there is no reason, why such a style would be invalid (e.g. you could use such a scheme, to set all highway=footway to highway=path and foot=designated).
And I think, if I would change the second line to
highway=* tag_a!=yes {set tag_b=yes}
it wouldn't change anything, or would it?
I am still trying to figure out, how the rules are working at the moment. So what is the result of the above? (I haven't tried it myself.) Which lines are processed in which are left out?
What would happen, if the second lien would be changed to the following: tag_a!=yes {set tag_a=no; set tag_b=yes}
It seems that the action rules are being used a lot more than I thought going some way beyond what they were designed for. We need to look at what the actions are being used for. I get the impression that a lot of it is to normalize inconsistent tagging, so perhaps we need a separate stage where that is done explicitly.
I don't know, what is possible with the action rules right now, since I am still trying to figure out, how they are working.
you can have tags only, but they dont create a copy of the map. whereas lines seem to be taken for polygons if not asked for in the style-file (i.e. if you set have_riverbank=yes to display water in the polygon file and any simple line is joined to become a polygon, often with the generated water layed over large areas, lines will only be drawn if they are somehow attached to highway=* & asdf also when creating style-rules the order is important. highway=* has to be first, or else some rules will not work so while asdf & highway=* [0x01 resolution 24] does not work, highway=* & asdf [0x01 resolution 24] does work. might be that this problem only appears on more complex rules (I have a ruleset of around 10.000 checks running, and needed to tweek the position of highway=* quite a lot until it actually showed up. I consider the style-rules to be quite buggy therefore.
Right now I am trying to use the action rules, to generate a bicycle routing map, which uses the Garmin-Navi in car-mode, because of the better routing algorithms. Therefor I am tweeking the road classes and the access restrictions. So basically I am trying to use the action rules as a preprocessor for the OSM data.
Oh, and by the way: Would it be possible, to add support for a "txt" extension for the style files? It is quite anoying on a windows system, that you always have to choose manually the application, when you open a style file.
You can associate any program to open up files without extensions. google it. .txt would be more beginner friendly though.
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
And I think, if I would change the second line to
highway=* tag_a!=yes {set tag_b=yes}
adding in the missing '&' sign: highway=* & tag_a!=yes {set tag_b=yes} Then that is allowed, and the result would still be that all highways were 0x01.
it wouldn't change anything, or would it?
What would happen, if the second lien would be changed to the following: tag_a!=yes {set tag_a=no; set tag_b=yes}
You cannot set the same tag that you are matching. (Currently there is a bug and it will hang, but the intended result would be just that it is ignored as it is too late.) All actions will be run before the final matching rule is selected and the action rules are not run in any particular order. So anything that relies on the order of the action rules will not work reliably.
So basically I am trying to use the action rules as a preprocessor for the OSM data.
So yes, could you think of what kind of preprocessing rules you want and then we can either make the existing system do that or have a separate pre-processing phase for that. ..Steve
Steve Ratcliffe schrieb:
You cannot set the same tag that you are matching. (Currently there is a bug and it will hang, but the intended result would be just that it is ignored as it is too late.)
All actions will be run before the final matching rule is selected and the action rules are not run in any particular order. So anything that relies on the order of the action rules will not work reliably.
Ok, so I will check my style, where I have to change something according to above two rules.
So yes, could you think of what kind of preprocessing rules you want and then we can either make the existing system do that or have a separate pre-processing phase for that.
I think a defined order of the rule processing would be a nice start. But first I will try, how far I can get with the actual implementation. Once again many thanks for your work on mkgmap. Gruss Torsten
participants (4)
-
Felix Hartmann -
Richard Fairhurst -
Steve Ratcliffe -
Torsten Leistikow