Offline-Router Interface?

[Arndt]

Hi,

I'm currently working on an OSM-offline (bicycle-) router for android, with some success.

It's by now the only long-distance router I know to run offline on the phone, and it's,
to my knowledge, the only bicycle router (including the online services) that considers
elevation in a senseful manner.

And it's fun cycling these routes, and I do that with OsmAnd following GPX-Tracks.

In the current setup, I made a file-based poor-mans interface to OsmAnd - reading the favorites-file
to pick start/end of the route to calculate, and writing the result into the tracks-directory.

That works, but, however, I would really like to have a tighter integration and replace
the build-in offline router by this external offline router - especially to be able to do
dynamic recalculations in case the track ist lost.

Any Idee how to do that? Any plans to define an offline routing interface? Bundling
my router with osmand could also be an option, but I need the full 10MB of memory
that an app can use and resource-concurrency with the renderer could become a nightmare.

thanks for your thoughts,

Arndt

[Sabra Sharaya]

It was suggested that the only difference between (fastest route) and (shortest route) is the set of parameters passed to the routing algorithm. I believe this applies to bicycling too.That is, optimizing for motors, pedestrians, and bicycles only requires one algorithm. The difference is, which ways are given priority. So the only change necessary would be to give priority to paths suited for a bicycle rather than a car.

[Pavol Zibrita]

Hi!

  I think such 'interface' or method to include also external routers might be possible. I don't know how,

probably creating and finding possible services for a routing specific intent. So the settings would look

up all available routers that user can choose, and than it will start the service and use it. I think this is

possible also to be an external service, if the intent is defined exchangeable. Probably. Do yo have already

some code for your router? Or, if I understand, it is a separate app on Android? Or an external service?

Best regards,

Pavol

[Arndt]

Hi Pavol,

yes, my current setup is a separate app. Basically, it's a java-command line tool with a very thin "app-wrapper" that does the file-interfacing with OsmAnd, show's a graphical animation of the processing and some "Toasts" with distance and elevation information. But no interactive graphical interface. And there's another java-command-line tool to process Osm-maps into preprocessed routing files (one per square-degree, about 10 MB).

Focus is good bike routing, with real elevation awareness and without zig-zagging through residential areas. What openrouteservice does with option "preferred cycle ways" comes close, but when it comes to elevation, also this one does a poor job. And also for the online interface to openrouteservice, selecting", preferred cycle ways isn't possible, since the configuration is restricted to shortest/fastest.

My implemenation is not so far, but conceptionally what this app needs is a fine-granular configuration to configure the penalties for elevation, car-traffic, steps, wrong one-ways etc individually, so it cannot be forced into the car/bike/foot+short/fast scheme.

I agree that defining an "standard-routing-interface" should by online and offline, so maybe it could just be an "online" interface that can be configured with a "localhost" adress?

best regards, Arndt

[Arndt]

On Tuesday, September 4, 2012 4:24:10 PM UTC+2, Arndt wrote:

I agree that defining an "standard-routing-interface" should by online and offline, so maybe it could just be an "online" interface that can be configured with a "localhost" adress?

best regards, Arndt

 
I would like to come back to that topic. For my offline router I implemented such a "local HTTP" interface, and it work's o.k (siee http://brensche.de/brouter/revsions.html) , but obviously that's not the way to go.

One problem is that Androids process lifecycle management does not guarantee a service to keep running, if  no active activity ha bound to that service, so Android is allowed to shutdown my service anytime.

Other problem is that there's not enough information in the interface. For the input parameters I think the moving direction is missing, and for the output data I think that OsmAnd is able to use more information from the routing service to calculate the voice navigation messages, but currently I'm not able to propagate this information.

Are there any resources/existing concepts/discussed designs for a more powerful offline interface?

 thanks, regards, Arndt

[Victor Shcherb]

Why do you think that service level integration is wrong?

Offline Routing should not be live, it is just one time operation. I think initial approach could be the same as for online routing, if you think Android compatible and right solution, then I would suggest aidl approach. http://developer.android.com/guide/components/aidl.html you can make pull request for new offline routing and I see no reason why it should not work.

Victor

--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Arndt]

On Sunday, June 2, 2013 8:57:55 PM UTC+2, V S wrote:

Why do you think that service level integration is wrong?

Hi Victor,

In my current setup the two main problems are not enough control on service lifecycle (Android allowed to shut it down) and that I need full internet permission though it's just an offline app with a TCP/IP Listening port.

 
> if you think Android compatible and right solution, then I would suggest aidl approach. http://developer.android.com/guide/components/aidl.html you can make pull request for new offline routing and I see no reason why it should not work.

Yes or maybe the simpler concepts also mentioned in this article (bound service or messenging service), something like that, I have a slow learning curve for the Android programming model but will come back to that.

Unfortunatly, it's not just a stateless service but needs additional configuration (so interact also with a configuration activity) and some sort of session state, e.g. to be able to do fast partial recalucations.
 
