New Topic

Locus Map - help desk Topic Idea Locus Map (Android)

This object is in archive!

Category Locus Map (Android)

Tags brouter, nogo

Comments 13

Subscribers 7

Votes 3

Honor BRouter nogo points when computing track

Andrew Heard shared this idea 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.

I like this idea 0

Replies (5)

balloni55 ●

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

URL

Andrew Heard ●

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.

URL

Libor Poutnik Striz ●

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.

URL

Andrew Heard ●

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.

URL

Menion ●

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).

URL

Andrew Heard ●

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

URL

zossebart ●

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?

URL

Menion ●

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

URL

zossebart ●

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.

URL

Menion ●

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.

URL

zossebart ●

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...

URL

zossebart ●

For a possible usecase, see for example https://phyks.me/2019/07/bicycle-routing-avoiding-road-works.html#bicycle-routing-avoiding-road-works

Looks nice, but this specific example would also need GeoJSON support in Locus, which is not supported right now, is it?

URL

Menion ●

It is not well known, but LM can! load GeoJSON files (try to put them into Locus/mapItems), but it's not well tested.

Anyway, this does not help here, because you talk about web interface, not BRouter in the Android.

As I mentioned before, understand that polygons may be useful, but it have to be defined in the UI in the app, which may be a little complicated task for now.

URL