The Open Source GraphHopper Routing Engine 8.0 Released | Hacker News Reader

The Open Source GraphHopper Routing Engine 8.0 Released

graphhopper.com

74 pointskarussell17 comments

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.

Those same incumbents are sponsors of OSM, which right now isn't a cause for alarm, but it does make one wonder what their long-term strategy is.

Good point. Maybe it only exists to avoid antitrust claims (sadly I think Firefox falls in this category too).

letsencrypt is similarly vulnerable.

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.

I wonder if you'd agree with that sentiment?

Thanks!

I think he meant that we dropped the explicit support of Android and the example app with offline maps (Mapsforge), see this issue: https://github.com/graphhopper/graphhopper/issues/1940

But offline routing should still work on Android. But as you need JDK 1.8 support this will exclude a few older Android versions and devices, I think.

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.

(There is even an iOS port of version 1.0 :) )

At least previous versions of graphhopper do work on android. Had no chance to test graphhopper 8.0, though. Just use the maven artifacts.

For ios you can find projects to transpile to ObjC within the graphhopper project. YMMV

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.

Is there any plans to support EV routing?

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...

The difference is recuperation of EVs.

Do you have a real-world example where it is preferable to use a certain route alternative because of recuperation?

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...

Why are the rate limits of graphhopper.com so low?

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.

Reply on news.ycombinator.com