Yes, I was thinking about this the other day, and standard routing algorithms like Dijkstra's aren't easy to use for this optimization problem. For a standard map/route planner, using speeds on each highway as the cost will yield the route with the lowest time. But when charging stops are involved, the charge speed has to be used as the cost, and it's not constant. It's a function of the length of the next paths to the next charger, the type of charger in use, and the battery size. (Note: This implies that the optimal path for a 60 might be different than the optimal path for a 90! )
You will probably have to implement this optimization in two steps:
1. Use Dijkstra's algorithm (or one of several other path-cost optimization algorithms) to find several candidate paths, say the top 10 or 20 that are least time, assuming a constant, fixed charge time at each charger.
2. Once those candidate paths are determined, then individually calculate the actual time for each path, with the exact charging times. Re-sort the candidate paths by total time to find the optimal path.
This becomes even more complicated if you at some point want to consider monetary costs for charging. e.g. 400 kWh free at superchargers, then after that $0.xx per kWh, vs. $0.yy per kWh at Chademos in the QQQ network, $0.zz per kWh at Chademos in RRR network, etc.
Then you have two separate optimization goals: total trip time vs. total trip monetary cost. For this, you'll have to run the algorithms multiple times, once using charge speed in part #2 above (finds total trip time optimal path), and again using charge $ cost in part #2 above (finds total trip monetary cost). Now you can give the user several choices, such as shortest trip time for a selected $ ceiling (e.g. give me the shortest time path for less than $100 cost). Or lowest cost for a time ceiling (e.g. lowest cost for a path that takes no more than 8 hours).
