We're using the Tour Planning API because it seems to be the only routing API that supports time windows, however according to the documentation the Tour Planning API does not return the route polyline.
Is there another way to get the route polyline along with the ordered stops?
Here Tour Planning and HERE routing are based on the same data; therefore, the tours returned are realistic. In the tour results, the sequence of stops also includes breaks if there are. While requesting the routes from routing API, use all the stops as waypoints (via) with duration at that stop (stopDuration). The resulting route should closely match the tour plan. Depending on the current traffic situation or other factors, there can be a minor difference.
Learn more about waypoint routing here: https://developer.here.com/documentation/routing-api/dev_guide/topics/waypoint.html
An example of routing request with waypoints and stopDuration looks like this: https://router.hereapi.com/v8/routes?routingMode=fast&transportMode=car&return=polyline,summary&departureTime=2022-08-01T08:00:00&origin=52.530914,13.384966;radius=100&via=52.525331,13.369311;radius=100!stopDuration=360&via=52.503011,13.341190;radius=100!stopDuration=1200&destination=52.530914,13.384966;radius=100
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
For reference, some related (not duplicate !) questions:
Fleet Telematics API fails to find route
Increasing search radius for way points in Here Maps Fleet Telematics API
How to increase search radius for a road link for a waypoint (Fleet Telematics API)
HERE Fleet Telematics API doesn't really optimize cost
First, some context. We're providing services for customers operating in Europe / North Africa.
The use case discussed here is to calculate truck routes with different possible goals, sometimes it's getting a cost-optimized route (including tolls or not), sometimes to get the fastest or (near) shortest, or a mix
Usually, we work with postcode/city locations, not full addresses
Initially, you had to use several different APIs to do that, now it's more or less fused into the Fleet Telematics API.
So, let's dive into the documentation: https://developer.here.com/documentation/fleet-telematics/api-reference.html
We're greeted with this introduction:
The HERE Fleet Telematics API is a set of REST resources for advanced
fleet telematics on top of the HERE Location Services. It supersedes
the services CLE, CRE, GFE, GFE-onMaps, PDE, RME, TCE, and WSE.
OK, the FT-API indeed rules them all. We're in the right place.
There are lots (LOTS) of different parameters you can play with, and it's working quite well, except that if you compare the routes to those of the competing services for truck routing, the optimization is often not very good, bordering on bad.
Then, at some point, you come across this strange couple of paragraphs at the end of the "Toll Cost & Cost Optimize" chapter in the Developer Guide:
https://developer.here.com/documentation/fleet-telematics/dev_guide/topics/calculation-considerations.html
Choosing a Toll Cost Routing Engine
Specify the parameter &rollup and/or &cost_optimize to get the route calculated by Routing API. Routing API itself doesn't cost/toll optimize, but provides the fastest and the shortest route and some more routes with different options. Fleet Telematics API then chooses the route which has the minimum sum of driver_cost, vehicle_cost, and toll cost. Hence, a (toll)cost-optimized route is usually found, but it is not always guaranteed.
Specify the parameter &rollups instead of &rollup, and don't specify &cost_optimize, to get the route computed within Fleet Telematics API. Fleet Telematics API ignores the shortest/fastest in the mode parameter. Instead, it minimizes the sum of driver_cost, vehicle_cost, and toll cost. This yields fully cost-optimized routes (within the limitation that routing doesn't consider the smallest roads when very far away from waypoints). But doesn't support all Routing API parameters and can show higher response times.
Ignoring the hackish way of unlocking the full-fat optimizing engine (why not a real parameter ?), the end phrase is quite ominous. Still, it's tempting to try to improve results after exhausting all the options of the Routing API.
Turns out the results are worth it, but with lots of caveats...
The first sign that we are entering uncharted territory is that we're told that it "doesn't support all Routing API" but we're left to discover which ones (trial & error ?).
What's trickier is that some parameter values can cause problems:
Let's go from HARELBEKE (Belgium) to LA MEZIERE (France)
https://fleet.ls.hereapi.com/2/calculateroute.json?apiKey=...&driver_cost=0&vehicle_cost=2&ignoreWaypointVehicleRestriction=20000;1;all;0&waypoint0=geo!50.85677,3.31078;2000&waypoint1=geo!48.21925,-1.7546;2000&mode=fastest;truck;traffic:disabled;motorway:0&legAttributes=shape,-links,-maneuvers&limitedWeight=44&trailersCount=1&excludecountries=CHE,AND&tollVehicleType=3&detail=1&mapMatchTolerance=2000&routelegattributes=li&routeattributes=gr&linkattributes=none,rt,fl&rollups=none,total,country
=> "Couldn't reach waypoint 1"
Turns out that changing only the parameter "driver_cost=0" to some other value is enough to make it work. And yes, "driver_cost=0" works with thousands of other routes, but not this one. Why?
Another set of weird cases is that some routes choices are hard to explain
Let's go from BORDEAUX (France) to PARIS (France)
Nailed it! The best route, 10/10
Then back to BORDEAUX from PARIS (same parameters of course)
https://fleet.ls.hereapi.com/2/calculateroute.json?apiKey=...&driver_cost=20&vehicle_cost=2&ignoreWaypointVehicleRestriction=20000;1;all;0&waypoint0=geo!48.85717,2.3414;2000&waypoint1=geo!44.8367,-0.58107;2000&mode=fastest;truck;traffic:disabled;boatFerry:-2;railFerry:-2;motorway:0&legAttributes=shape,-links,-maneuvers&limitedWeight=44&trailersCount=1&excludecountries=CHE,AND&tollVehicleType=3&detail=1&mapMatchTolerance=2000&routelegattributes=li&routeattributes=gr&linkattributes=none,rt,fl&rollups=none,total,country
Disappointing result considering that you just have to take the same route back, 4/10
Moving on to the first big unsolved problem for us: boats
The documentation states that, for trucks, you can only cost-optimize. To go for shorter or faster routes, you have to tweak the values of vehicle_cost or driver_cost.
A minor issue is that you lose the "real" costs calculation but it's easy to calculate yourself, so no big deal. The major problem is that if you push the vehicle cost above a certain threshold, around 4€/km, and you're near a coast, the engine wants to take a ferry.
For instance: ERMELO, 3851, NLD => CHATRES, 77610, FRA
Live request here
Sure, going to London, great idea. 2/10 including 1 bonus point for creativity
The solution for this route is to to add the &tollPass=transponder parameter to be able to use highways w/tolls in Belgium for trucks (anything above 3.5t). That's only for FT-API, the Route-API doesn't need it (go figure). So if you do truck routing in Europe, that parameter is de facto mandatory. But for the next route, there's no known (to me) solution, you can't avoid the boat trips.
CESTAS, 33610, FRA => GIUSSANO, 20833, ITA
Live request here
FIVE sea trips! It's not a truck route, it's a touristic cruise! 3/10
Unfortunately, the parameter vehicleCostOnFerry= doesn't change the route - it computes the additional cost but still goes for the boat(s)
Last shot in the mode parameter: boatFerry:-2;railFerry:-2, but nope - still prefers the boat
Only option boatFerry:-3;railFerry:-3 but then you can't cross the sea when you have to
Second big unsolved problem: waypoint radius
The premise is that the exact waypoint is not always reachable with a truck, mainly because you don't always have the real address but a default position in a city or postcode.
To work around that in the Route API, you define a radius around the waypoint to make it fuzzier. That parameter is ignored by the FT-API.
See that question for an example: Increasing search radius for way points in Here Maps Fleet Telematics API
The suggested workaround is to set the routeMatch=1 parameter. At first, it seems to work, but that option hides some nasty surprises.
First surprise: no error but the engine drops one or more points with the warning "Ignoring Trace Point X/Y because it is far away from the neighbors"
Luckily, there's a solution: ignoreWaypointsFarFromNeighbors=false
Second surprise: no error but you're teleported from one location to another
BIGANOS, FRA => KOLDING, DNK
Live request here
There the warnings are:
"code": 1021, "message": "Ignoring tracepoints with too big distance to the main route"
"code": 1005, "message": "Tracepoint #1 (55.48637 / 9.47336) moved by 1676199 meter onto the route"
At that point, I just gave up on routeMatch=1 because I found no parameter to avoid that and no workaround.
To summarize, at the moment we use the FT-API by default (because it finds better routes), but with two limitations:
it's impossible to fully optimize for distance because there's a practical limit to the vehicle_cost parameter
we have to fall back to the Route-API engine when the FT-API fails because of unreachable waypoints
Does anybody have a solution or workaround for those remaining problems ?
I'm using the Here API to calculate routes for trucks with 40t. Using the HERE devtools, i got the same error of my APP. The answer is "The API can't calculate the route because of illegal access". I checked the map (image attached) and in the street where my journey will start, with a difference of some meters, it exists two limitations 12t and 18t. The street is one way... If you see the satellite image exists several trucks... The company is testing the software says the trucks goes their...
Can some help me on this?
https://fleet.api.here.com/2/calculateroute.json?waypoint0=41.325299,2.141551&waypoint1=stopOver,3600!41.3291843,2.0317197&waypoint2=stopOver,3600!40.91260530,-8.42291420&waypoint3=38.855951,-9.104382&mode=fastest;truck;traffic:enabled&departure=2020-08-19T02:57:58&alternatives=0&weightPerAxle=14t&limitedWeight=40t&height=4m&width=2.55m&length=16.5m&trailersCount=
If you want to ignore the restrictions for trucks in the route, add the parameter truckRestrictionPenalty and set the value to soft.
The route violating truck restrictions is indicated in the response with dedicated route and manoeuvre notes. The route with the note of the type violation and the text truckRestriction may be travelled at your own responsibility. While driving on such a route, extra care has to be taken as it may result in a vehicle or road infrastructure damage.
You can read more about the parameter here.
Thanks for your feedback, but we are using the Fleet Telematics Api not the Routing API. Using your info, We researched a litle more and we found the equivalent parameter: ignoreWaypointVehicleRestriction.
We added these params &ignoreWaypointVehicleRestriction=5000;0;all and the API returned the route with the warning.
Thanks,
I have the following content in the link (https://www.developer.here.com/documentation/android-premium/dev_guide/topics/routing.html):
You can use RouteWaypoint to add more waypoint details to your route calculations. These details include whether the waypoint is a deliberate stopover or a crossing point through which the route must pass. This affects routing because the path containing the stopover or route may be different. For example, the calculated route may suggest a U-turn maneuver after a stopover, while a route containing the same location as the waypoint is recommended to continue on the same street. The via waypoint type is only supported in car routes and is not supported in other route types.
I guess this passage means that your company's SDK supports path planning between multiple points, but it seems to only support the "car" type. I want to confirm if the truck type is supported.
Adding multiple waypoints for Trucks is supported, but waypoints will always be of type "Stop_Over" , you cannot have a waypoint as type "Via_point" when using Truck Routing. More details can be found in https://www.developer.here.com/documentation/android-premium/api_reference_java/com/here/android/mpa/routing/RouteWaypoint.Type.html
VIA_WAYPOINT
public static final RouteWaypoint.Type VIA_WAYPOINT
No maneuver is generated for a VIA waypoint. After the VIA waypoint, route will continue in the same direction as when it's approached.
Via waypoints will "force" the route to pass through them, but they will not cause any guidance, announcement or maneuvers.
VIA waypoints are not considered during Guidance triggered re-routing nor do they trigger any callbacks upon arrival at the waypoint.
This is only supported by RouteOptions.TransportMode.CAR . It's ignored for other transport modes.
I am setting up a routing service specific to certain types of trucks. I have been searching the HERE documentation for a way to specify a maximum gradient for the route, but cannot seem to find such a function. Am I missing something? Is this possible? My users indicate that 5% is a good threshold for certain trucks.
Fleet Telematics API provides you the capability to handle such situation. PDE layer supports slope information in ADAS_ATTRIB_FCn. Below are some methods to achieve the above ask. You can pick any of the suggested ways depending on your usecase. Hope you find it useful.
Set fuel consumption on slope to very high number – calculateroute.json method provides a requestParameter “customConsumptionDetails” in which the slope value could be set very high number that the route calculation tries to avoid such routes. Refer https://cle.api.here.com/swagger-ui.html?app_code=xxxx&app_id=xxxx#!/Routing_%26_Route_Matching/calculateRouteUsingGET
Request for adas attributes and avoid slope links - Set requestParamater “attributes=ADAS_ATTRIB_FCn (SLOPES)” and get adas layer. Determine the links you would want to traverse and trigger same query setting “avoidLinks” requestParameter. Refer https://cle.api.here.com/swagger-ui.html?app_code=xxxx&app_id=xxxx#!/Routing_%26_Route_Matching/calculateRouteUsingGET. Also https://tcs.ext.here.com/pde/layer?region=WEU&release=18144&url_root=pde.api.here.com&layer=ADAS_ATTRIB_FC1 for explanation on ADAS attributes.
Add custom overlay – This method is used widely by our current customers. You can add a custom layer on top of Here Map layers where you can avoid links/roads where your trucks should pass through. Read more on overlays - https://developer.here.com/documentation/custom-routing-extension/topics/resource-overlay.html