logo separator

[mkgmap-dev] Don't let action rule execute its actions if its type isn't going to be used

From Felix Hartmann extremecarver at googlemail.com on Sun Nov 29 10:51:23 GMT 2009

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 at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20091129/0410d39d/attachment.html 

More information about the mkgmap-dev mailing list