Honor BRouter nogo points when computing track

Andrew Heard shared this idea 2 years ago
Completed

If I use the external BRouter from/ via(n)/ nogo(m)/ to method of calculating a track, BRouter of course takes account of all selected via(n)/ nogo(m) user defined points. Nogo points are very useful for preventing travel through a tunnel or unforeseen detours around a road block.

At present the Locus internal "Navigate To", route planner, and track editor, all ignore any user defined nogo points.

If possible, please pass *visible* nogo points onto the BRouter engine.

Comments (11)

photo
1

Hello Andrew

perhaps i missunderstood your idea

< At present the Locus internal "Navigate To", route planner, and track editor, all ignore any user defined nogo points.>

for me it work with "NavigateTo" as well as "Route&measure"

Wolfgang

beef0395eef8305894ed8ff1db8d6ae1

photo
1

Thanks Wolfgang. You are entirely correct, as usual. I'm not sure why they appeared to be ignored the other day, but are certainly working now.

photo
1

It may interfere with BRouter nogo check marks during BRouter manual internal mapping of transportation mode vs profile ( car/bike/foot short/fast ). Each of these modes has independent settings what nogo points are active. That makes sense as they can differ in nogo criterias.


OTOH, I am not sure what happens, if the Locus built-in BRouter profiles are used directly , passed to BRouter as external profiles. It may happen, if the profile matches the one included in the mode mapping files, its set of active nogos is used.

Or, perhaps all nogos may be ignored. There is need to check.

photo
1

I thought the other day Locus was ignoring nogo's but after retesting after Wolfgang's comments it seems ok. I only use the external BRouter profiles.

photo
1

Hi guys,

not sure what to do with this "idea". Probably mark it as "completed", because user needs were satisfied here :).

Maybe time of direct support for nogo areas will come ... (soon).

photo
1

Yes, completed. Internal support for nogo's would be good too. They can be very useful.

photo
1

Hey Menion,

with the release of brouter 1.5.x, it now supports nogo areas (polygons) as well as weighted nogos (as far as I understand it from looking at the commits). It would be really nice if Locus could support this functionality!

Should I open a seperate idea for this?

photo
1

Hard to say. What are "weighted" nogos? And polygons? Hm, can't imagine now some simple tools/screen how to draw them.

photo
1

I think "weighted" means that you can give them lower than 100% "nogo-value". So under certain circumstances, brouter would route through them despite of the nogo (although with high penalty). But that's just my interpretation of the word "weighted". I have not tried it yet.

For polygons: maybe allow the selection of (closed) tracks already in the database to be used as nogo areas? Brouter-web also seems to have no way to draw them yet, you can only upload a "nogo file" (geojson?) there.

photo
1

Oki, thanks for the explanation.

My personal opinion is that both features are just "too much". Some weights on No-go points, should this be really useful? Same with polygons. I use No-go points during rides and to be true, I never had a need to define a bigger area than a simple circle. Give it some time, maybe this need comes.

photo
1

I can imagine some would like to import nature-reserve or road construction areas and use them as nogo polygons to avoid them, as these kind of nogos are not easily creatable with circles.

For the weight I also see no use out of my mind, but from your point of view, it's just one additional parameter you would have to give to brouter I think, so I suggest it would be no big deal to implement. Maybe some sort of visual representation of the weight would be nice, though...

photo