BRouter Version 0.9.4 +

[tommi]

"while the service interface is usually accessed by just choosing one o the 6 "standard routing modes" made of a combination of the car/bike/foot and the shortest/fastest selection."

Locus use these parameters, so just "car/fastest", "car/shortest", etc ... but which profile BRouter map to these Locus requests is mystery for me and it's probably described in article you mentioned, but I'm not much clever from it ...

Call brouter standalone and it will first prompt you to select a routing profile (e.g. choose fastbike), in the next step select Server-Mode and finally accept bicycle_short and bicycle_fast.
This should map bicycle_short and bicycle_fast (modes in Locus) to the profile fastbike (profile of brouter).
But somehow this doesn't seem to be fully functional - or I don't fully understand it

Do you know when Arndt will be back?

edit:
Seems that bicycle fast, bicycle short and foot work but car modes don't work.
Where does the text "moto_car" come from? Yes, I mean exactly the bad spelling which should obviously be "motor_car"!

[michaelbechtold]

All three modes documented above do work for me - however, bicycles and walkers are all sent to use HIGHWAYS ...
As Menion confirms he relays the selected mode to brouter via API, this should be a brouter problem then. I will try to report it to brouter support.

[abrensch]

Seems that bicycle fast, bicycle short and foot work but car modes don't work.
Where does the text "moto_car" come from? Yes, I mean exactly the bad spelling which should obviously be "motor_car"!

Hi,

yes, you're right, there's a spelling-bug, it should be "motorcar", not "motocar". This is sent by locus.

The bike and foot-modes work fine for me as well, thanx Menion for putting that in.

However, there seems to be some confusion on the mechanism I'm using to handle the configuration. I could have made the quick-start easier by deploying a standard-mapping, but I decided not to do that because this flexibility in configuration is a main feature of brouter so it's important to realize that there is a mapping and that there is more configuration on the brouter side.

An important thing to notice is that also a list of nogo-points is part of that configuration. So if, before pressing the "server-mode" button, you confirmed one or more nogo-points, they will become part of the routing-modes you select in the next screen.

[menion]

ah "motocar" fixed, thanks

[gynta]

An important thing to notice is that also a list of nogo-points is part of that configuration. So if, before pressing the "server-mode" button, you confirmed one or more nogo-points, they will become part of the routing-modes you select in the next screen.

good point...

[michaelbechtold]

Not sure if somebody reported already that 60000 ms (1s) are a too short timeout for brouter.
Just tried with a route from Frankfurt to Praha -> Locus timeout ...

Maybe you could make it a something like: timeout = (geo distance) * (configurable factor)

All this is brand new, and nobody knows yet, so this would allow to gain experience.

[menion]

it!s on BRouter side, in locus is no timeout

[abrensch]

Not sure if somebody reported already that 60000 ms (1s) are a too short timeout for brouter.
Just tried with a route from Frankfurt to Praha -> Locus timeout ...

Maybe you could make it a something like: timeout = (geo distance) * (configurable factor)

The timeout is important to protect the device. 60 seconds is the default, but there's a parameter in the aidl-interface, so it can be changed from outside.

However, the long-distance solution I am working on is "fast-partial-recalculation": the idea is that if a route to the same destination-point and for the same routing-profile is already known, a partial recalculation is done and the result is a combination of the old and the new calculation. This way you can do a long-distance calculation by starting the brouter-app, but then have fast recalulations if you follow the route and get off the track.

[jusc]

Because of this answer http://forum.locusmap.eu/index.php?topic=3423.msg24312#msg24312 I want to ask the developer of BRouter, if he would place this neccessary app to ggogle play? 

[michaelbechtold]

Well, one more question then: does brouter have a notion of highways ? So this partitioning would be INSIDE your app, not manual ! I.e. first search highway connections only near to start and end points, then get from those points to/from the valid entries to the highway system. Do not mind about "optimal" connections - this is an NP-complete problem beyond reach on smartphones ... ? By above searchtimes will really collapse automatically. For motorcar search.

