I am trying to find the description for the static traffic pattern table on the Here Maps website, but it keeps telling me that "The page you are looking for doesn't exist". I am wondering if the static pattern tables have been removed from Here Maps API?
Here is the link to the page I was referring to:
https://tcs.ext.here.com/pde/scontent?region=NA&release=19135&url_root=pde.api.here.com&content=TRAFFIC_PATTERN
The response to the request contains the following information blocks:
name of each layer,
each layer mapping between layers and features tile level for each
layer
https://s.fleet.ls.hereapi.com/1/doc/layer.json
?layer=LINK_ATTRIBUTE_FC3
&apiKey={YOUR_API_KEY}
TRAFFIC_PATTERN_FC1...5 Typical link speed per time of day and weekday
TRAFFIC_SIGN_FC1...5 Traffic sign info for driver alerts
TRAFFIC_SPEED_RECORD_FC1...5 Live traffic info recorded from the last days, in 15 minute resolution
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.
I am trying to construct a dataset including road links, their geometries, and information about the roads such as number of lanes, functional class, and average daily traffic. I have been unable to determine whether Here has an API to retrieve something approximating average annual daily traffic for each road link. Is it feasible to retrieve this data?
I've found an API to get general road link information which does not include traffic:
https://developer.here.com/documentation/platform-data/dev_guide/topics/quick-start-view-map-data.html
I've found an API to retrieve map tile images built from historic data (given a day of week and time of day) that shows traffic flow, but does not provide the underlying data:
https://developer.here.com/documentation/map-tile/dev_guide/topics/example-traffic.html
My desired result would be something structured as {road_link_id, annual_average_daily_traffic}, so that I can connect the link with other associated information.
The HERE Traffic API is what you are looking for. It offers:
Traffic Incident Data - provides aggregated information about traffic incidents in XML or JSON, including the type and location of each traffic incident, status, start and end time, and other relevant data. This data is useful to dynamically optimize route calculations.
Traffic Flow Data - provides access to real-time traffic flow data in XML or JSON, including information on speed and congestion for the region(s) defined in each request. The API can also deliver additional data such as the geometry of the road segments in relation to the flow.
Traffic Flow Availability - allows client applications to access traffic flow information (excluding incidents) in an area, if available.
Traffic Map Tile Overlays (Traffic Tiles) - delivers pre-rendered map tile overlays with traffic information that you can readily display with your mapping application. You can request map tiles that show traffic data for a specific area.
See documentation: https://developer.here.com/documentation/traffic/dev_guide/topics/what-is.html
I am using a HERE API call to request traffic incident data from a particular start time. Whenever I include the "type" key and specify "Accident" as the value, no response is returned. However, switching the value to "Construction" does provide a response.
Does anyone have information on how to make the API call return accident data specifically?
Here is the exact call I am using:
https://traffic.api.here.com/traffic/6.3/incidents.json?app_id={{app_id}}&app_code={{app_code}}&startTime=2017-01-01T00:00:00-05:00&type=Accident&bbox=52.5233,13.4035;52.5181,13.4159
There is no data returned as there are no “Accident” type incidents in that location. This can be seen when skipping the “type” parameter:
https://traffic.api.here.com/traffic/6.3/incidents.xml?app_id=APP_ID&app_code=APP_CODE&startTime=2017-01-01T00:00:00-05:00&bbox=52.5233,13.4035;52.5181,13.4159
Traffic Data is dynamic data. Accident can be located somewhere and disappear in a matter of minutes. We recommend to use wego.here.com to locate an accident, or Bing maps (they are all using our services and traffic data).
We were able to find one in Germany right now (should be there until 13:34 German time):
https://traffic.api.here.com/traffic/6.3/incidents.xml?app_id=app_id&app_code=app_code&startTime=2017-01-01T00:00:00-05:00&prox=51.52427,11.85887,15&type=Accident
Hope this helps! Happy Coding!
I am wondering why my goal is not converting at all. It should have.
Goal Type : Destination
Goal Begins With : https://play.google.com and http://play.google.com
I have had a lot of views to my website but for some reason the goal does not convert at all. Due to this my google ad's App Install Campaign is stuck for
Focus on conversions (Conversion Optimizer) - use CPA bids
Unavailable because this campaign doesn't yet have conversion data.
Basically I need some conversions recorded before I can set Focus on app Installs on my google ads.
It's not totally clear to me what domain you own, but I presume you don't own play.google.com. That means you won't be able to use it as a destination in goals.
Figure out what exact event you are trying to log as a goal. If that event can be defined as a URL on your base host address, then use it as a destination goal. If it can't be defined as a URL within your domain, then you'll have to log it as a different type of event.
Ok! So I have spoken to a google representative about this issue, however since I am not enterprise level, he can't push me to tech support and suggested that I use the SO for answers. Here is the question...
In Google Maps Terms it states the following:
(b) No Pre-Fetching, Caching, or Storage of Content. You must not pre-fetch, cache, or store
any Content, except that you may store: (i) limited amounts of Content for the purpose of
improving the performance of your Maps API Implementation if you do so temporarily (and in
no event for more than 30 calendar days), securely, and in a manner that does not permit
use of the Content outside of the Service; and (ii) any content identifier or key that
the Maps APIs Documentation specifically permits you to store. For example, you must not
use the Content to create an independent database of "places" or other local listings
information.
This led me to originally believe that google would not allow caching of any type of information. However, then I read the following:
When to Use Client-Side Geocoding
The basic answer is "almost always." As geocoding limits are per user session, there is no risk that your application will reach a global limit as your userbase grows. Client-side geocoding will not face a quota limit unless you perform a batch of geocoding requests within a user session. Therefore, running client-side geocoding, you generally don't have to worry about your quota.
Two basic architectures for client-side geocoding exist.
Run the geocoding and display entirely in the browser. For instance, the user enters an address on your page. Your application geocodes it. Then your page uses the geocode to create a marker on the map. Or your app does some simple analysis using the geocode. No data is sent to your server. This reduces load on your server, but doesn't give you any sense of what your users are doing.
Run the geocode in the browser and then send it to the server. For instance, the user enters an address. Your application geocodes it in the browser. The app then sends the data to your server. The server responds with some data, such as nearby points of interest. This allows you to customize a response based on your own data, and also to cache the geocode if you want. This cache allows you to optimize even more. You can even query the server with the address, see if you have a recently cached geocode for it, and if you do, use that. If you don't, then return no result to the browser, and let it geocode the result and send it back to the server to for caching.
So one side says you cannot cache, the other side tells you, you should. Another solution it states is to always use clientside when you can, but then this becomes a grey area as well, because both examples state that you must have a user input data. What if the jquery read data from a div or span and then geocoded the information? The user wouldn't have actually done the geocode,but it was still done client-side? I'm trying to create a site that has a bunch of events generated by users and this site could get pretty loaded, so I am trying to determine the best practice in being able to do this. Google suggested here, so before you go and say this is "off-topic" please note, this is where they stated me to post.
Any feedback would be greatly appreciated.
The first quote does not explicitly forbid caching data at all. It is ambiguous as to how much you can cache (what number explicitly is "limited amounts"?) but it does not forbid caching.
You are allowed to cache the data if it helps improve the performance of your site as long as you retain the data for no longer than 30 days and do not make it available in any way to any other service except the service that originally retrieved the data.
Regarding user interaction - if your user explicitly enters a page with the expectation that they will be shown geocoded information I would assume that this would fulfill "user interaction".
As an example from a project I worked on last year I had it set up to do the following:
- Show markers on the map
- If the user clicked a marker they were shown a popup with data from the cache if available, otherwise a geocode would be performed and the returned information would be cached along with the date/time of the cache.
Another page of the site showed a history of these markers at 5 minute intervals throughout the day. If cached data was present (from clicking the map marker as in the previous part) this would be shown, otherwise a geocode would be performed and the data cached as before. The user clicking to run the report was (in my opinion) enough "user interaction" to not count as pre-fetching as the user had to manually select a timeframe before the report would be displayed.
A cronjob then ran every day at midnight which would go through each record with cached data over 25 days old and remove it.
As it was I was caching much less than 10% of the marker positions being shown (20+ markers being updated every minute, but the report was being run on maybe 3-5 markers each day and only geocoding data for every 5th point).