Hey all—time for another update! Since the last post, I’ve been focusing on solidifying the routing backends in the new spopt.route module. A couple of big milestones are in place now, and I’ve started exploring what the full landscape of available routing services looks like.

OSRM as the Default

After getting OSRM working, the project mentors and I agreed to treat it as the “default” router for the module. Because routingpy provides wrappers for several routing services, other routers should work under similar parameters, but for now OSRM is the one that’s been fully verified. Users can connect to their own OSRM instance—whether running locally or in the cloud—and expect the solver to work out of the box.

Fallback with Haversine Distances

I also added a fallback option for when no router is provided. In this case, the solver computes haversine distances between stops. While this doesn’t follow a road network (so the solution is less realistic), it at least gives a rough estimation. That way, users can still solve VRPs without having to set up a routing backend first.

Exploring Routing Services

With the basics working, I explored other routing services to see what’s supported by routingpy. Here’s the current status:

Router Required Keywords API key? Requires Backend? Confirmed Functional
No router none no no yes
OSRM base-url no yes yes
Valhalla base-url, profile no yes no
HereMaps   yes   no
Google   yes   no
Graphhopper   yes   no
Mapbox OSRM   yes   no
OpenRouteService   yes   no
OpenTripPlanner       N/A (matrix not implemented)

This table should help future users quickly see what’s possible and what’s already functional in practice. We don’t have plans to actively develop for the services that require an API, but because of routingpy, these should function the same as OSRM or Valhalla. Future changes might be required if these services require additional parameters, but these should be small and relatively easy to implement.

Next Steps

Right now, I’m actively working on getting the Valhalla router to function. That’s likely the last major backend I’ll explore as part of this GSoC project, but the design is flexible enough for future contributors to extend to other services.

More updates soon—
Dylan