distance is given in meters for this query:
https://places.cit.api.here.com/places/v1/discover/search?app_id=my-app-id&app_code=my-app-code&at=36.97425,-122.03099&pretty
Is there any plan to support "metricSystem" parameter(as is done in the case of Routing APIs) so that the result can provide distance in miles?
Correct, the distances are just given back in meters from the Places API. There are no further plans to change this in future. But you can easily calculate the values into miles on client side.
Related
I want to create isolines around point locations (public transport nodes) that indicate the service area that can be reached within max. 1 km of walkable distance (with steps of 200 m). When looking at the output, it seems that many of those service areas are not large enough. There are often pieces of road that should be included in the area (as they are within 1 km distance) but they are not. I included a screenshot of one of the service areas below to illustrate.
I this an issue that can be resolved or not?
Illustration
Many thanks
We have to consider the performance of service when calculating the isoline. For this reason, the Isoline service have constraints on the range value.
Please check the below screenshot related to range object and its maximum value.
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.
I'm experimenting with the Isoline API and have a question about the effects of two parameters:
Mode: Shortest
The docs imply that things like turns are penalized. By what factor? Known travel times, or some arbitrary estimation?
Traffic: Disabled
The docs imply that traffic is not taken into account. Does this mean the cost of traversing a component of a road is a function of the speed limit, or collected data on actual travel speeds on that route?
Thanks in advance.
For your questions:
Turns are penalization depend on multiple factors which are different for turns of different characteristic (road types, turn geometry etc).
This takes the actual travel speeds into account.
We are at a cross roads where we need to decide if we are going to store our GeoSpatial data in DocumentDB or SQL Azure. According to this article, the polygon parameter of the ST_WITHIN function in a query can contain a maximum of 256 points. Our data will potentially contain polygons with millions of points as we are mapping continents, countries, states/provinces, etc. We need to be able to use ST_WITHIN against all of these polygons. The article also mentions that we can adjust that limitation by contacting Azure Support.
Why is this limitation in the first place? If Support does remove the limitation, are we going to bring DocumentDB down with so many points?
If you want to do it all in DocumentDB (as opposed to adding something like SQL Azure), you can use an approach of narrowing down the list by using ST_DISTANCE to get candidates and then running the equivalent to ST_WITHIN client side (ray casting algorithm is simple and fast). The trick involves storing denormalized meta-data about each polygon, namely a center point (accuracy of center point not critical) and the maximum radius using that center point. Then if the distance between your point and the center minus the maximum radius is less than zero, it's in the candidate list. It works like a charm and is performant with some careful index design.
One thing to worry about is the condition where the polygon intersects itself. Do you treat the intersecting space as outside the polygon or within it? We had a nasty bug that took forever to figure out and it boiled down to a self-intersecting polygon. This problem exists whether you implement your own algorithm or use the database's native "within" function.
The short answer to your question is yes, they are worried you will bring DocumentDB down with more than 256 points. It used to be limited to just 16 points, but they changed it to 256 recently. Perhaps they will raise it again in the future. We ran into a similar problem with polygons having more than 1,000 points. In the end, we decided to use Sql Server for our polygon searches and then use the data refined from Sql Server to pull the related data from DocumentDB.
The problem is that DocumentDB resources are shared between customers so all of the operations that you run against DocumentDB have to be governed by request units. That way, no one customer can bring the system down with massive queries. I don't know how to calculate the request units from using ST_WITHIN on millions of points, but my guess is that even on the S3 tier, it would probably push the limit of the allowable 2500 Request Units. So even if they lifted the 256 points to a one million points, your query might not be able to finish because it would be too expensive. So I suggest you go with Sql Azure. That is what we settled on and it performs great.
I need to calculating times and distances with multple travel modes, I try to pass multiple travel modes separated with | like this:
https://maps.googleapis.com/maps/api/distancematrix/json?origins=E149AQ&destinations=UB83PH|NW14SA|WC1E7HU|N78DB&mode=walking|bicycling|driving&language=en-GB&key=myKey
But it doesn't work as I expected.
Only a single travel mode is supported per request. To get results for multiple travel modes, make multiple requests.
The documentation implies that but doesn't state it explicitly:
Optional parameters
mode (defaults to driving) — Specifies the mode of transport to use when calculating distance. Valid values and other request details are specified in the Travel Modes section of this document.
Travel Modes
For the calculation of distances, you may specify the transportation mode to use. By default, distances are calculated for driving directions. The following travel modes are supported:
driving (default) indicates distance calculation using the road network.
walking requests distance calculation for walking via pedestrian paths & sidewalks (where available).
bicycling requests distance calculation for bicycling via bicycle paths & preferred streets (where available).
transit requests distance calculation via public transit routes (where available). This value may only be specified if the request includes an API key or a Google Maps API for Work client ID. If you set the mode to transit you can optionally specify either a departure_time or an arrival_time. If neither time is specified, the departure_time defaults to now (that is, the departure time defaults to the current time). You can also optionally include a transit_mode and/or a transit_routing_preference.
Note: Both walking and bicycling directions may sometimes not include clear pedestrian or bicycling paths, so these directions will return warnings in the returned result which you must display to the user.