Proposed feature: warnings configured in the routing profiles

52 views
Skip to first unread message

Radim Večerek

unread,
Jan 26, 2023, 1:58:05 PM1/26/23
to OSM Android bikerouting

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

unread,
Jan 26, 2023, 2:49:08 PM1/26/23
to Radim Večerek, OSM Android bikerouting
but if yes, there are tweakbale parameters:

#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  



čt 26. 1. 2023 v 19:58 odesílatel Radim Večerek <radim....@asamm.com> napsal:
--
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.

Radim Večerek

unread,
Jan 26, 2023, 4:43:40 PM1/26/23
to OSM Android bikerouting
Unfortunately, what we want to do cannot be done using tools available now. I used SAC levels as an example, but these warnings we propose require non-trivial new feature implementation. 

Radim V

unread,
Jun 20, 2023, 4:01:44 AM6/20/23
to OSM Android bikerouting
Hello all
I have done some prototyping of this warning feature. How I approached the problem is roughly described in this comment. I am ready to start implementation and also pull requests, if desired. But before I proceed, it would be great to hear some insight/feedback from the people who know brouter. Especially because the approach chosen is slightly different (I believe more flexible), than what was suggested years ago in the previous comment.
Thank you all for your attention. Radim. 
Reply all
Reply to author
Forward
0 new messages