I'm new to Here Maps Traffic API and i'm trying to find out how to know which direction is the QD(+ or -) pertaining to. Is it north or south? Thank you for answering my question.
From: Traffic API Guide - Common Acronyms
QD
This data type indicates the Queuing Direction (QD) of the traffic. When traffic becomes congested, a queue of vehicles begins to build up in the opposite direction to the driving direction. The value can be "+" or "-". The value "-" indicates that the traffic is queued in the opposited direction to the driving direction.
Related
I am working for a anti replay window service for my project and while going through the document I can see that window size is maintained i.e top and bottom, could someone please help me in understanding that sequence number here has anything to do with ordering of packets, my understanding is any packet within the window range the receiver gets, it check(section A2.2. of RFC 4303:), does the integrity check and if it valid mark the index and fwd. Is my understanding correct ?
We are building mobile application for truck navigation. When using HERE SDK route calculation for trucks, it sometimes tries to avoid a particular road segment, that is in reality suitable for trucks.
One example - highway crossing:
When I calculate route for car, route is correct and meaningful, it follows the highway from south to the north and crosses under the east-western highway. We expect the same route also for a truck as trucks drive like this daily basis (legally).
But when we actually calculate route for truck, it makes a massive detour and takes us either to the westbound highway (blue route on the picture) or eastbound highway, where it turns back after several kilometers and comes back (green route on the picture), both of which is a nonsense. It seems as HERE wants to avoid going under the highway bridge.
I tried to put a waypoint slightly north of the east-western highway and suddenly even with truck setting the route is calculated correctly and does no longer want to avoid going under the bridge. So it seems HERE knows it is legal to go there, but tries to avoid this particular road segment at all costs. We witnessed such behavior multiple times at different places.
This is the exact setup:
Start: 49.154356, 16.600705
Destination: 49.190870, 16.594660
Traffic is disabled for route calculation
For tta time we use getTtaExcludingTraffic()
Truck dimensions were tested both with zero size and and with very small values, so that it certainly fits under the bridge
Question is what causes this behavior? It is a problem of HERE's data? Can we avoid such detours in our application?
Seems like this is more so data error, please use
Map creator (locate the poi and make the change, Here team will review and approve it)
Use Map Feedback API : https://developer.here.com/documentation/examples/rest/map_feedback/no-trucks-allowed-on-road
I have a number of locations between which I want to know the travel time and distance.
The locations have been correctly geocoded. However, the problem I am experiencing is that some of the locations lie between a regular road and a motorway. In fact, they lie closest to the motorway.
In this case, the travel time and distance I receive consider the location to lie on the motorway (the closest road), which leads to an incorrect estimation of the actual travel time and distance.
Given that I cannot manually adapt each geocode to lie closest to the regular road, I need a different solution.
I included 'street!!' in my call as indicated on https://developer.here.com/api-explorer/rest/routing/route-to-location-near-motorway but to no avail.
My call looks like this "https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=x.x,y.y&destination0=street!!x1.x1,y1.y1&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=...".
Is there another way to avoid that Here puts the destination on the motorway?
Your help would be greatly appreciated. Thank you in advance!
Below you find one example
Geocodes of departure: 51.090995,4.018793
Geocodes of destination: 51.017960,3.694040 (close to E40/A10 in Belgium)
When I use the matrix routing API, I get a distance of 29799 meters and a travel time of 1317 seconds.
My call:
"https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=51.090995,4.018793&destination0=street!!51.017960,3.694040&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=..."
When I use the routing API to get the directions, I can see that my destination is updated to 51.0187054,3.6935735, which is on the E40/A10. This gives me a distance of 29827 meters and a travel time of 1335 seconds.
I used the call below:
"https://route.api.here.com/routing/7.2/calculateroute.json?app_id=...&app_code=...&waypoint0=51.090995,4.018793&waypoint1=street!!51.017960,3.694040&mode=fastest;car;traffic:disabled"
Given that the distance and travel time differs, I executed my matrix routing API call again with the updated destination geocodes (51.0187054,3.6935735). This provided me with the same distance and travel time as my initial matrix routing request, i.e. 29799 meters and 1317 seconds.
I used this call:
"https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=51.090995,4.018793&destination0=street!!51.0187054,3.6935735&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=..."
As such, I am sure the destination is on the E40/A10. How can I avoid this?
On a related note, why do the travel time and distance differ between the matrix routing API and the routing API?
When I enter the geocodes in GoogleMaps, I actually get the position I wanted.
As you can see, it is not on the E40. Why can't I get a route to the nearest regular street?
So taking the example you gave, the destination waypoint 51.017960,3.694040 lies very close if not on the E40/A10 itself. See image below:
Moreover, using our reverse geocoder API to get the list of address within 200m radius of the destination waypoint returns only addresses (points) along the E40, 9052 Gent, België with street match level . There is therefore no way for the algorithm to know which nearby street you intend to arrive when the waypoint is many hundreds of metres off. I will suggest to correct your waypoints using our reverse geocoder api to determine which waypoints are way off your intended address.
From here maps Voice Guidance ,Exactly When Google TSS will speak about Maneuver Take left into X road ,Now take Right, like that.
Consider Navigation Distance 10km ,when trip started there is Turn left in 500m meters ,so when Google TTS will speak?before 300m or 200m ?
I want to know the triggering point to speak for My task to complete.
--suppose speaking Text is long(eg:Now keep right and then turn slightly right onto JC Road) Speaking logic distance will also change?
--Apart from TBT(Turn By Turn Info) here maps also triggering in middle to speak like ( After 250 meters keep left towards Hosur Road ) how this is calculating
So many questions is single please excuse me
Interface for notifying NavigationManager.AudioPlayer functions used by NavigationManager. Clients can take over playback of audio files and TTS text strings by implementing this interface and submitting to NavigationManager.AudioPlayer.setDelegate
The audio will be played during the entire route, playing the audio based on distance calculation logic can not be done.
In my web application, I need to know the altitude of a road. For that, I use the Google Maps API v3. I use the Direction Service for getting the waypoints and then I use the Elevation Service to get the altitude of each points that the Direction Service has returned.
The problem is, if there's a tunnel or a bridge, the elevation will returns the altitude of the mountain (for a tunnel) or under the bridge...
Is there any way to get the good altitude of the road who goes inside a tunnel or on a bridge ?
I'm open for any suggestion.
Thank you
The data you need could be found in Map Maker Road Attributes (is maintained by the community)
Unfortunately there is no API for it on V3
The "good altitude" only can be obtained with a good GPS or another hardware designed for that. A good enough value could be calculated if you somehow store the places where tall bridges are (or deep tunels), and then for those places retrieve the corrected altitude (not an easy task, but if your scope isn't too big and the data is already on Google's Map Marker it could work).