I know that the durationIntraffic is depracated now.
I just cant find a way to get the duration without traffic using google api.
already tried the matrix using DrivingOptions and trafficModel but the duration and duration_in_traffic did not match the duration without traffic in Maps.Google.com
Any help on how to get the duration without traffic data using API?
Image
Duration gives average time and duration in Traffic gives time in traffic .sometimes you run googleApi at midnignt you will find duration in Traffic time is lesser than duration time means duration is not without traffic time.
According to this Google Maps API should return an element called duration as well as an element called duration_in_traffic. Duration will be time without traffic while duration_in_traffic is time with traffic conditions.
Just to set the correct expectations, you shouldn't expect the Web Services API and the Google Maps website to work in the exact same way. These are different products managed by different teams at Google. The search stack is also different, so results may differ.
The result you get in duration field is an approximation of the average travel time for the route. This takes into account average traffic conditions of the last several weeks for a time when you execute a request. That means that the duration can change during the day.
Applying the departure time and traffic_model you can add further information to your requests to get the travel time in the current traffic, this will be provided in a duration_in_traffic field.
Resuming, currently there is no way to get duration without traffic. You will get the average travel time via the API.
Related
I am sending a request to the "tour plan" calculation that determines routes for multiple bus stops and buses as described here: https://developer.here.com/documentation/tour-planning/2.1.0/dev_guide/topics/concepts/problem.html. Depending on the route type, I either need the bus to drop all riders off at a depot at specific time or pick them up at a depot at a specific time. I see the shift time has a start time and optional end like this "2020-07-04T18:00:00Z".
Why is the date important and not just the time? This route will be used every day.
Why can't I just specify an end time and no start so the stop times are calculated from the destination perspective?
Does the calculation take historical traffic information into account for the time estimates?
Can we please add the TAG attribute to the fleet as well (like the tag in "job") so we can pass arbitrary information through to our consumers of the solution? (Example: my internal id of the destination or start waypoint)
Tourplanning uses date to specify the departure time in routing request so it's needed as part of the API request.
With the current design making the start time optional is not supported currently.
The traffic setting configures what kind of traffic information should be considered for routing:
liveOrHistorical: for departure times in the future, either live or historical traffic data are applied depending on how far in the future the departure time is. For departure times in the past, only historical traffic data are applied. The departure time of a vehicle type can be configured via the vehicle profile's optional departureTime property. In case this property is omitted when defining a vehicle profile, the earliest shift start time of all vehicle types sharing that same vehicle profile is used as that profile's departure time. Choose this setting if all locations are within a radius of 190 km and you want to use live traffic data whenever possible.
historicalOnly: only free-flow speeds based on historical traffic data are applied. Choose this setting if you want to avoid live traffic data usage.
automatic: the same as liveOrHistorical, if all coordinates are within a radius of 190 km, otherwise the same as historicalOnly. Choose this setting if you want the service to decide automatically what is the best option.
Details are provided in this link:
https://developer.here.com/documentation/tour-planning/2.2.0/dev_guide/topics/concepts/configuration.html
No, that is left for pre/post-processing on the client-side.
This question already has answers here:
Google Maps API - Getting closest points to zipcode
(2 answers)
Closed 2 years ago.
I'm working on the delivery web app and can't figure out how can I reduce the number of requests app sends to google distance matrix to calculate a distance between requested delivery and store address.
I have a page-catalogue that has around 1000 stores. Each time user enters delivery address I send 1000 requests to google maps API to check if user's delivery address is within each store delivery range. Hence google charges me for 1000 requests every time users enter new delivery address.
Any suggestions on how to optimise usage of Google API and show only those stores that deliver to the selected address, as the current way is the way too expensive. I'm wondering how large on-demand delivery services that have tens of thousands of stores deal with this?
You could calculate the direct-line distance (using a formula) and only request stores whose direct line distance is less than the allowed range, since the travel distance can't be shorter than the direct line.
If you don't care about getting exactly the shortest travel, you can also sort the candidates, request them in order and stop as soon as you get an acceptable one. That will occasionally give a store that's physically closer but further away by road, which may or may not be acceptable.
In most programming languages, the direct-line distance will be available in a "geo" library or similar, under the name "great-circle distance". You can also search for it here on SO.
I have stackdriver alerts/incidents on metrics like cloud run revision request latencies.
If there were a few calls a long time ago that had high latency, but there have not been any new requests since then which had a low latency, the incident will be permanently firing. This is because when there are no new requests coming in, there are no data points for the metric.
Is there a way to automatically stop an incident from firing when there are no recent data points for the underlying metrics? Or is there an alternative way to have alerts on high request latencies in cloud run that automatically switches off the alarm again when no new requests are coming that have a high latency?
The solution of https://stackoverflow.com/a/63997540/6473907 does not work as-is, because the google cloud run built-in metric for the request count does not go to zero when there are no more requests coming in. Instead, it just stops providing any data points. The solution for us was to create a custom logs-based metric that counts the log entries written for every request by cloud run, because the logs-based metric does indeed go to zero, then combine it with the AND_WITH_MATCHING_RESOURCE as described in https://stackoverflow.com/a/63997540/6473907
The chart compares the request count as obtained from the google pre-defined metric run.googleapis.com/request_count (in violet) with the metric generated by a custom logs-based metric (in blue). Only the latter goes to zero when no more requests are coming in.
Edit: This solution will not work because the request count stops being sent to Stackdriver instead of dropping to zero. As explained in the other (more correct) answer, the solution is to create a logs-based metric for the requests, and this will properly drop to zero when there are no additional requests.
This behaviour is documented in the alerting docs:
If measurements are missing (for example, if there are no HTTP
requests for a couple of minutes), the policy uses the last recorded
value to evaluate conditions.
There are a few recommendations in there to mitigate this issue, but all the suggestions assume you're actually collecting metrics, not your situation where there are no metrics at all (because you stopped receiving requests).
This is probably by design: even if you are not receiving additional requests, you might still want to check why all the latest requests had this increased latency.
To work around this feature, you could try to use multiple conditions in your alert policy:
One condition related to the latency: if latency > X
One condition related to the existence of requests: if request count > 1
If you combine those with AND_WITH_MATCHING_RESOURCE, it should only trigger if there's high latency and there are requests. The incident should be resolved when one of the 2 conditions are not met. Even if no new metrics are ingested related to the latency (so the alerting policy still thinks the latency is high), the request count will stop matching after the duration period specified.
Is there a way to get the average number of cars per time unit on each road in a bounding-box on a map using HERE traffic API ? or na indicator of this rate ?
The final goal would be to get the info regularly, and give the option to filter and average the data over time to display the results on a map.
Thanks
This is not possible with any of the APIs currently available on our developer portal. I'm not sure this is available at all, but you can use the contact us form on the portal to enquire about our Enterprise offering around traffic.
I build application which pull sales data from Amazon and push it to Google Analytics.
I'm "hitting" transaction to Analytics and it's all works fine, the problem is that in Amazon the sales data updated after 48 hours (maximum) so I need to pull the report two days later.
Does anyone know if there's a way to send the date of the transaction? Can't find it in the Measurement Protocol API.
Thank you all, Peace and love :)
Not really. You have the queue time parameter (offset between current time and time the data was tracked), but as it says in the documentation:
Values greater than four hours may lead to hits not being processed.
"May" indicates that this is not a completely fixed limit but I'm pretty sure that 48 hours are not covered (Philipp Walton, a Google engineer who frequents SO once mentioned that the queue time limit is somehow related to timezones and rollover between days, so I'd guess that two days are way to long).
Apart from that there is as of yet no way to set a date for a hit.
You can try posting a Custom Dimension for each event you send, where the dimension is formatted to the date-time:-
e.g.
&t=event&cd1=20170423081321&cm1=24 etc
Only problem is: when you generate a GA custom report, the values are accumulated per day. If anyone knows how to get round that, would love to hear it!