For routes that start and end in the US, HERE fails to suggest a route that goes through Canada even when I choose 'mode=fastest', and via Canada would clearly be the fastest route (traffic disabled).
e.g. Detroit to Buffalo
HERE We Go
HERE Routing API gives the same as HERE We Go. I use traffic disabled, hence a route through Canada is definitely the fastest: https://route.api.here.com/routing/7.2/calculateroute.json?waypoint0=42.33239,-83.04887&waypoint1=42.95594,-78.90584&mode=fastest;car;traffic:disabled&app_id=______&app_code=____
These places are just inside the US border. If I edit one co-ordinate to fall just inside the Canadian border, a route through Canada is recommended.
I can't find any restrictions that seem to be applied that would prevent routes going through Canada. I've tried examples in other countries which seem to be fine (e.g. a route starting and ending in Sweden was chosen to pass through Norway). What is going on here?
Can you please use fleet telematics with advance mapping options. Also if waypoint doesn't work, you can pass link ID or street to get the accurate result. please refer below documentation for more reference.
https://developer.here.com/documentation/fleet-telematics/api-reference.html
Also report the map team if the route is still incorrect using feedback API :
developer.here.com/documentation/map-feedback/dev_guide/topics/quick-start-submit-feedback.html
Related
Problem: I want to tell if the access road to an US address includes dirt or paved road(like if it is in a remote area without proper road). If it is a dirty road we charge more to the customer for delivery.
In technical terms - The input is going to be a house address and I need to find out if the way to it involves dirt road.
I am ok with making multiple calls to get the complete information. What steps do I need to take?
In general, you will probably need two steps:
Use HERE Routing API to calculate the route between the two locations. It will return the path information.
Get the road attribute from one of the following content sources, such as Map Attribute API, Road Physical Attributes in HERE Map Content.
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 am building an app for a federal government client using the Bargain Finder Max SOAP API. They need to adhere to the Fly America Act: any flight that leaves the US or arrives in the US must use a US flagged carrier.
I have tried to use the IncludeVendorPref and included all US carriers; however, on flights such as ALGIERS (ALG) to New York (JFK) I cannot find a solution because the route may go from ALG to London via British Airways and then London to JFK via American. Because not all flights are American (because of the IncludeVendorPref filter I have on), it does not find this solution even though it is valid because you are taking an American carrier back from a foreign country (it is okay that you are going from a foreign country to another foreign country - i.e. Algeria to London on a foreign carrier).
Does anyone have any advice on how to handle this? Is there an easy way to adhere to the Fly America Act?
There is no specific request that will meet what you want, at least as far as I know.
There are 2 ways in which I can think you can accomplish this:
1. By requesting 200 flights, in order to have more diversity, including the IncludeVendorPref qualifier for all US carriers with PreferredLevel="Preferred". The bad part is that you would have to end up doing the filtering on your side. I think this would be the best way, as it would give you the most heterogeneity without loosing too many itineraries.
2. By calling the service twice, once for the US connection and once for the trip outside. This has several disadvantages, for example it would make it really difficult to create itineraries based on the 2 responses, and it would require to create separate tickets, as those would be 2 separate itineraries.
If neither option suits your needs, I recommend you to contact the help desk to see if there would be another option that I didn't consider.
I am working with the Google Analytics Reporting API. The problem I am running in to is that as far as I can tell the city dimension is not necessarily unique (i.e. multiple cities can have the same name.) So in order to filter to a specific city I need something like ga:country=France;ga:city=Paris which works fine, unless I want everything from Paris OR London. But the OR operator has a higher precedence than the AND operator in the filter expressions, and it doesn't look like there is a way to group expressions together.
So,
Are the strings returned by google analytics for ga:city uniquely identifiy a city?
Is there any way to group expressions together like (ga:country=France;ga:city=Paris),(ga:country=UK,ga:city=London)?
If neither of the above, is there any other workaround?
One of the examples on the reference guide is:
Operating system is (Windows OR Macintosh) AND browser is (Firefox OR Chrome):
ga:operatingSystem==Windows,ga:operatingSystem==Macintosh;ga:browser==Firefox,ga:browser==Chrome
In your situation you could do it in the way of (United Kingdom OR France) AND (Paris OR London) but it would still have your problem if there was a paris in the UK or a london in France.
A workaround would be to make one request where you query the cities in France, and a second different request where you query for the cities in the UK. It would mean making more requests but usually in these kind of cases having smaller but more specific requests is better practice. (And probably easier to manage)
I have built an small application which calls the Google Directions API in Transit mode. It works - nevertheless it returns only one possible route, so it shows no alternatives. Usually I expect 3-4 options to choose from.
Example:
http://maps.googleapis.com/maps/api/directions/json?origin=bieberstrasse,+dusseldorf&destination=norf,+neuss&sensor=false&mode=transit&departure_time=1399399424
The returned JSON structure has the expected "routes" array, but this array always has only one element. I have tried it with addresses in Brazil and Germany - it doesn't matter the country, I only get one single route.
Did I miss some parameter? Could someone help me with it?
If you want alternative routes, specify the request parameter alternatives=true:
http://maps.googleapis.com/maps/api/directions/json?alternatives=true&origin=bieberstrasse,+dusseldorf&destination=norf,+neuss&sensor=false&mode=transit&departure_time=1399399424