For our application we are presenting route options to a user that will be used for planning purposes (distance, time, etc). Is there a way, with the bing maps web control api, to ignore traffic conditions? For example, if a major highway is closed at the time the directions are generated, I don't want to route around that. Other conditions are fine, such as highway or non-highway, or possibly just other options that are similar. But we don't want to change the route options based on current traffic. Thanks.
Simply set the routeOptimization option in the directionsRequestOptions to shortestTime. I believe that is the default. The calculated route will be based on posted speed limits and not on traffic conditions. The response includes two times, one with and one without traffic for the route path.
Related
I'm currently making a map with roads that I have driven in the past. Right now, for one route I enter a few waypoints, and the route is calculated through these waypoints using OSRM.
It works fine, but the problem is that on every pageload this route will be recalculated (which makes sense, cause that's how routing works). Let's say I have 50 routes, that'll be a lot of requests. However, I want to be able to calculate the route once, and save the line that is generated as a polyline, which essentially caches the route forever.
Since the routes all stay the same, and no recalculation is necessary, this would be the best way, because then I don't need to setup my own OSRM server or pay for a routing service. (I might need to recalculate routes every once in a while, but that's alright).
Is this way of converting/cachine routes possible? It would be great if I could get this project working live without any routing attached to it.
Thanks for your help in advance!
I'm working with Directions API, trying to get the best route from one point, pass through another places and return to the origin. But the max waypoints the API allows me to put is 25, and I need 120 on average.
Is there a way to change this restriction? Or maybe another service that allows more than 25 waypoints?
It's not currently possible to add more than 25 waypoints for Directions API.
However, there is an open feature request in Google's Issue Tracker which I suggest starring to increase visibility and subscribe to future notifications:
https://issuetracker.google.com/issues/35824756
Hope this helps!
I know that from most of today's REST APIs, web calls responses have to be paginated.
But, I don't see on the web any insight on how to select the ideal size of a batch returned by an API call: should it be 10, 100, 1000. To be short: on what factors should we base the reflection of the size of an API response?
Some people state that it should be based on the number of elements displayed by the UI. I don't agree with this, as not all APIs are directly linked with an UI, and, in any cases, modern REST APIs allow to chose the number of items in output batch with a configurable parameter up to a certain amount.
So, how could we define the value for this "maximum number of elements returned by an HTTP request"?
Should it be based on the payload size? Internal architecture of the API? Should it be based on performance measurement?
Any insight on this? I'm not really looking for an explicit figure, but more some techniques that could help to find the answer. The best for me would be the process followed by some successful APIs. But, I cannot find any.
My general approach to this is to:
Try to avoid paging
Make REST clients resilient against paging changes, by using next and previous links, instead of using a ?page= attribute. A REST client knows another page is available strictly by the appearance of the link.
I don't use hard rules or measurements to figure out when paging is needed. Paging is generally painful, so my first approach would be to try to figure out what requirements drives the need for paging, and if that requirement can be removed.
Once I've determined it's not possible to remove this requirement in another way, I would set the cut-off of a page as large as reasonable, to remove the likelyhood clients need to do additional requests.
If it's a closed API (used only by clients you control), pick whatever the UI wants. It's trivial to change. If clients can choose from several options, you can include a pageSize parameter. Or, better..
If it's an open API (used by clients you don't control), then let clients control what size paging they want. Rather than support a pageNumber parameter, support offset and limit. Offset is how many records to skip before starting to return records, and limit is the maximum number of records to return. If the client is not happy with how their request performs, they can adjust the parameters to suit their needs. Any upper limit your API has should be driven by what your service can handle. It's neither possible nor desirable for you to try to figure out the Magic Maximum Page Size that makes all clients happy and no clients sad.
Also, please note that none of this has anything to do with ReST, which is silent when it comes to paging.
I usually make a rough performance measurement by hand. I want as few requests as necessary, but do not want to risk timeouts.
With ORSM there are 3 profiles for different modes of transport, cycle, foot and car. These come with OSRM.
According to the following post which was made 1 year ago, OSRM does not support multiple profiles:
OSM routing (OSRM): do I need to duplicate all data for different profiles?
Yet in the official documentation there is a profile argument as part of the URL called for retrieving a route from a running OSRM instance:
http://project-osrm.org/docs/v5.6.4/api/#general-options
The path would look something like this:
http://router.project-osrm.org/route/v1/driving/
Without driving, foot or cycle in the URL a route won't be retrieved so one of them is required for the API, yet if I compile a route for car on the server, but then use /foot/ in the URL to retrieve a route, it will still retrieve a car based route, completely ignoring 'foot'.
Could anybody from OSRM explain why something as useful as multiple profile support has been withdrawn, and what the point of driving is in the above URL seeing as it is ignored anyway and just appears to use the profile attached to the running instance of OSRM?
The solution to the problem of multiple profiles appears to be to host parallel copies of the routing machine for each profile and address different IP's, so again, what is the point of 'profile' in the URL?
Could anybody from OSRM explain why something as useful as multiple profile support has been withdrawn
The support has never been there. You will need to run separate osrm instances for each profile.
The URL option is merely there to make it easier to stick a nginx in front of your OSRM instances and distribute to the correct instance based on profile string.
We might implement multiple profiles in the same OSRM instance in the future, but this is still far out.
I've been attempting to use the Bing traffic API to return traffic data for a specific area, but I never seem to get any traffic info back, even at peak hours when I can see several incidents listed with the BBC Travel website.
I haven't been able to find a way through the Bing API to show a bounding box on a map to verify that I'm getting the right area, but when I display the bounding rectangle on a google map, it covers the area that I'm interested in. I've also tried expanding the area considerably to include surrounding areas, and then I do sometimes get some data, but that seems quite erratic and disappears again when I expand the bounding box again??
The URL I'm using is:
http://dev.virtualearth.net/REST/v1/Traffic/Incidents/51.4,-2.8,51.7,-2.3/true?o=xml&key=MyKey
(South, West, North, East co-ordinates).
And it covers the following area on a google map, which is exactly what I'm expecting:
Am I doing something completely wrong with the API call or is this some weird behaviour that shouldn't be happening?
The BBC pulls in their Traffic incident data from a different source. Looking into the Traffic Manager Module in the Bing Maps V7 control I do see some incidents, not the same as the BBC though. The Bing Maps control also has traffic flow maps as well.
Here are a couple of other API's you can try out:
http://data.gov.uk/dataset/live-traffic-information-from-the-highways-agency-road-network
http://www.highways.gov.uk/traffic-information/