Hi,
Does anyone here use the Long Distance EV Routing
api and would like to share some experiences?
John
Hi,
Does anyone here use the Long Distance EV Routing
api and would like to share some experiences?
John
Hi @Digidodo, I have experience using the API (I’m a developer at TomTom). What questions do you have about the API?
Adam
I’ve been trying to use the Long Distance EV API and have been getting weird results. It seems to me like the API can only return a single leg of a trip, when it should return many. For instance, a trip from Montréal, Québec to New York City should be easily do-able by EV (considering you stop to charge a few times) but the API with the default demo values returns a 400 error with a “No route found” error along with it.
On the other hand, if I try to do a short trip (Eg: Montréal, Québec to Brossard, Québec), I get a valid trip and the API seems to work properly. However, I always have a single leg in the legs array when I do these shorter requests (which makes sense).
I don’t know if it’s because the documentation is not clear enough or there is simply an API Bug but it seems pretty counter-intuitive that the Long Distance API can only plan short distances…
Here is the exact request I am sending (I increased the maximum):
https://api.tomtom.com/routing/1/calculateLongDistanceEVRoute/45.5088,-73.554:40.7648,-73.9808/json?vehicleEngineType=electric¤tChargeInkWh=20&maxChargeInkWh=40&minChargeAtDestinationInkWh=4&minChargeAtChargingStopsInkWh=4&traffic=false&constantSpeedConsumptionInkWhPerHundredkm=30,16.75:80,20.94&key=YOUR_API_KEY
I am sending it as a POST request with the body given in the documentation Demo. (https://developer.tomtom.com/routing-api/routing-api-documentation/long-distance-ev-routing)
Thanks for your help,
Pierre-Olivier
Hi @potrottier, the Long Distance EV API calculates a route with an additional leg for each charging stop along the route. If you use the origin and destination points from the documentation example you will get back a route with multiple legs for example.
The “No route found” error indicates that a route was unable to be calculated between the 2 points using the vehicle configuration you provided. The reason why the route could not be calculated is likely due to no compatible charging station being found within the range of the vehicle, either from the starting point or after one of the charging stops along the route.
The example POST body in the documentation is fairly minimal with only 1 connection defined for high speed charging and one for low speed. You can define up to 20 connections for each mode. Each connection is specified as a facilityType, plugType pair and the possible values for these types can be found in a table on the API documentation page (https://developer.tomtom.com/routing-api/routing-api-documentation/long-distance-ev-routing). Defining more connections increases the number of candidate charging stations that can be used along the route.
You can also try increasing the value of the currentChargeInkWh and maxChargeInkWh parameters which are described here: https://developer.tomtom.com/routing-api/routing-api-documentation-routing/common-routing-parameters. In an area of low charging station density if the currentChargeInkWh is low the vehicle may have insufficient charge to reach the first charging stop.
Thanks alot for the quick response! The answer was really helpful. When you mentioned the 20 different connections, do they all need their individual curves to go with the connections or can multiple connectors use the same curve? From reading the documentation it seems like it would be possible to associate many connections to the same curve.
That being said, I tried adding the CHAdeMO plugType with 110v, 220v and 240v facilityTypes using the demo curve. (which should be enough to cover a nice level 3 route from Montreal to New York) then again, maybe I’m wrong and it’s not possible.
When I did that and increased the max power to 80kW (as well as the curve to go with it) I was still unable to find a route.
It maybe be too much to ask but do you think you could provide an example request of a working Level 3 route from Montreal to New York?
Thanks alot!
Pierre-Olivier
Yes the idea is that you can associate multiple connections with a single charging curve. The charging curve won’t effect the route calculation but will be used in computing the charging times returned for each charging stop so you don’t need to be too fussy about that at this stage. I’m away from work this week so may not have time to create an example for you however I think once you’ve identified the common plug types in use in the US and Canada and defined connections for those you should be right. I’ve found that using the API successfully requires understanding what plug types are found in your area of interest and defining connections for them.
I did a quick search and found this article (https://chargehub.com/en/electric-car-charging-guide.html) that says the most common plug type in those countries is the SAE J1772. Can you try setting up some connections for this plug type, try again, and let me know how that goes.
Thanks for taking the time to answer while you’re away. Your tip worked! I was able to create a route MTL-NYC using the J1772 connector with all facilityTypes. I now understand the way the API works a little better! I’m still not 100% sure I understand all the facilityTypes but I’ll do some research on that!
Thanks again,
Pierre-Olivier
I’m glad it’s working for you. If you have any other questions about the API you can ask them here and I’ll do my best to help.
Cheers
Adam
Hey @de9b32ce358d80a64313 ,
It’s me again! Do you think it would be possible to make a request for the Long Distance EV API that doesn’t require the facilityType
fields but only the plugType
? For my specific use case the facilityType
is useless and I just want to filter by plugType
.
I know I could simply put all the facilityType
for every plugType
in my request body but that ends up requiring more than 20 chargingModes
and therefore limits me greatly… The only option I see then is to always put the most common facilityType
in my request and it seems like a bad solution…
Any help would be appreciated !
Thanks,
P-O
Hi @potrottier, I agree that the current request format is quite verbose. Specifying independent facility types allows for more specific charging curves and thus more accurate calculation of vehicle charge time at the charging stops but that won’t necessarily be important for all scenarios, such as yours. I’ll pass your feedback on to the development team. I’ve been working on a map which shows which plug types are most common for each country. Is that something that would be helpful to you also?
Such a map would definitely be a super helpful reference! For now my application only requires data for North-America but it would be useful nonetheless.
And thank you for passing the message. I guess I’ll stick to the regular routing API the mean time. It’s still a much better and more powerful alternative to any other routing API!
I hope the dev team will see value in the idea.
Thanks alot!
P-O
@potrottier I’m wondering if you’d be happy to share a little more information about what your use case is, particularly any EV-related features you’re wanting to support.
Of course I’d be happy to help! My specific use-case would be as such:
I want to build a trip planner…
A couple of features would therefore be extremely useful:
Bonus:
For example:
https://api.tomtom.com/routing/1/calculateRoute/lat,lng:lat,lng/json?car=1234&routeType=eco&travelMode=car&vehicleEngineType=electric
With a dicationary in the documentation:
Car | ID
------------------
Kia Soul | 1234
etc.
Thanks a ton for the great support !! You guys are awsome.
I hope this feedback helps,
Pierre-Olivier
Hi @potrottier, thanks for the detailed reply. I agree that being able to pass an ID representing a vehicle configuration would be a great option for most API users.
Addressing some of the other points you raised:
You can avoid toll routes, ferries etc using the avoid parameter which is described on this page https://developer.tomtom.com/routing-api/routing-api-documentation-routing/common-routing-parameters
That’s a good point! I hadn’t though about using the last point of every leg!
And thanks for the reference! I’ll look into these options. They’ll definitely come in handy.