regards, Arndt

[Victor Shcherb]

Internally OsmAnd using the same concept of almost stateless background. And of course to use something natively there is no need to have TCP.

For simple queries aidl is not necessary, it could be done via Intents and serialized data in Intent extra, which I think is worth to try. 

State of the service is presumed between calls.

Victor

[Arndt]

On Sunday, June 2, 2013 8:57:55 PM UTC+2, V S wrote:

if you think Android compatible and right solution, then I would suggest aidl approach. http://developer.android.com/guide/components/aidl.html you can make pull request for new offline routing and I see no reason why it should not work.

Meanwhile I created an aidl-interface to BRouter - it's part of version 0.9.3 ( see http://brensche.de/brouter/revisions.html and the aidl.definition file within the 0.9.3 zip ). There's still a minor bug in error handling (producing an exception instead of an error message in case no track could be found - will fix that in the next version.

The service is fully stateless - so it doesn't matter whether you bind to the service per call or per "session". It get's some extra configuration for the requested routing mode (foot/bike/car/short/fast) including the routing profile to use and the list of nogo-areas.

Personally, I'm still using it with OsmAnd via an "HTTP-bridging-app", because I still didn't succeed to build OsmAnd from source in order to create a pull request. The AIDL-Service itself is working absolutly stable.

I would love to get that working with OsmAnd.

Still some features missing. Fast partial recalculations are top on the list. For best location matching on motorways I would need the driving direction in the input parameters. Car routing still doesn't have turn-restrictions. And especialy for long-distance car routing there's a memory issue, but this could be easily solved by preparing car-routing specific data-files not containing the non-routable paths.

regards, Arndt

[Harry van der Wolf]

Hi,

 

I downloaded your brouter and according to the readme.txt I need to download segments as well.

I live in Nederland and to test in (entire) Nederland I need to cover from 2 E to 7.5 E, and from 49N to 54N

This means that I need to download the following segments:

E0 N45.rd5 (130M)

E0 N50.rd5 (96M)

E5 N45.rd5 (287M)

E5 N50.rd5 (247M)

 

This means that I need, next to the 540M Dutch OsmAnd map, another 760MB of segment data.

I understand that it calculates routes and store these as gpx files in the map tool folder, /osmand/tracks in this case.

But Osmand can do that as well.

 

To test I downloaded one segment. For short distances <20km it is comparable in speed with OsmAnd.

Over long distances >100 km, it's very slow (and OsmAnd is not that fast either, but much faster then Brouter).

 

Can you please explain what the added value is of your Brouter application?

 

I don't mean this as criticism, but I currently don't see what Brouter brings us extra.

So please explain (and promote your app?)

 

(And by the way: As that long address to download references from, is hard to type on your phone I shortened it to http://goo.gl/qGLryq)

 

Harry

 

 

[Victor Shcherb]

The brouter has a different algorithm, uses height profile?, something else. 

But again for user it will be always a hard choice to download so much data and as an application we can't afford having duplicated data.

The answer we are fine to have as many router algorithms as possible, but they should work with OsmAnd data.

Victor

 

 

--

[Arndt]

On Friday, August 9, 2013 3:19:22 PM UTC+2, Harry van der Wolf wrote:

 

To test I downloaded one segment. For short distances <20km it is comparable in speed with OsmAnd.

Over long distances >100 km, it's very slow (and OsmAnd is not that fast either, but much faster then Brouter).

 

Can you please explain what the added value is of your Brouter application?

 

I don't mean this as criticism, but I currently don't see what Brouter brings us extra.

So please explain (and promote your app?)

Hi Harry,

thanks for your thoughts and testing.

well, I do not advertivse BRouter for car-routing, because this has not (yet) catched attention. But for your speed comparison, to be fair you would have to compare precise-routing to  precise-routing. BRouter always does precice routing, but in in app-animation you can see what "non-precise" or "heuristic coefficent" means, because BRouter does it as well as the first and second pass in the routing process just to get an upper cost estimate: if the "heuristic coefficent" that gives you a strong "attraction" of the routing destination is large enough, you get a linear scaling with distance.

What BRouter can do is (non-CH) precise-routing over long distances withing reliable memory limits. That's not really true now for car routing because  it's caching algorithm assumes that most of the ways are routable. So to get serious on car routing, you would have to use a reduces network not containing the non-routable paths, which simultabously gives you a speed boost of a factor of something.

Such "medium speed" non-CH precice routing together with a "smart partial recalculation" would be a usable solution for car routing. No need for CH here, and you keep all the flexibility in routing configuration (and especialy in handling no-go areas)

Regards, Arndt
 

 

[Arndt]

Am Sonntag, 2. Juni 2013 20:57:55 UTC+2 schrieb V S:

 

Why do you think that service level integration is wrong?

Offline Routing should not be live, it is just one time operation. I think initial approach could be the same as for online routing, if you think Android compatible and right solution, then I would suggest aidl approach. http://developer.android.com/guide/components/aidl.html you can make pull request for new offline routing and I see no reason why it should not work.

Victor

 
Hi Victor,

I created a pull request on GitHub for the interfacing to my offline router ("BRouter")

This is cool stuff and works great. Bike routing for medium distances ( <30km air distance in osm-dense regions like germany), just works as designed, with reasonably fast (and correct!) recalculations. If the router does not succeed to find a (precice) result within 60 seconds, you get a timeout message, buit this can only happen at the initial calculation for a destination - recalculations do not time out. And I also implemented a long distance solution - you precalculate a long distance route (up to several hundreds km) in the brouter app and then in OsmAnd just say "navigate to" to this same destination and it works perfect with correct recalculations.

This is precise bike routing with elevation awareness, nogo-aereas etc. for long distances without memory issues - though of course the installation is still complicated, the documentaion poor and english only - but I think hard-core bikers will love to use BRouter tightly integrated into OsmAnd - so thank's in advance for merging my pull-request.

Arndt

PS: though the current revision 0.95 is fully functional with that interface, better wait for 0.96 this weekend with some bug-fixes and (hopefully) more doku.

[Michael Alt]

Hi Arndt,

I'm developing a maptool for cycling, I called it GpsTicker2, it's on Google Play.

I have integrated your aidl-interface to test offline routing and it works fine.

On your webpage you write 

This beta-version of the BRouter Android App will expire on August 13, 2014 and show an annoying warning on that 100 days before.

What is the behaviour of the aidl-interface after this date, will it work further more?

One further question: Must Osmand or Locus or oruxmaps be installed, when I only want to use the aidl-interface?

Regards Michael 

[Arndt]

Hi Michael,

Am Donnerstag, 14. November 2013 18:50:49 UTC+1 schrieb Michael Alt:

"This beta-version of the BRouter Android App will expire on August 13, 2014 and show an annoying warning on that 100 days before."

What is the behaviour of the aidl-interface after this date, will it work further more?

yes.
 

One further question: Must Osmand or Locus or oruxmaps be installed, when I only want to use the aidl-interface?

yes I think you will not be able to configure the service-modes if no "Coordinate-Source" is found, and this is hard-coded to the waypoint-databases of osmand, locus and orux. If you have such a concept in your tool (named waypoints stored in a file (sqllite/ xml / or whatever ) accessible on the sc-card ) I can add a "coordinate reader" for that tool.

On the other hand, I am working on a "foolproof installer app"  that assists downloading the data files and pre-configures a standard-mapping for the service-modes, so when this is available, you can install a working service via click&pray on google-play, without a need for another maptool installed.

However, you will still miss some advanced feautures like long-distance-calculations, alternatives, nogo-areas, reconfiguring service modes etc.

regards, Arndt

[Michael Alt]

Hi Arndt,

I'm looking forward to your "foolproof installer app", it's exactly as I had imagened. 

In the meantime I will continue testing and get more familiar with BRouter modes and profiles.

BRouter bycicle routes are similar to google routes with 'car avoid highway'.

Google bycicle routing preferred paths, which are not allowed for cars.

Perhaps it would be useful to have an option 'avoid streets' for bycicle routing.

regard, Michael

[Arndt]

Am Freitag, 25. Oktober 2013 20:15:18 UTC+2 schrieb Arndt:

 I created a pull request on GitHub for the interfacing to my offline router ("BRouter")

Thanks Victor for merging (and even refactoring) that patch.

I tested with Nightly and it works great except for a liite bug in the configuration menu that can be confusing if you are not aware of:

it seems that when entering the "Navigition" submenu (in order to change the routing service for a transport-mode), the transport-mode selection seems not to work, but the pre-selection keep beeing effective. You can workaround that problem be cahning the default-transport mode.

You can check that BRouter service is active (instead of OsmAnd internal offline routing) by checking the distance message after calculating a route: OsmAnd internal gives you the travel time, BRouter does not.

[Arndt]

Am Donnerstag, 14. November 2013 19:25:16 UTC+1 schrieb Arndt:

 

On the other hand, I am working on a "foolproof installer app"  that assists downloading the data files and pre-configures a standard-mapping for the service-modes, so when this is available, you can install a working service via click&pray on google-play, without a need for another maptool installed.

I uploaded BRouter to Google-Play now with more or less this click&pray behaviour, so there's a preconfigured mode-mapping and a download-manager to assist downloading the routing data files.

So it's getting easier to try BRouter for biking with OsmAnd. Please remember that OsmAnd in it's actual version (not yet in the Google-Play Version, 1.6.5) will offer BRouter as a navigation service if it is installed. The easiest way to verfify that it's BRouter calculating your routes is to look (or listen) for travel time calculations: OsmAnd-offline does deliver travel-times, BRouter does not.

Please note the in the pre-configured mode-mapping, "bicycle-short" is mapped to the "trekking" profile, "bicycle-fast" to the "fastbike" profile.
 
regards, Arndt