Proposed feature: warnings configured in the routing profiles
Radim Večerek
Hello all,
We in Asamm Software have been using a slightly modified version of Brouter in both Android and web versions of Locus Map for some time. There is one feature we've missed since the very beginning:
WARNINGS
Here are some examples where the proposed feature is needed:
There’s a routing profile named "Walking" with an icon of a casually walking person. If this profile is used in mountainous terrain, it gives a considerable penalty to ways marked with higher SAC levels, so the "easy" route is preferred where possible, as expected. BUT if there is no "easy" route, (like e.g. a route to a summit), there are currently two options: either act like "there is no way for you", or "just use the hard, dangerous route to the summit, there is no other route anyway".
A cycling profile allows passing a one-way street in the opposite, wrong direction (one can push the bike for a short distance instead of cycling miles of a detour).
Cycling vs steps - to carry a bicycle is no big deal, unless it is a loaded touring bike.
Road cycling vs abandoned roads.
Many means of transport vs ferries.
e.t.c
We would like to build a feature that issues warnings, configured by routing profiles, using messages defined by routing profiles. Messages would be interpreted by clients (the clients may be translating messages into meaningful text warnings displayed on hover, e.t.c.).
The rough idea of such a configuration:
---context:way
# simple case
# tree-like structure of message
assign warning_message = if (sac_scale=mountain_hiking) then walking:sac:t2
assign warning_message = if (highway=steps) then cycling:steps
# more complex case
# also consider using new parser plugin for strict no-go at the moment
# access:conditional=no @ (Nov 01-Jun 14)
# some parser ‘plugin’ class is needed
assign warning_message = if (access:conditional=) then access:not_now
---context:node
# maybe
How we think this could be implemented:
To us this looks like an introduction of another build-in variable (in BExpressionContextWay) is the way to go. We cannot quickly figure out the exact mechanism of how osm key=value pairs are are used in the gradual build of OsmTrack, so guidance is welcome.
We believe this feature should be not too hard to implement (except for the parser ‘plugin’ scenario) , yet some guidance by Brouter authors would be greatly appreciated.
Thanks for your attention. Radim, backend developer
Poutnik Fornntp
#SAC - mountain hiking - see http://wiki.openstreetmap.org/wiki/Key:sac_scale assign SAC_scale_limit 3 # 0..6, 0 to avoid any SAC paths, 1 for T1 as maximum, 6 for T6 as maximum # all paths with sac_scale higher than SAC_scale_limit are forbidden. assign SAC_scale_preferred 1 # The same, but the preferred SAC scale level. Level below are slightly, above strongly penalized assign SAC_access_penalty 9000 # 1 m like 9 km of normal roas. A costfactors <9999 means the most horrible but allowed road. # Such a road is taken as the last and the only option. # CF=9999+ means a forbidden road, but if equal to 9999, navigation hints considered. # assign SAC_K1 0.05 # Penalizing of SAC levels below preferred assign SAC_K2 0.6 # Penalizing of SAC levels above preferred
--
You received this message because you are subscribed to the Google Groups "OSM Android bikerouting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osm-android-biker...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osm-android-bikerouting/ae043643-a72c-49d7-a400-41798a3d20e3n%40googlegroups.com.
