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