Enable integration with multiple routing services

[thehoneymad]

Presently, MapLibre Nav carries a direct integration to Mapbox routing services. Configuring MapLibre Nav to work with any other routing service including opensource engines like Valhalla requires reworking a lot of existing code.

I propose an interface or plugin model that allows MapLibre Nav to connect to any routing engine available in the world. For example, integration with Valhalla will bring client-side map matching with Valhalla route tiles along with its routing capabilities.

Expected behavior

MapLibre Nav provides documentation and golden path solutions to integrate with existing routing engines.

Actual behavior

MapLibre Nav requires extensive code changes to test out behaviours with existing routing engines.

[1ec5]

Presently, MapLibre Nav carries a direct integration to Mapbox routing services. Configuring MapLibre Nav to work with any other routing service including opensource engines like Valhalla requires reworking a lot of existing code.

The Mapbox Directions API v5 request and response formats are derived from the OSRM v5 request and response formats. Even though Mapbox generally uses Valhalla instead of OSRM these days, Valhalla responses still get translated to OSRM responses via a compatibility shim built into Valhalla. Valhalla-specific features have gotten bolted onto the side. Essentially, the Mapbox Directions API v5 response format is the abstraction you’re proposing, except that it happens to be much more similar to OSRM’s native response format than any other routing engine’s.

[boldtrn]

Internally maplibre-navigation-android uses the request and response format that was derived from OSRM as models to power the navigation. I think it makes sense to keep these models more or less similar to what they look right now, they have shown that they work and are reasonably flexible. See also #37, I think we should copy the models over to this repo though.

Then we can create converter mechanisms that convert any routing request / response to the internal models. This part is not super straight forward, but should be doable.

[thehoneymad]

I am happy to have converters. As long as we explicitly note the model we desire for MapLibre Nav and let other routing engines be integrated with it.

For example, Amazon Location Service wants to use MapLibre Nav and we can offer customers a library to translate the response from Amazon Location to MapLibre Nav compatible response. :)

[thehoneymad]

Provided I deleted the mega amount of code in #37, I can help re-instate that back with the help with my team. :)

[1ec5]

For completeness’ sake: the iOS/macOS/tvOS/watchOS/visionOS/Linux/Windows/WASM equivalent to those mapbox-java models would be mapbox-directions-swift, which remains openly licensed and compatible with maplibre-navigation-ios. mapbox/mapbox-directions-swift#121 tracks direct support for raw OSRM responses, but it would amount to nothing more than some syntactic sugar, since OSRM doesn’t provide stuff like translated text instructions out of the box (you need to osrm-text-instructions for that).

[boldtrn]

As far as I know, mapbox-java is also still open-source (MIT), but Mapbox is only deploying the dependency on a private repo, but we could still use the code and for example copy the latest version of the models into this repo.

This should be the easy part, it just takes some time to refactor everything.

The more complicated part would to provide the converter logic. Converting form OSRM or Mapbox directions api should be straightforward as you can use DirectionsRepsone.fromJson() and you are done.

I believe writing converters should be possible for almost all routing engines as the navigation logic works with just the basic data.