Data complications

Solving EV charger anxiety used maths for better road trips, but skipped over using real data. Let’s fix that, or at least try to…

The easy bits

I used Open Route Service to find a base route to a destination and and Open Charge Map to find chargers near the route – thank you to all the contributors and maintainers of these excellent resources!

We’re making good time.

Progressive data complications

I previously sketched the rough process below to show how we might use the base route and charger data to prepare the inputs we need for optimised planning.

How hard can it be? Let’s see…

1 – charger on route

The simplest approach, as many chargers are close to highways and town centres, is to project charger locations to the nearest point on the route. This produces the model from last time. But considering time and energy consumed deviating to the actual location, I skipped ahead to…

2 – projection point return trip

Instead, assuming a charger stop involves a straight-line return trip to the charger from the projection point, we can update model variables and base constraints to include the extra energy consumption.

But this suffers from a major issue in real world scenarios…

3 – branch and merge

Shell Coles Express Taylors Lakes features a 350kW ultra-fast charger we’d probably want to use, but isn’t on a major freeway.

Instead of using the projection point to reach this charger, we’d take a shorter, more energy efficient, and possibly faster variant, branching off the base route before the projection point and merging again some distance after.

Another call to the Open Route Service directions API, with the charger as a waypoint, gives the variant route, and we can find branch and merge points with shapely set operations. Some examples are shown below.

With the lengths of common sections, the base branch, and the variant branch approaching and leaving the charger, we can update our base constraints.

More realistic and still fairly simple. Disadvantaged by an additional directions API call per charger, but maybe we can cache this. Then we realise that chargers may fall within each other’s branch intervals…

4 – untangling branches

So far, to keep the model simple, we’ve assumed we return to the base route between each charger stop. However, if we used both Hobsons Bay Civic Centre and Ampol Foodary Altona North chargers, we’d go straight from one to the other.

Two stops so close together is unrealistic, and we can group chargers to ensure we return to the base route between groups, then add further constraints to use at most one charger from each group.

We’re now doing a lot of data wrangling, maybe we could back up…

5 – enter the matrix

Alternatively, we can take the red pill and acknowledge there is no base route, and we can consider routing between every pair of chargers. The Open Route Service matrix API fetches all distance pairs with a single call, shown below.

This requires a re-think of the base constraints. We introduce a matrix of legs constraints, activated between pairs of stops on the route, to ensure the energy consumption of each leg reflects the corresponding distance matrix element.

While the constraints are a little more complex, there’s less data wrangling, especially as the matrix API also returns travel time data…

6 – time travel

So far we’ve looked at many complications in calculating consumption constraints with route distance data. That’s only part of the picture though–we also need to update the time objective with travel time data…

7 – comparisons and hybrids

To find a way forward, we could compare plans under each data preparation and modelling approach, and we may see very little practical difference, except in rare cases. If not satisfied with a single option, we could also mix and match, or progressively refine, to best trade-off complexity and responsiveness in interactive planning.

Round trip to modelling

As is typical, the data preparation and feature engineering is more complex than the optimisation model itself, thanks to all the edge cases we find. I also describe this as translation of performance and design in End-to-end simulation hello world!

I thought it was interesting to share these progressive data complications for a look under the hood–or frunk–of data-intensive initiatives, and that they would strike a chord with many readers.

And there’s still plenty of mileage for updated road-trip modelling, which I’ll share in a future post.