Don't let action rule execute its actions if its type isn't going to be used
Felix, As you know, action rules execute their actions (like add tags, etc.) whenever their expression is true. But is that the right behaviour if the type associated with the rule isn't going to be used because of the continue action? I'm not sure that it is so I have made a little patch that stops action rules from executing their actions if the type to be returned isn't going to be used. I don't know if it helps with your current issue or not but perhaps you can try it out. The patch also adds back all the resolveType() methods without the pre argument so that Steve's test suite isn't borked. Mark
Mark Burton wrote:
Felix,
As you know, action rules execute their actions (like add tags, etc.) whenever their expression is true. But is that the right behaviour if the type associated with the rule isn't going to be used because of the continue action?
I'm not sure that it is so I have made a little patch that stops action rules from executing their actions if the type to be returned isn't going to be used. I don't know if it helps with your current issue or not but perhaps you can try it out.
The patch also adds back all the resolveType() methods without the pre argument so that Steve's test suite isn't borked.
Mark
Great, that is "more or less" what I need. Because you never know what simple action rules do, I have been using "continue" to add restrictions in steps. The patch would be perfect, if one could specify to have it working this way on demand only. So e.g. [... resolution=24 continue save] working like old behaviour, and [... resolution=24 continue] would drop everything added within {}. Alternatively maybe it would be easier to have [... conintue ] as before, and [... continue drop ] to specify that {...} is not saved for further ways. ... oh and just to confirm, the patch works as expected (as far as I can tell).
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann wrote:
Mark Burton wrote:
Felix,
As you know, action rules execute their actions (like add tags, etc.) whenever their expression is true. But is that the right behaviour if the type associated with the rule isn't going to be used because of the continue action?
I'm not sure that it is so I have made a little patch that stops action rules from executing their actions if the type to be returned isn't going to be used. I don't know if it helps with your current issue or not but perhaps you can try it out.
The patch also adds back all the resolveType() methods without the pre argument so that Steve's test suite isn't borked.
Mark
Great, that is "more or less" what I need. Because you never know what simple action rules do, I have been using "continue" to add restrictions in steps. The patch would be perfect, if one could specify to have it working this way on demand only. So e.g. [... resolution=24 continue save] working like old behaviour, and [... resolution=24 continue] would drop everything added within {}. Alternatively maybe it would be easier to have [... conintue ] as before, and [... continue drop ] to specify that {...} is not saved for further ways.
... oh and just to confirm, the patch works as expected (as far as I can tell).
... Ups too fast. if I use: /highway=* & copy=99 { set oneway=no } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & copy=98 { set oneway=no } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & ( copy=99 | copy=98 ) [0x02 road_class=2 road_speed=2 resolution 24] /Then it does work as expected, however Mapsource puts out error =3 when I try to route along 0x01 against 0x02 direction. If I use however the highway=* & copy=99 { set oneway=-1 } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & copy=98 { set oneway=yes } [0x01 road_class=0 road_speed=0 resolution 24 continue] /highway=* & ( copy=99 | copy=98 ) [0x02 road_class=2 road_speed=2 resolution 24]/ then oneway=-1 is also set for 0x02, instead of 0x02 being oneway=1. and vice versa. I am unable to have opposing oneways. On top of this at some places Mapsource creates an error when I route over the way (- the critical point being where ways are joined to simple oneway=no ways). Knowing that the opposite cycleways patch works great (opposing oneways) I do assume either: a) Some ways are not connected correctly, therefore the routing problems b) At least in Mapsource it is not possible to have one oneway=no (slower), and one oneway=yes with higher road_class/road_speed. If the way with oneway=yes is slower to use, no problems appear however. Opposing oneways in my eyes should be working well however (though the patch currently works for restrictions, it does not reverse a way without saving the reversing for future ways). Currently, no matter what I do, it does not really work. I can't seem to find out what is done differently compared to the opposite cycleways code, which does work very well.
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello Felix,
... Ups too fast. if I use: /highway=* & copy=99 { set oneway=no } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & copy=98 { set oneway=no } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & ( copy=99 | copy=98 ) [0x02 road_class=2 road_speed=2 resolution 24] /Then it does work as expected, however Mapsource puts out error =3 when I try to route along 0x01 against 0x02 direction.
I'm missing something here - where are you setting oneway for 0x02?
If I use however the highway=* & copy=99 { set oneway=-1 } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & copy=98 { set oneway=yes } [0x01 road_class=0 road_speed=0 resolution 24 continue] /highway=* & ( copy=99 | copy=98 ) [0x02 road_class=2 road_speed=2 resolution 24]/
then oneway=-1 is also set for 0x02, instead of 0x02 being oneway=1. and vice versa. I am unable to have opposing oneways. On top of this at some places Mapsource creates an error when I route over the way (- the critical point being where ways are joined to simple oneway=no ways).
Again, I don't see how 0x02 would be given oneway=1. I shall look again at where the way is being duplicated, I don't understand how with that patch, setting oneway=-1 in 0x01 also sets it in 0x02. Cheers, Mark
Mark Burton wrote:
Hello Felix,
... Ups too fast. if I use: /highway=* & copy=99 { set oneway=no } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & copy=98 { set oneway=no } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & ( copy=99 | copy=98 ) [0x02 road_class=2 road_speed=2 resolution 24] /Then it does work as expected, however Mapsource puts out error =3 when I try to route along 0x01 against 0x02 direction.
I'm missing something here - where are you setting oneway for 0x02?
It is already set by an action rule before.
If I use however the highway=* & copy=99 { set oneway=-1 } [0x01 road_class=0 road_speed=0 resolution 24 continue] highway=* & copy=98 { set oneway=yes } [0x01 road_class=0 road_speed=0 resolution 24 continue] /highway=* & ( copy=99 | copy=98 ) [0x02 road_class=2 road_speed=2 resolution 24]/
then oneway=-1 is also set for 0x02, instead of 0x02 being oneway=1. and vice versa. I am unable to have opposing oneways. On top of this at some places Mapsource creates an error when I route over the way (- the critical point being where ways are joined to simple oneway=no ways).
Again, I don't see how 0x02 would be given oneway=1.
As above. Set by action rule.
I shall look again at where the way is being duplicated, I don't understand how with that patch, setting oneway=-1 in 0x01 also sets it in 0x02.
okay, the problem seems to me that reversing of ways is only possible once.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix, Please try this new patch to trunk. Don't use any other of my recent style patches as it contains all the current stuff. This now suppresses action execution when looking for further matches. If you want the actions to be executed anyway, add 'with_actions' (or 'withactions', both are recognised). Also, there is a subtle change in the logic in that now if an action rule matches but otherwise would be ignored because it's not the first time through, resolveType() will return null so that if the action rule is part of a sequence (which it almost certainly is) then the rule munging engine will go on to look at the next rule in the sequence. Without that change, I think it would always choose the first rule in cases like this: foo=bah { tag=val1 } [0x01 continue] foo=bah { tag=val2 } [0x02 stop] Anyway, see what happens. Mark
2009/11/29 Mark Burton <markb@ordern.com>
Felix,
Please try this new patch to trunk. Don't use any other of my recent style patches as it contains all the current stuff.
This now suppresses action execution when looking for further matches. If you want the actions to be executed anyway, add 'with_actions' (or 'withactions', both are recognised).
Also, there is a subtle change in the logic in that now if an action rule matches but otherwise would be ignored because it's not the first time through, resolveType() will return null so that if the action rule is part of a sequence (which it almost certainly is) then the rule munging engine will go on to look at the next rule in the sequence.
Without that change, I think it would always choose the first rule in cases like this:
foo=bah { tag=val1 } [0x01 continue]
foo=bah { tag=val2 } [0x02 stop]
Yeah , this allways took a lot of smart thought to be circumvented! Now I will have to look through my lists to remove the workarounds that I have done to accomodate.
Anyway, see what happens.
Mark
Overall: Great it's the first time the patch actually seems to work as expected (as expected when looking at the result with gpsmapedit). Inside Mapsource it works 100% when not starting or ending on the street that is oneway. So if you have to route over such a stretch - it will work as expected - with different speeds depending on the dircection of travel. This is the greatest feature we have since routing was introduced!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Only if you start or end the route against the oneway of the way on the top, it might end up to route to one end of the street, and then run the opposite direction back. This is no major concern to me at all and probably simply caused by the fact that if you click somewhere it always chooses the top road, and there are no interchanging nodes so it has to route to the end of the street to change to the street that lies below. -- I did not notice any drawbacks using this patch, and it makes the "continue" command much more useful. Now we really have a unique feature. (and I have a lot of work thinking about all the great stuff I can use this for to improve routing) I think you can safely commit this! (for anyone wanting to use this like me for different speed depending of direction, now having the slower way with oneway=no also works great, I'll play around a bit to see whether two opposing oneways, or one fast oneway and slow way "without direction" works better).
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, Thanks for the report.
Overall: Great it's the first time the patch actually seems to work as expected (as expected when looking at the result with gpsmapedit). Inside Mapsource it works 100% when not starting or ending on the street that is oneway. So if you have to route over such a stretch - it will work as expected - with different speeds depending on the dircection of travel. This is the greatest feature we have since routing was introduced!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Only if you start or end the route against the oneway of the way on the top, it might end up to route to one end of the street, and then run the opposite direction back. This is no major concern to me at all and probably simply caused by the fact that if you click somewhere it always chooses the top road, and there are no interchanging nodes so it has to route to the end of the street to change to the street that lies below.
-- I did not notice any drawbacks using this patch, and it makes the "continue" command much more useful. Now we really have a unique feature. (and I have a lot of work thinking about all the great stuff I can use this for to improve routing)
Good, hopefully, that will keep you quiet for a while!
I think you can safely commit this!
OK, I'll do that soon.
(for anyone wanting to use this like me for different speed depending of direction, now having the slower way with oneway=no also works great, I'll play around a bit to see whether two opposing oneways, or one fast oneway and slow way "without direction" works better).
Cheers, Mark
On Nov 29, 2009, at 23:24, Felix Hartmann wrote:
This is the greatest feature we have since routing was introduced!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Um, I've been having some difficulty following this discussion. Would someone be so kind as to explain (perhaps with a small example) the conditions under which this patch would be useful? I'd be most interested in trying this out, if only I could understand it. ;-) Cheers.
Clinton Gladstone wrote:
On Nov 29, 2009, at 23:24, Felix Hartmann wrote:
This is the greatest feature we have since routing was introduced!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Um, I've been having some difficulty following this discussion. Would someone be so kind as to explain (perhaps with a small example) the conditions under which this patch would be useful? I'd be most interested in trying this out, if only I could understand it. ;-)
highway=* & cycleway=opposite { set oneway=-1 } [0x01 road_class=0 road_speed=0 resolution 24 continue] This example would allow you to put an opposite cycleway with your choice of speed. The current --make-opposite-cyclways however uses the same speed/road_class as the road it is on. I as a cyclist would like to avoid, but not block going against the usual flow of traffic. with the above only in case nothing else more or less is possible I would be routed against traffic direction. There can be plenty other things you could use this for (also for example setting different road_class / road_speed for one type of street depending on mode of travel by setting different restrictions). Note however that it only works 100% well, if you route over the oneway (or whatever you choose to change) street, not if you have a route ending there or starting there. That is a limitation on Garmins side however. You could also say, I as a cyclist don't respect oneway at all, so lets put oneway=yes | oneway=-1 {set oneway=no } [0x01 road_class=0 road_speed=0 resolution 24 continue] - so usually you should not be routed against oneway direction, if there is a significant shortcut you will however.
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Nov 30, 2009, at 0:15, Felix Hartmann wrote:
Um, I've been having some difficulty following this discussion. Would someone be so kind as to explain (perhaps with a small example) the conditions under which this patch would be useful? I'd be most interested in trying this out, if only I could understand it. ;-)
highway=* & cycleway=opposite { set oneway=-1 } [0x01 road_class=0 road_speed=0 resolution 24 continue]
Thanks, but what I was having trouble understanding is the stopping of actions when the type isn't going to be used. That is, where would 'with_actions' be necessary, and what is the consequence of not having this set? Cheers
Hi Clinton,
Thanks, but what I was having trouble understanding is the stopping of actions when the type isn't going to be used. That is, where would 'with_actions' be necessary, and what is the consequence of not having this set?
The problem was that the actions, e.g. { set foo='bah' }, were always being executed even if the rule ended up being skipped because it had a continue keyword and it was not the first time the rule list was being scanned (for the particular way in question that was being processed at the time). So now, the default is that the actions will be skipped if the rule doesn't get used unless you specify "with_actions". I grappled with various combinations of words to come up with something that wasn't too long that meant "do the rule's actions even though this rule is not going to supply the garmin type and/or road class/speed". I thought that was a bit long winded. So now, I think that [... continue with_actions] reads OK. Cheers, Mark
Hallo, I am glad that the continue statement finally made it into the trunk, but I am nor sure, when to use this with_actions flag and when not. And can anybody describe the difference in this regard, between the trunk and the style-branch? In my style I have the following lines in the polygon file: # set access blanking access=* & access!=yes & highway=* {set access_blanking=yes} access=* & access!=yes & railway=* {set access_blanking=yes} access=* & access!=yes & landuse=residential {set access_blanking=yes} access=* & access!=yes & landuse=industrial {set access_blanking=yes} access=* & access!=yes & leisure=garden {set access_blanking=yes} access=no & access_blanking!=yes [0x22 resolution 22 continue] access=private & access_blanking!=yes [0x22 resolution 22 continue] Now I have an example way with the follwoing tags: highway=service access=private With the style-branch the first rule is executed and the tag access_blanking=yes is added. All other rules do not match any more afterwards. With the trunk I get a polygon of the type 0x22, so obviously the first rule has no effect and the sixth rule is executed. Do I need to add here some kind of the with_actions flag, so that the example will work as expected? Or how can this be done with the actual trunk? I still haven't understood the with_actions flag completely. Can someone please provide an easy example, wich demonstrates the different results, whether the with_actions flag is used or not? Gruss Torsten
participants (4)
-
Clinton Gladstone -
Felix Hartmann -
Mark Burton -
Torsten Leistikow