Hi,
Does anyone here use the Long Distance EV Routing
api and would like to share some experiences?
John
2 Likes
Hi @Digidodo, I have experience using the API (I’m a developer at TomTom). What questions do you have about the API?
Adam
1 Like
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.
2 Likes
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.
2 Likes
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
1 Like
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
3 Likes
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?
1 Like
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.
1 Like
Of course I’d be happy to help! My specific use-case would be as such:
I want to build a trip planner…
- Ask the user for a starting point and destination
- Ask the user what their car is
- Ask the user their current charge percentage
- From there, I would have the car’s efficiency, and maximum capacity in kw/h in a database
- I could therefore calculate all of the required parameter for the API query
- I would also know which connectors (J1772, CHAdeMO, etc.) are compatible with the car
- Next step would be to send the request
- Once I get the response, I would display the Polyline on the map
- I would then need to get basic information about the stations at which to stop to on the way
- Example of data needed: Location Name OR LatLng OR Address
- It would actually be pretty useful if the LatLng or Station Name or Address was provided in the initial response
- From there I would query my database to find the station that corresponds to the one returned by the API
- I would then add markers on the map to show the user where they would need to stop.
- We would also display an approximate charging time at every stop but these don’t need to be super accurate. They should just give a general idea (30 minutes VS 5 hours)
- At this point, if a route exists (if I got a response from the API) I’m done.
- If I got an error message back from the API, I’ll need to give the user some kind of feedback or some alternative option.
A couple of features would therefore be extremely useful:
- Not needing to provide the facility types
- Having basic station information in the initial response
Bonus:
- Having a link to resources where I can find a car’s consumption in the form required by the API (30,16.75:80,20.94) and more
- Alternatively having a list of cars pre-configured on the API side and simply having to pass a car’s ID or name would be even better but would require more work from you guys…
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.
- Having basic routing options support (like on google maps)
- No toll routes
- No ferries
- No highways / Maximize highway
- etc.
- Having the option to look further away from the route to find charging stations (for example, a 10 minutes detour from the original route instead of 1 or 2)
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:
- The coordinate for each charging stop is already available. For each leg that terminates with a charging stop the last point in the points array will be the location of the charging park. The UUID for the charging park is available in the leg summary under the chargingInformationAtEndOfLeg key. I’ll check with the development team to see if this can be used to retrieve further information about the charging park such as it’s name and operator.
- The charging time for each stop is calculated based on the charging mode matched from those sent on the route calculation request. It’s the chargingTimeInSeconds property found under the chargingInformationAtEndOfLeg key in the leg summary.
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
1 Like
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.