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 ?
When using Fleet Telematics API I have been getting the error message quite often -- about 10% of the routes I want to calculate: "Couldn't reach way point 1 (start links 781909352 -781909352 dest links 881144574 -881144574 881144579 -881144579 ), link 881144574's through traffic restriction might apply, link 881144579's through traffic restriction might apply"
Sample query: http://fleet.api.here.com/2/calculateroute.json?mode=fastest;truck;traffic:disabled&driver_cost=20¤cy=EUR&rollups=total,country,tollsys,country;tollsys&commercial=1&shippedHazardousGoods=0&waypoint0=52.51,13.42&waypoint1=45.747353, 11.733903&tollVehicleType=3&vehicle_cost=0.5&fuelType=Diesel&emissionType=6&length=1500cm&height=270cm&heightAbove1stAxle=120cm&vehicleWeight=7000kg&vehicleNumberAxles=2&trailerType=2&trailersCount=1&trailerNumberAxles=4&trailerHeight=270cm
What are these numbers after the word "links"? Do they give more information about what the restriction might be? And if so, how do I access that information?
When I manually adjust the waypoint latitude and longitude a bit to move it to a nearby bigger road, a route is able to be found. But for me this needs to be automated to work. If I could increase the radius around the waypoint that would be considered a "success" to find a route, that would solve my problem.
The numbers after the word "links' are link IDs with the - indicating an opposite direction of travel. The error means the algorithm cannot get a valid route that goes through those two waypoints without violating the restrictions that you have provided (as parameters). You can add a routeMatch parameter with value 1 so the algorithm will treat you waypoints as GPS trace and find the most probable trace along the route.
I want to measure the distance to the next intersection/traffic light based on a gps location(s).
I DON’T have a route (i.e. no destination point) but I can get gps locations every second (while on the move).
Is it possible to get the information using HERE APIs?
I understand that there is no direct way (specific api) to do it, but I would appreciate any idea that will fulfill my needs.
The general idea that I came up with was getting at least 2 gps points to understand the direction, then getting link_id for current location and try to get the next links in same direction/road and find if any of them are intersections...
I didn’t find a way to do it. Any ideas?
There is no direct API for this however there is an idea that you have to crawl along the link into the direction determined like you outlined (or better by sending the last few GPS points to our Route Matcher (aka RME)) until you reach an intersection.
And this can be achieved with a concept of "electronic horizon" in SDK. It takes your current road link and driving direction and then crawls forward over the upcoming links until an intersection comes (or even beyond taking the most probable choice). mobile SDK has this "electronic horizon" feature.
https://developer.here.com/documentation/android-premium/dev_guide/topics/electronic-horizon.html
It seems that the Routing API requires a Lat/Lon pair to be supplied to the Waypoint parameter. I've seen other APIs that allow for the actual address to be passed, instead of the Lat/Lon. I'm wondering if anyone knows of a way to do this with the Here.com API. In many instances I can obtain the Lat/Lon first, but in one instance it's proving to be a headache, especially given the nature of the way that the REST APIs work and the fact that I'm trying to batch-process a small group of addresses at a single time. Any help would be appreciated.
Unfortunately Routing API needs a waypoint in lat, lon and required a Geocoding as a pre-requisite.
Maybe a not so nice workaround if you are facing issues with Geocoding, the Duck Duck Go provides a syntax
https://duckduckgo.com/?q=!here Junghofstraße 14,60311 Frankfurt am Main,Germany, Germany&ia=about
But you will stll have to extract the lat,lon from the final redirected url.
I am using Google Maps API v3 Distance. It has worked well for the majority of the addresses in my database. However, it seems like some addresses just aren't available in Google Maps, and it seems to pick the closest street address match which could be way off. I would expect Google Maps in this case to provide an answer based on city and zip. Does anyone have a solution? I've thought of double checking mathematically by geocode and checking Yahoo maps(or other sites) for the ones that are way off but that adds processing time and is not a very elegant solution. There must be some setting I'm missing or other such work around.
Thanks!
BTW shout out to the new Json Serializer! Well it was new to me anyways.
How are you formatting the address you are sending ?
I've used the Google Maps API to do some reverse geocoding and if a street could not be found (due to a typo or what have you) Google would return the lat lng for the historic town center.
I structured addresses as Country, city cityzip, street nr.
You should use the location_type of the geometry object to determine what accuracy was returned. I suggest checking to see if the returned resulsts indicate whether a result is anything other than ROOFTOP or RANGE_INTERPOLATED.