Add Option to Avoid Ferries and Toll Roads In Routing

[aesculus]

Google does this and I can do it within the Google routing part. One issue is that the optimizer is going to pick superchargers it thinks are best no matter if they are on a toll road or not. Also the UI could be a problem. We are out of room on Settings unless we go to a panel approach like we did for My Cars and in the Edit Trip or Edit Segment we are getting near full up.

[aesculus]

I cannot think of a way to do this with the underlying optimization methodology that EVTO uses. Currently EVTO uses fixed estimates between superchargers, so if you had a route that needed to avoid a toll road or ferry it could violate those estimates. For example you want to get from Petaluma to SF.

Now apply the non toll rule and see what happens to this route:

It could get even worse in situations where there are tolls both ways (some of those bridges only had one way tolls)

While I can tell Google to only create routes that don't use tolls or ferries, the optimizer does not know how to do that. It will assume it can go direct and most likely run out of energy before the user makes their destination.

The only way you can use EVTO in that manner would be to have Google plot a course that avoided ferries or tolls and then add some waypoints that forced that routing, and then optimize. Not really much of an assistance from the user just putting in the waypoints themselves.

[EVGrokker]

Given the results of your research, I'd suggest removing this objective for version 2. We can explain that if a user wants to hand-optimize for reduced tolls, they should use Manual routing.

[aesculus]

It's unfortunate and an artifact on the way I optimize. I think the other guys are doing a more brute force approach but I am not sure.

What I could do is to add the feature but if the user optimizes there would be a good chance they would run out of energy and I would leave them high and dry. Their only course of action would be to add an additional charger manually which might take care of the problem.

That might be better than nothing at all though.

[EVGrokker]

This is closely tied to #74, other route optimization models.

My gut tells me that as more charging stations come online, the 'high and dry' scenario becomes less likely. By leaving the feature in, you're basically supporting the early adopters, with the caveat that it may not always work. The good news is that no one will be harmed.

So I see two alternatives for this issue and #74. Implement them with appropriate caveats, that there are in place as early route optimization features that will improve over time, or disable all optimizations until some future date when you have more confidence in them.

One possible way to deal with making them available now would be to add a popup when the user selects any of the iffy optimization models, warning them that it's an experimental feature dependent upon available charging options along their route, and they may need to manually tweak the recommended route to end up with something satisfactory.

[aesculus]

The technique in issue #74 is real, it's just subtle, and therefore might not be noticed in all circumstances. Note that not ALL factors that could affect minimizing energy/distance are put into the server model (ie slowing the car down). It uses all the current factors but drives towards minimizing time, energy or distance.

This issue on the other hand is different and could create wrong results. I have no way on the server to avoid taking routes between superchargers that don't use tolls or ferries. I am taking Google's best routing in all cases. I did not restrict toll or ferries when I created the relationships of time and distance between superchargers and supercharger/waypoints.

Now on the device side I can turn this feature on, and the routes will avoid tolls and ferries. But the optimizer will have assumed that I went direct between superchargers, or from a supercharger to a waypoint, and therefore could not provide sufficient charging stops for that portion of the route. This would result in the user running out of energy before the waypoint or charger. The two models would not match up.

The two models never are actually the same (the app is much more granular in its calculations) but this only shows up occasionally (see issue #486). Since the app is the only one the user sees, any discrepancies are often masked or overruled by the app routing and energy/charging calculations.

So to net it out I am afraid that if I implemented a feature to avoid tolls or ferries I would be setting an impossible expectation and one that could fail with no chance I would ever 'fix' it.

[EVGrokker]

So it sounds like you want to remove this feature. I'm in favor of robustness and reliability, so I'm fine with it.

If so, mark this issue as "won't implement" and close it.

[aesculus]

I will close this for now and add a FAQ to the website on the issue.