It's easy to be cynical about the future of the internet but OSM and tools like GraphHopper are a wonderful and rare example of at least _some_ power being wrested away from the incumbents. Finding Leaflet, OSM, and custom tile servers many years ago was a godsend when it seemed like your only option for including mapping was relying on Google maps.
Great work Peter and the rest of the GraphHopper team.
I note with interest the improvements to GraphHopper maps on mobile. I don't know if you saw a couple of days ago an article was linked on HN with an interview of Kevin and David from Valhalla: https://console.substack.com/p/console-179 where David says:
> The main drawback [of GraphHopper] compared to Valhalla is that it isn’t tailored to mobile environments. I think they supported an Android build at one time, but later they dropped support.
There's a dead comment from n4r9 asking about mobile support and I'm not sure why it was voted down because it seems like a reasonable question, but in case n4r9 is reading this, my impression is that the graphhopper engine itself has no support for Android and the app mentioned in these release notes is just a client that uses a remote instance of graphhopper to do online routing.
Yes, the mentioned app requires an online instance (can be self-hosted too).
But it is possible to use GraphHopper for offline routing on an Android device although we do not have explicit support for this (anymore). But as version 8.0 only requires JDK1.8 the routing will work when you configure it to use the memory mapped configuration.
Huh, I never noticed it get downvoted! As I've checked the post it's gradually increased from 1 to 4 karma. I also see that karussell replied about ten minutes after your post. Very strange.
What would be different from a routing perspective? Driving economically (avoiding hills, reducing max speed, avoiding motorways, avoiding cities, preferring shorter distances, ...) is already possible with a custom model: https://www.graphhopper.com/blog/2020/05/31/examples-for-cus...
Ideally it would factor in battery charge levels at departure, ideal charging stations along the route, the time to needed to recharge the battery at charging stations along the route and arrive at the destination with enough battery.
A custom model may be necessary, but with the world transitioning to EV's it may be worth integrating it into GraphHopper as a profile in the future.
I would do the (de)charging (or recuperation) after calculating the route. Sure, there are algorithms for energy optimal routing, but negative weights might not be that clean to handle in normal Dijkstra (or the speed up algorithms we have). So instead I would tell the algorithm to calculate an "energy optimized" route and avoid uphill, prefer downhill, avoid fast speeds (etc) and then I get one and a few alternative routes with elevation and all the other data back I need for energy calculations. This could be done within GraphHopper but I'm unsure if we should do this as this depends on the driving behaviour, car type, temperature and many more data which is probably better handled on the client side.
Now, the ideal charging stations along the route is a problem which involves yet another step similar to a vehicle routing problem (or travelling salesman) where one could use another tool we developed called jsprit. We have written a blog post a few years ago with the simpler situation of a single charging station along the route: https://www.graphhopper.com/blog/2015/05/05/solving-the-elec...
What do you mean? We allow hundreds of routing requests per IP and per day. But we have a few bad guys that misuse the service and so we have to limit this.
