add a warning feature (e.g. ferries)

[abrensch]

When planning a route, there may be sections in the routing result that require attention (e.g. a ferry).

A new expression for the profile parser:

warn

with being displayed in the calculation summary if that expression contributed to the final routing result would by a generic way to achieve that

[zossebart]

Now that we have turninstructions, wouldn't it be possible to also insert warnings into the resulting track? Could be very helpful at e.g. railway crossings or fords.

But I guess we have the same problem here as with turninstructions: how to transfer them to map apps. And then the map apps would need a way of displaying such warnings during navigation.

Or is there any "default" turn instruction we could "misuse" for warnings?

[radim-asamm]

Hello all,

I have prototyped this feature of warnings a bit. Description of what we (Asamm Software) chosen as a general approach:

• At the moment, we consider warnings as a feature separated from routing. ("Be aware there is a ford, but that does not mean Brouter is making any attempts to avoid it, except what is configured in the profiles using well known in-build variables.")
• Routing profiles define warnings as an array of Strings - descriptive identifiers.
• When it comes to syntax, two possibilities come to mind: 1.Warnings is an expression. 2.Warnings is a specially treated variable, different from in-build variables -- an array (of String or Int, but an array anyway). In-build vars are floats and that is not convenient to use for configuration of something that is by nature a collection. I have explored both approaches but finished prototyping for the second one (assign warnings=descriptive_identifier1&descriptive_identifier2). If warnings are separated from routing, this makes more sense to me.
• There is a clear distinction between configuration part and detection part.
• Configuration is native to Brouter, common for all. (Use it or not, as you wish)
• Detection is Brouter-user-dependent. Once the route is computed, warnings are detected by examining osm tags attached to OSMPathElement. Brouter provides only "injected" interface, implementation is done by users of Brouter. Implementation can be complex, an example follows. This approach is flexible, but there is no common, universal language of identifiers and implementations. Anyway some defaults can be provided by Brouter.

A bit more of reasoning, using perhaps the most important use case for warnings: Many mountain passes, roads, e.t.c have seasonal access. There is no reason this seasonal access should affect routing as such. We just don't know if you go there now or next month. The output of such a warning detector can be as simple as "Beware, seasonal access!" (Translated by api consumers). Or the implementation can be advanced, dealing with often inconsistent osm syntax, using fairly complex parser, outputting "You can't go there today, but starting on the 1.st of May, no problem."

Thank you for your attention, if any of these ideas seems worth to follow, of course I am ready to go into details, provide some flowcharts what I have done e.t.c.

[afischerdev]

Inspired by @radim-asamm we will start with a proof of concept in my branch add-warnings. Please have a look there, the first code is arrived.