Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/graphhopper/graphhopper/issues/1940 below:

Future of 'Offline' Routing · Issue #1940 · graphhopper/graphhopper · GitHub

The current state of routing on mobile devices (iOS & Android) without internet access (aka "offline routing") is suboptimal:

• The Android support is "okayish", but for a meaningful usage we could need graph merging or a tiled approach to allow cross-graph routes and a fix for a strange, per-process virtual memory limit to allow loading big graphs too e.g. a native DataAccess or file cache approach. There is also still no CI integration for Android, see Android build fails on build server #803.
• Since several releases there is no update of our iOS port. Here all the limitations of the j2objc library apply, but it worked surprisingly well and even supports several Java 11 features and without any artificial virtual memory limitation.
  Update: see this new issue: Rebased to graphhopper master and current ios  graphhopper-ios#46
• For both platforms we do not have the public transit module as only the core is limited to Java 7.

I am really happy that despite these limitations I know there are apps in the app stores that use GraphHopper for offline routing (Android and iOS).

And still, we are struggling to continue supporting this as we have to limit ourselves and avoid updating dependencies (see e.g. #1803), stick to Java 7 in the core and also many dependency issues when it comes to Jackson and its annotations and many more design decisions that would be less complicates without "Android Java" in mind. Also there will be inline types in Java, which are already available as experimental feature in JDK 14, which it will be hard to avoid in the core. Previously we have accepted this and I've done lots of testing for Android myself and invested time or provided the map data and apks, but this does not make much sense as I have no real Android- or "app store"-experience. Additionally it is effort that I'm no longer willing to invest.

I see the following options:

1. we abandon offline routing and embrace the latest server side Java version in GraphHopper
2. we make it worth to limit ourselves in the core (i.e. implement the missing "production" features and update the iOS port and have real community involvement for this like we already have for other things)
3. make native GraphHopper working for mobile devices too (GraalVM native image likely combined with Gluon tools). For iOS see also Add iOS support to Substrate VM oracle/graal#373. This is currently not usable: even a simple HelloWorld is hard to compile. (could work together with option 1). See update.
4. a special Android fork of GraphHopper (suggested from @develar; could also work together with option 1)

If no one steps up for contribution in this area in the next months (see for concrete tasks in option 2), then I'm afraid that we'll have to go for option 1 and drop explicit support for Android offline routing (it might still work).

So, if you use GraphHopper for offline routing, now it is the right time to contribute :) ! (@devemux86, @develar, @menion, @johnpercy, @Starcommander)

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4