-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
That works now, but if I put in from Toronto, On via Augusta, via Washington, to Pittsburgh I get no route found.
I can do it in stages if necessary.
@blincoln
I’m still having an issue planning longer routes with waypoints.
Example: from 22150 (Springfield, VA) to 98229 (Bellingham, WA) routes just fine. If I add any location as a waypoint (I tried Wall, SD, Michigan City, IN, and several other known destination chargers), it fails and says “no route found.”
Thanks for looking into this.
I’m still having an issue planning longer routes with waypoints.
Example: from 22150 (Springfield, VA) to 98229 (Bellingham, WA) routes just fine. If I add any location as a waypoint (I tried Wall, SD, Michigan City, IN, and several other known destination chargers), it fails and says “no route found.”
Thanks for looking into this.
@blincoln
I’m still having an issue planning longer routes with waypoints.
Example: from 22150 (Springfield, VA) to 98229 (Bellingham, WA) routes just fine. If I add any location as a waypoint (I tried Wall, SD, Michigan City, IN, and several other known destination chargers), it fails and says “no route found.”
Thanks for looking into this.
OK, it should now be able to handle really complicated routes too.
Last week, I added a feature to quickly find just any route along the way to assess whether it was possible to route at all, but that turned out to give up too quickly. Now I have removed that restriction.
ABRP in Asia too
I just added routing for all of Asia as well (up to now only North America, Europe and Australia has been supported). Now Tesla countries China, Japan, Taiwan and Korea works, as well as Middle East.
(I know, Google services does not work in China, and most users in Asia are not too keen on English services, but the rest of us can at least dream of distant road trips...)
I just added routing for all of Asia as well (up to now only North America, Europe and Australia has been supported). Now Tesla countries China, Japan, Taiwan and Korea works, as well as Middle East.
(I know, Google services does not work in China, and most users in Asia are not too keen on English services, but the rest of us can at least dream of distant road trips...
)
Thanks. I figured it had to do with the long/complex routes. I don't want to kill your processing power, but we have pretty long distances to cover here in North America.
HaThanks. I figured it had to do with the long/complex routes. I don't want to kill your processing power, but we have pretty long distances to cover here in North America.
Distance is not an issue when it comes to planing, but many potential choices of routes and chargers is. And we have plenty of options going through Europe too 
dwploc
Member
Planning a route on my Chromebook tonight and as shows the route it constantly shows the detail window. I close it and it just opens again seconds later. Haven't seen the before and use your app a bunch.
Hi,
I was playing with your tool to see if a LR M3 would allow me to do some of my usual trips without need for supercharging underway.
Very nice tool with a lot of options to play with. Congratulations and thanks to share this with the community.
One series of tests I have done is without charging needs at all. I would like to better understand which engine you are using for the routing itself. Your engine seems to take traffic into account, but then I don't understand why drive times are way too optimistic.
I compared 3 routers you know:
ABRP 2h32 roundtrip for 267 km (taking the Antwerp route outwards and coming back through Ghent)
Gmaps 2h59 roundtrip for 265 km
Waze 3h11 roundtrip for 279,5 km
Maps and Waze times are realistic... unfortunately.
There was some delay between Gmaps and Waze testing (due to multi-tasking...), so this explains partly why they differ in their routing options.
But as you can see Maps for the same distance takes 20% more time, most probably because he uses intelligent traffic info.
So I have 2 questions:
1) how does it came that you calculate a different route for outward and inward journey? I presume it's because your routing engine does have some traffic notion.
2) why is the timing of the ABRP route so optimistic? Don't you take into account the "real" speed as given by the routing engine?
Why give importance to this? Because consumption varies widely in function of the speed of a stretch of road. Certainly when we try (foolishly) to compensate time lost in traffic jams by overspeed on open road.
stop & go in traffic jams + overspeed might cause up to 20% overconsumption.
See here below a comparison between ABRP, Maps and Waze of the outward journey cut in 4 (representative) parts
I think all needed traffic info is available through the maps API (free as long as it is for personal use)
Google Maps APIs | Google Developers
What are your thoughts about using traffic info in ABRP?
Emmanuel
I was playing with your tool to see if a LR M3 would allow me to do some of my usual trips without need for supercharging underway.
Very nice tool with a lot of options to play with. Congratulations and thanks to share this with the community.
One series of tests I have done is without charging needs at all. I would like to better understand which engine you are using for the routing itself. Your engine seems to take traffic into account, but then I don't understand why drive times are way too optimistic.
I compared 3 routers you know:
ABRP 2h32 roundtrip for 267 km (taking the Antwerp route outwards and coming back through Ghent)
Gmaps 2h59 roundtrip for 265 km
Waze 3h11 roundtrip for 279,5 km
Maps and Waze times are realistic... unfortunately.
There was some delay between Gmaps and Waze testing (due to multi-tasking...), so this explains partly why they differ in their routing options.
But as you can see Maps for the same distance takes 20% more time, most probably because he uses intelligent traffic info.
So I have 2 questions:
1) how does it came that you calculate a different route for outward and inward journey? I presume it's because your routing engine does have some traffic notion.
2) why is the timing of the ABRP route so optimistic? Don't you take into account the "real" speed as given by the routing engine?
Why give importance to this? Because consumption varies widely in function of the speed of a stretch of road. Certainly when we try (foolishly) to compensate time lost in traffic jams by overspeed on open road.
stop & go in traffic jams + overspeed might cause up to 20% overconsumption.
See here below a comparison between ABRP, Maps and Waze of the outward journey cut in 4 (representative) parts
I think all needed traffic info is available through the maps API (free as long as it is for personal use)
Google Maps APIs | Google Developers
What are your thoughts about using traffic info in ABRP?
Emmanuel
Last edited by a moderator:
Thanks for the in-depth post! ABRP does not use traffic information but routes solely based on speed limits and user input. If there is no charging in your journey above I guess the reason for taking different routes is that both routes takes almost exactly the same time to drive and it just happens that left side driving makes one of them better in one direction and the other one in the other direction. Otherwise, this usually happens when you need to charge once in a round-trip.
Traffic information requires a lot of user input or other data which has a lot of commercial value, which means that the data is certainly not free. Google can route based on current traffic, but planning with chargers requires a lot of distance calculations from the backend and Googles per-lookup-pricing is simply not economically viable.
The OSRM routing backend used by ABRP does support traffic input nowadays, but I do not know if there is any useful source of (crowdsourced?) traffic data. Let me know if you have any tips!
Thank yo for your reply.
I understand your point of view. And you are right when saying Google's pricing is "simply not economically viable".
I have a few ideas (2 cents value):
1) I presume that when you say this, you put the API key at server level and of course all requests add-up and the bill comes to you.
If you have one API-key per user (ie the user is providing the key by itself), the number of requests is much lower and secondly, the user wishing to spend for more accurate information may want to pay himself for the service.
2) On the other hand maybe a hybrid calculation is possible. There would be a heuristic when to query Google for traffic data and when to use OSRM for the parts of calculation that are less traffic sensitive.One of the key points would be to know how fast you can determine which is your first stop. Each stop is then an endpoint for the google query.
3) Do all calculations with OSRM and then update your route (and consumption!) with Google traffic data. Consumption would be influenced by the difference of traffic speed versus max allowed speed. On a route where you might drive 120km/h, if google says it will be 40km/h there should be a (negative) impact on consumption. On the other hand if Google says speed will be 100km/h the impact should be positive, because one will be forced to drive slower, but without stop & go.
This assumes you can obtain chunks from Google with their respective speed.
In the best case your estimate of consumption will be more accurate and hence calculation of needing a charge stop will be also.
The hitparade of the best route against the alternative routes could be modified as the driving and the charging times could be impacted by traffic on the road.
But first would be to have an idea of the usefulness of this info for your user base. Perhaps they don't bother at all about traffic and impact on consumption and range.
I understand your point of view. And you are right when saying Google's pricing is "simply not economically viable".
I have a few ideas (2 cents value):
1) I presume that when you say this, you put the API key at server level and of course all requests add-up and the bill comes to you.
If you have one API-key per user (ie the user is providing the key by itself), the number of requests is much lower and secondly, the user wishing to spend for more accurate information may want to pay himself for the service.
2) On the other hand maybe a hybrid calculation is possible. There would be a heuristic when to query Google for traffic data and when to use OSRM for the parts of calculation that are less traffic sensitive.One of the key points would be to know how fast you can determine which is your first stop. Each stop is then an endpoint for the google query.
3) Do all calculations with OSRM and then update your route (and consumption!) with Google traffic data. Consumption would be influenced by the difference of traffic speed versus max allowed speed. On a route where you might drive 120km/h, if google says it will be 40km/h there should be a (negative) impact on consumption. On the other hand if Google says speed will be 100km/h the impact should be positive, because one will be forced to drive slower, but without stop & go.
This assumes you can obtain chunks from Google with their respective speed.
In the best case your estimate of consumption will be more accurate and hence calculation of needing a charge stop will be also.
The hitparade of the best route against the alternative routes could be modified as the driving and the charging times could be impacted by traffic on the road.
But first would be to have an idea of the usefulness of this info for your user base. Perhaps they don't bother at all about traffic and impact on consumption and range.
Speaking as a user, traffic data on ABRP isn’t very important to me. If I used it in the car, perhaps it would become more important.
Rather than live traffic, how about historic traffic for a certain day of the week and time? Google has that information available but I’m not sure how the cost would compare to live traffic. This could be optional based on departure date and time.
When using traffic data you get historical values whenever you start your journey at another time than the current time. The mix between historical and real time is handled by Google itself, so it could be that you get historical data for all remote km even if you start "now". I don't think you get another pricing for historical data unfortunately.
Next to that I saw that "Here" does provide a traffic API. However it's not free after 90 days trial and it is not simple to get even a slight idea of the pricing and the quality of the service. "Here" is a mutant product, so availability and pricing could be temporary. Not a good basis for serious development.
Another big supplier of traffic data is TomTom. But it's not clear to me whether they provide an API for such developments. End-user cost for TomTom traffic data is about 40€/year.
Next to that I saw that "Here" does provide a traffic API. However it's not free after 90 days trial and it is not simple to get even a slight idea of the pricing and the quality of the service. "Here" is a mutant product, so availability and pricing could be temporary. Not a good basis for serious development.
Another big supplier of traffic data is TomTom. But it's not clear to me whether they provide an API for such developments. End-user cost for TomTom traffic data is about 40€/year.
Peter_M
Member
Does the ChaDeMo option work in Canada? When I select it, I see ChaDeMo chargers on the map, but it can't find a route. I'm trying to plan a route from Ottawa to Halifax.
Presently, ABRP puts a limit to the number of optimization steps when searching for solutions with ChaDeMo chargers (since those optimization problems tend to be very hard to solve). In your case, you need quite a few ChaDeMo stops to reach Halifax and this route will simply not be found in time. I would recommend that you add a few of the chargers by hand by clicking them and "add as waypoint".
Peter_M
Member
Thanks, that seems to work. I have to try several options to get a route that looks good, but I can do that.
I had one case where it did the whole route via ChaDeMo stations, bypassing superchargers. I picked a different ChaDeMo station as a waypoint and then it went back to SCs for the first section. Looks like a bug but I'm not sure exactly how to reproduce it.
WannabeOwner
Well-Known Member
I expect it isn't this, but:
When I've done waypoints I've sometimes had one of two problems:
Waypoint inserted out-of-sequence for my route (my pilot error!) and thus the journey was actually A, C, B, D ... and, as such, the B-D distance was large and a Supercharger was included for that section.
Similarly, I have manged to select something on the other side of the dual carriageway, so the route is "Up the road past the Waypoint, off at next junction, back again, stop at way point, carry on, off at next junction, double back YET again ...
... the route all shows a blue-highlight on the road, so it can be hard to see that I have doubled-back ... but zooming in far enough to separate the carriageways brings it to light
Similar threads
- Question
