Nogo area permanently in Android not working

[afischerdev]

An error is reported in OSM Android bikerouting

Nogo areas defined via waypoints do not work.

Basic for test is this nogo5000_Munich.gpx.txt

BRouter-Web is working with nogo area

[afischerdev]

@abrensch I have a concept question: With commit 'bee-line patch: Nogo covering 2 Waypoints triggers a beeline segment' the function: cleanNogoList was introduced to BRouter. I guess it was to enable direct routing between two points that are inside a nogo point with radius x. Direct routing now starts with a marker on the first point.

Do you think we still need the logic to clear the nogos before routing and restore them after? If clearing is removed, we get an island error. when an incoming waypoint is in a nogo area. That's what I would expect in this use case. Or am I missing something?

Please see this route for a sample.

[devemux86]

@afischerdev there are also some answers in Cruiser Discussions:

• https://github.com/devemux86/cruiser/discussions/85#discussioncomment-5348449

[WolfgangZ42]

If waypoints are set in a nogo area consciously, they should be taken into account - according to the motto: "Trust me - I know what I am doing!" If the cleanNogoList is the right way, I don't know. I don't think we should even need the beeline function for this. Here again the comparison to "Avoid Highway", where this also works.

[afischerdev]

@devemux86 Thanks for the link, I've seen that. And I can follow your samples, see it in the same way.

For a situation with a start point outside, a via point inside and a target point outside - or more of them -, the plan is to ignore the via point and generate a route around the nogo area.

[devemux86]

For a situation with a start point outside, a via point inside and a target point outside - or more of them -, the plan is to ignore the via point and generate a route around the nogo area.

So nogo areas have priority over waypoints. Nogo areas are similar to lakes, we can set waypoints in them, but not expect routing to work in them.

Such cases will need the beeline profile to cross them or the routing will go around them.

[nrenner]

Nogo areas can also be assigned a weight, so ways inside are considered for routing with an additional cost (default -1 excludes from routing), see:

• 117

For example with a fourth weight parameter of 1, the route enters the area at some points: https://brouter.de/brouter-web/#map=13/48.1539/11.5833/standard&lonlats=11.593082,48.085009;11.565511,48.191278&nogos=11.567093,48.141441,5000,1

[afischerdev]

@nrenner Thanks for the pointer. And yes this is a little bit out of focus. The discussion was about file import for nogos. This doesn't have a weight info. May be it should have also a weight. No idea how at the moment.

Here are some results from the new lib: Red = nogos=11.567093,48.141441,5000 Blue = nogos=11.567093,48.141441,5000,1 Green = nogos=11.567093,48.141441,5000,0 Looks pretty similar.

117 means to me we have not a strict nogo area, when it has a weight it is an area with extra penalty.

But that also means I would take the route with less cost. In this case the route should go through the area and not around or nearly around.

Anyway, the weight should be taken into account if wpts are excluded.