Cooperation with brouter

[Asteliks]

@organicmaps
Have you guys considered cooperating with brouter team? You've got a great app and they have a great routing algorithm for bikes. You can test it online here: https://brouter.damsy.net/

Technically they have an app but its limited to android and tbh it isn't as good as yours. It should be also pointed out that they use the MIT license which means that as long as me mention them there shouldn't be any problems with this idea.

Connected to: abrensch/brouter#360

[biodranik]

Any alternate algorithm, including brouter, in theory, can be integrated. It requires a lot of work though, especially taking into account our data format. I would start with a direct algorithms comparison first, to understand the limitations of our current engine. Based on that it will be clear, what to do next: either improve our implementation or throw it away.

I didn't take a look at brouter implementation. What is the core algorithm? Is it also a modified A*, as in Organic Maps?

[Asteliks]

I didn't take a look at brouter implementation. What is the core algorithm? Is it also a modified A*, as in Organic Maps?

TBH I don't know, but based on its routes it is quite good

[edrex]

I am trying to switch most of my usage from OSMAnd, and their usage of brouter for cycle routing (initial commit of brouter service) is the one major missing feature. It is very good, in fact the cycle routes generated by brouter in my city (Portland, OR) are usually more sensible than those from Google Maps. Currently, Organic Maps routes cycles on highways and major boulevards just like cars.

Information about brouter's algorithm: https://brouter.de/brouter/algorithm.html
brouter also mentioned here: #1201 (comment)

[edrex]

To get a feel for brouter the online interface is recommended: https://brouter.de/brouter-web/

• Especially note that a primary route and 4 alternatives are always generated.

OSMAnd's integration with brouter is kinda painful since it goes over a local http connection and requires setting profile and downloading segments in brouter then configuring in osmand.

If organicmaps integrated brouter functionality it would probably be better integrated as a library, but that would mean downloading brouter routing segments (which are 5deg * 5deg).

Somehow, it would be great to get the level of performance and functionality provided by brouter into organicmaps.

[zod]

OSMAnd's integration with brouter is kinda painful since it goes over a local http connection and requires setting profile and downloading segments in brouter then configuring in osmand.

Technically it's an android service and not http but your other remarks are true: the configuration using OsmAnd is a bit quirky. LocusMap does the profile configuration in the app itself so the BRouter app is only used for downloading segments.

If organicmaps integrated brouter functionality it would probably be better integrated as a library, but that would mean downloading brouter routing segments (which are 5deg * 5deg).

The advantage of the service is that multiple apps can use the same routing data.

[Atemu]

I think the most important feature of brouter is that it can be parameterised.

Not everyone rides the same kind of bicycle that can handle surfaces equally well and not everyone is comfortable using certain kinds of paths (i.e. roads). Brouter allows tweaking the routing parameters to fit your personal circumstances.

Parameters I think are most important:

• Kind (exclusive bicycle path, shared with pedestrians, shared with cars (high/low traffic))
• Grade
• Surface quality

If integrating brouter is technologically infeasible, exposing such high-level parameters could make most of the difference from a UX perspective IMHO.

I'm going to explain a little more why that is as it was claimed that the team does not bike very much

The tolerance for such route "problems" is different for each individual cyclist and even depends on the specific situation. Many cyclists have multiple bikes with different specialities; they may prefer muddy steep paths over roads on their mountain bike and the complete inverse on their racing bike. It can't be assumed that the same user always has the same preferences.

While it is individual, there is a rather harsh cut-off for most of these where a small diversion that does not have the "problem" is almost always better:

• If I have a low tolerance for car traffic, I really don't want to be put on a road with high speed limits
• If my gearing is made for flat cities, I really don't want to take on >5% grades for prolonged sections often
• If my wheels are extremely thin, I really don't want to take a mud path

In the perfect bicycle routing app, I'd have sliders for each of these right in the route selection screen with ranges like this:

• Kind: "I can deal with anything but a highway" to "Avoid cars at all costs"
• Grade: "I'm on an pedelec trip in the alps" to "I have a single gear"
• Surface quality: "My tires are 20cm thick" to "Even gravel would make me fall"

where the extremes would respect the boundaries with little leeway and mediums would allow for trade-offs.

[biodranik]

@Atemu thanks for sharing ideas! I like to reuse the "Avoid..." approach. Adding explicit "Avoid..." options is relatively easy to implement. So let's brainstorm the most important ones for most users.

Adding a highly customizable set of preferences has a lower priority compared to providing something very simple and yet useful for most users.

[Atemu]

An important aspect of this that I want to stress is that these limits really are quite different for every cyclist. A perfect route for one cyclist could be entirely unacceptable and potentially life-endangering for another.
Boolean values would likely not be able to capture this reality at all; there has to be more configurability than true or false. It doesn't have to be infinitely configurable, range of maybe 5 values would likely be enough.

I don't know how your "Avoid ..." implementation works but one method of implementing this that sprung to my mind would be to for the user preferences to act as a limit beyond which factors for the costs are applied. An incline intolerance setting of 6% would assign paths with >6% incline a much higher cost than regular incline cost scaling would for instance.

The intention behind this is to avoid situations where there is a much faster route which includes a small stretch of path that does not respect the user's preferences. Suggesting this path even if it technically doesn't fit the requirements in its entirety could still be helpful.