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
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