And for bicycle and foot path search, such single long distance searches do not make sense anyway (and you do not need to optimize for irrelevant use cases). For motorcar, the relevance is obvious. though.
TXs
Michael

Not sure if somebody reported already that 60000 ms (1s) are a too short timeout for brouter.
Just tried with a route from Frankfurt to Praha -> Locus timeout ...

Maybe you could make it a something like: timeout = (geo distance) * (configurable factor)

The timeout is important to protect the device. 60 seconds is the default, but there's a parameter in the aidl-interface, so it can be changed from outside.

However, the long-distance solution I am working on is "fast-partial-recalculation": the idea is that if a route to the same destination-point and for the same routing-profile is already known, a partial recalculation is done and the result is a combination of the old and the new calculation. This way you can do a long-distance calculation by starting the brouter-app, but then have fast recalulations if you follow the route and get off the track.

[KaHeMu]

...

And for bicycle and foot path search, such single long distance searches do not make sense anyway (and you do not need to optimize for irrelevant use cases). For motorcar, the relevance is obvious. though.
TXs
Michael

This applies only for that people they aren't moving without a car. For car navigation there are special apps or devices to do very good job.
But there are many people outside which are moving by foot or by bike, often for long distances (>200 kms).

Just my 2 pence,
KaHeMu

[michaelbechtold]

I go by all three ;-)
My failed situation was > 500 km, and in all fairness, neither walking nor bicycle will allow 500 km IN ONE GO.
Even 200 km is pretty extreme for both, again, without a "via" target. You would typically target some place in between, right ? Drink, food ?
While for car, going to a place 100s of km away where you need directions is not unusual.
There are workarounds, yes. But why not have a proper solution rather than a workaround.
And why using yet another app in addition when it can be in one solution (Locus+brouter) ?
Cheers
Michael

...

And for bicycle and foot path search, such single long distance searches do not make sense anyway (and you do not need to optimize for irrelevant use cases). For motorcar, the relevance is obvious. though.
TXs
Michael

This applies only for that people they aren't moving without a car. For car navigation there are special apps or devices to do very good job.
But there are many people outside which are moving by foot or by bike, often for long distances (>200 kms).

Just my 2 pence,
KaHeMu

[KaHeMu]

Normally you're right. But next year I'll do a very long hike (about 2000 kms) and first I have to do is looking for a good and interesting way with some fix points for sightseeing or another things. The breaks or accommodation places I'll see from day to day.
Looking for the generally trek is a job where brouter and locus could help.

Kind regards,
KaHeMu

[michaelbechtold]

WOOOWWWW !
You set the bar high for brenche ;-) !!

Normally you're right. But next year I'll do a very long hike (about 2000 kms) and first I have to do is looking for a good and interesting way with some fix points for sightseeing or another things. The breaks or accommodation places I'll see from day to day.
Looking for the generally trek is a job where brouter and locus could help.

Kind regards,
KaHeMu

[abrensch]

However, the long-distance solution I am working on is "fast-partial-recalculation": the idea is that if a route to the same destination-point and for the same routing-profile is already known, a partial recalculation is done and the result is a combination of the old and the new calculation. This way you can do a long-distance calculation by starting the brouter-app, but then have fast recalculations if you follow the route and get off the track.

Today I deployed version 0.95 of BRouter ( see http://brensche.de/brouter/revisions.html ) which contains basically this mechanism.

I also did some "hard-work" to improve the basic performance, but this is less than a factor of 2. And I supplied "car-subset" datafiles that allows somewhat longer distances for car-routing.

But the major improvement is this recalculation stuff. I do not anymore call it "fast-partial-recalculation", now I call it "timeout-free recalculations": if you already have calculated a valid track for the same destination and the same routing mode (via the brouter-app or the service-interface), then the next calculation via the service interface for that destination will almost never give a timeout, but, if it does not succeed to finish the full calculation, give you a merged track from the old valid track and the new, partial calculation.

There's no change in the user interface. Just be aware that, when pressing the "Server-Mode" button after you calculated a track using the brouter-app, you do not only store the profile and the nogo-list for use by the service-interface, but also the track itself to be re-used by the service-interface.