Offline navigation - GraphHopper - preparation

[silvermapper]

Moving england.osm-gh out of england-gh and deleting england-gh folder as in screenshot attached makes no difference.  I powered off the 'phone, too, and cleared the cache, just in case.

[gynta]

What happens when you tap the Locus GraphHopper AddOn App on the homescreen?

[silvermapper]

See attachment.  Tapping 'england.osm' displays another 'england.osm', nothing more.  Should it?

[gynta]

that's ok.
hm, for now - i have no more ideas.
maybe a logfile helps:
http://docs.locusmap.eu/doku.php?id=manual:faq:issue_reporting
http://docs.locusmap.eu/doku.php?id=manual:faq:how_to_create_debug_log

[silvermapper]

gynta
What a shame!  I thank you for your efforts.  Meanwhile I shall attend to the log files.

edit
gynta
Would you believe it?  I was repeating the action that caused the "Unfortunately, Locus Pro has stopped." message, in order to create a logfile.  It did not appear.  I checked that GraphHopper was the selected router and yes, it was!  I have chosen a destination and it works!  Let's celebrate (while keeping fingers crossed)!
What I love is that requesting a short route by foot from my home, most routing applications will insist upon taking a nearby road instead of footpaths where available.  GraphHopper has been the first I have experienced to take the same route as I would and has done so in several other cases to date, too.  That is why I am an advocate of it.

[gynta]

Would you believe it?... while keeping fingers crossed

Yes ... me too.

[karussell]

Hi together,

author of GraphHopper here. I really need to read through this whole thread here now, but first of all: thanks to @menion for making this happen and for the others that you provided feedback etc!

Now regarding some points:
* indeed offline was not the main focus for me but this does not mean that you should not focus on it
* offline maps generation should be updated more often, more areas? I still cannot promise something here, sorry
* more profiles, different vehicles: we are working on this. E.g. more profiles are now possible with the speed-mode in a dev branch

@menion is your work open source or how others usually contribute to this? Regarding the some technically points: Do you start a web server on the device to serve JSON or how does this work?

I would really like to see this add-on for a broader audience, even more integrated and easier to setup. We've an Android demo which e.g. allows one to easily download certain maps, see the apk here: https://graphhopper.com/#community

How else do you think could we improve the installation procedure? And what are the 3 main pain points for you or most wanted features?

Regards,
Peter

[Menion]

Hello Peter,

nice to have you here too . Welcome.

Whole add-on for Locus is made in little bit different way. Imagine it as a standalone application, but binded over Android service directly into Locus system.

Add-on has public code here: https://bitbucket.org/asamm/locus-map-add-on-graphhopper, I've just committed latest changes so code is actual.

Currently no-one contribute here, mainly because it is not needed at all. Add-on itself do not do any hard work. Locus just bind to this add-on, send required parameters and wait for computed tracks. Check mainly RoutingSevice class where all hard work is done.

So no online usage, no web server, just an Android system of communication. Even with this system, add-on is independent on Locus and different apps may use it also in case, they will communicate with this add-on with defined methods.

Installation here also won't be a problem. Once we (team behind Locus) and You decide, that GraphHopper is mature enough, to publish it as regular app on Google Play, we will do it. Users will then need only to download it from GP. Data will be available over existing Locus Store directly in application, so no problem with installation.

Anyway 3 main pain points I have -
1. due to lack of deep programming skills, my major problem is compiling of add-on . Currently when I execute build in gradle, I get below error I'm unable to solve. Some problem on my side, I know, but why when all other tasks works? Sometimes for unknown reason I have problems with error due to dependency on slfj library, usually I'm also not able to find a place where to download working jar file and so on. Some funny problems for skilled developer, but small private nightmares for me

Error:Execution failed for task ':addonGraphHopper:preDexAddonGraphHopperDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

Anyway back to GraphHopper. Just a few days ago, I was on 4 days trip on motorcycle. From Prague to Austria and back, all together around 1500 km and all only with GraphHopper. It works, it is fast and usable, nice. With roundabouts it finally make sense even for moto/car.

Anyway two major problems -
2. too much navigation commands ... usually I get huge list of commands, when most of them are "straight". I also discovered before in Czech, then when main road (primary) turns left and secondary road continue straight, GraphHopper did not notify to turn left. Not sure if it happen on all places, but at least twice it happen to me. And in Czech, difference between primary and secondary round between villages is sometimes un-noticable

3. inability to route over more files - I have to use Locus tool "add new route" and plan with one file from Prague to border with Germany, then switch data file, plan over Germany, then switch data file to Austria and plan to target. Quite complicated and it also disable possibility to "auto-recalculate".

4. one last big issue for me as user - I had to generate special data file with type=motorcycle, because I wanted to disable planning on highways and I do not found this directly over GHRequest class as it seems, supported roads are hardCoded in FlagEncoder right? I see here solution by creating own FlagEncoder with possibility to dynamically enable/disable certain osm tags.

Sorry for a longer post, but ... you asked .

Good luck with you work and wish your head, many good ideas!

[tommi]

Hello Peter,
as experienced user of Locus and especially it's "inherited" routing and navigation capabilities I observed few mistakes/obstacles as well.
I could summarize them by my own but there is already a quite accurate description here:
https://github.com/graphhopper/graphhopper/issues/94 comment of jansoe on 6 Feb 2015.
Thanks for this great project!

[Menion]

Ah nice report from jansoe. Thanks tommi, this cover my very inaccurately wrote issue 2.

[karussell]

Hmmh, someone moved too many replies into a separate thread. Here is the link for reference: http://forum.locusmap.eu/index.php?topic=4742.0

[ringen00]

Locus force closes when using GH (0.1.7) for navigation.
Tried the newest data also!
OPO CM11

[Bucky Kid]

Locus force closes when using GH (0.1.7) for navigation.
Tried the newest data also!
OPO CM11

That's right, latest add-on doesn't work with data generated by new graphopper version (independent on flags used to compile). Hopefully menion updates the addon soon.

[karussell]

> Locus force closes when using GH (0.1.7) for navigation.

It is important that you create the data with the same GraphHopper version that is used for the locus add-on.

GraphHopper 0.5 released a few days ago and this is incompatible with older versions. You should try to switch to the 0.4 branch to create data for the locus add-on I guess, or update the add on to the latest version (it is open source too).

Try:

Code Select Expand


git checkout 0.4
./graphhopper.sh clean
./graphhopper.sh import your-area.pbf


[ringen00]

Thanks! I'm not generating any data myself - completely dependent on post one of this thread!
0.1.7 didn't work with my old data so I tried it with new data which failed too...