Some routers (like Valhalla) have a almost extreme-level of flexibility when it comes to waypoint specification. Our model is currently simplistic. However, with an optional "dictionary", we could support arbitrarily extensible waypoint properties.
This would of course be left entirely to the RouteRequestGenerator to actually handle, but in the Valhalla case, it's pretty much identical to what we do in https://github.com/stadiamaps/ferrostar/pull/268; just convert it to JSON and update the location object.
This raises a few other questions for discussion:
Should we change our approach to WaypointKind? Maybe that could allow arbitrary values too. I assume the two variants we support have equivalents on all routing engines, but anyone please feel free to fact check me on this!
In the case of #268, we are talking about something Valhalla-specific, so we know it's a JSON object and can model it accordingly. What should we do here? Key/value pairs with a HashMap<String, ??> seems logical, but is that too JSON-specific? Should we just leave this as an Option<Vec<u8>> and leave it up to the request generator to know what to do with it? I lean toward the latter, but discussion welcome on this.
Some routers (like Valhalla) have a almost extreme-level of flexibility when it comes to waypoint specification. Our model is currently simplistic. However, with an optional "dictionary", we could support arbitrarily extensible waypoint properties.
This would of course be left entirely to the
RouteRequestGeneratorto actually handle, but in the Valhalla case, it's pretty much identical to what we do in https://github.com/stadiamaps/ferrostar/pull/268; just convert it to JSON and update the location object.This raises a few other questions for discussion:
WaypointKind? Maybe that could allow arbitrary values too. I assume the two variants we support have equivalents on all routing engines, but anyone please feel free to fact check me on this!HashMap<String, ??>seems logical, but is that too JSON-specific? Should we just leave this as anOption<Vec<u8>>and leave it up to the request generator to know what to do with it? I lean toward the latter, but discussion welcome on this.