I have an application where I should have the driving time between a point A and a set of points. I have the GPS coordinates of all these points.
I tried to do the job using google maps directions api, but the problem is that the program must wait for a minimum of 1 second between two consecutive requests, so if the destination set contains 40 points I should wait 39 seconds before getting all the answers.
This part of the program is critical so 39 seconds will be a very long time.
Is there any other api that I can use for this?
Note that I'm not interested in detailed directions or distance, the total travel time will be enough, I can later use google directions on the best answer to get these details.
Thanks!
There's Walk Score's Travel Time API which seems to offer just that
The Travel Time API rapidly calculates travel times between an origin and a set of destinations. The distance calculator uses ... driving distance ...
Related
I am trying to measure changes in altitude with an Apple Watch in a sport activity (Kite Surfing). Currently my App is just collecting data for analysis. I am recording barometric and GPS altitude for comparison at a frequency of 10 measurements per second. Basically, it works and data is recorded, but it seems these data are just worthless. In both measurements there are sudden jumps in the dataset of up to +-10m and spikes in GPS readings of up to 75m. Does anyone have an idea how to get somehow accurate readings? I basically do not care about absolute altitude; I am just interested in the change of altitude.
Use startRelativeAltitudeUpdates(to:withHandler:) and when your done remember to stopRelativeAltitudeUpdates()
Here is a link to doc.
Also you can ignore anomalies. for example: if the max possible change in altitude in 100 milliseconds is 2 meters (72 km/h). Then if you see any changes more than 2 meters in 100 millisecond just ignore the data and wait for the next reading.
remember when you ignore one reading to account for the time difference.
I'm running into an odd problem using the snap to route feature of the Bing Maps REST API. It works great for most of the GPS coordinates I send it -- they were recorded by me on a recent motorcycle trip, so they're "contiguous" -- but fails silently for others.
As in, the returned status code is 200...but rather than returning SnapToRoadReponse objects it returns Route objects. Which lack any of the snapped-to coordinates I need.
What's particularly interesting is the problem occurs in the middle of processing the entire route. In other words, it works fine for 6 or so invocations (each with around 100 points), fails for a number of invocations, and then works fine for the remaining invocations.
Is there a rate limit on how frequently you can access the snap-to service? I'm using just a basic Bing Maps account but could program around rate limitations easily enough (e.g., by waiting beyond invocations). But I couldn't find reference to such in the documentation I reviewed.
Or maybe Bing Maps just doesn't like the hills east of Santa Rosa and the 101 corridor south from there other the Golden Gate Bridge... :)
Turns out the problem was sending too many points through the request pipeline. The Bing Maps REST API requires/strongly advises not to use GET requests involving more than 100 geographic points. I assumed the Bing Maps REST Toolkit took care of ensuring larger requests were done as POSTS. It does not, however, appear to do that.
Reducing the number of geographic points to no more than 100 per request solved the problem.
The portion of my route which was causing problems involved high speed freeway travel, which caused my code to interpolate additional points for each set of observed data points so as to ensure no two points were more than 2.5 kilometers apart (that's a Bing Maps hard limit). That drove the total number of points for each request along that stretch of the route to over 100 points, causing the problem I encountered.
I am trying to retrieve current speed limit of a given road location data is passed to the Open Street Maps api every 2-3 seconds as the vehicle is in motion.
I have tried the code below using [around] however it only outputs results when the radius is at least 2500 metres
i am seeking to have a an area that is closer to 10 meters to determine the current speed limit of the vehicles location.
If there is an alternative endpoint to achieve the above so that is more robust and responsive please advise
i am basically wanting to replicate what i see on navigation apps where the speed limit value updates within 1-2 seconds of a vehicle passing a new speed sign of value different to the previous speed zone being driven in
I would appreciate any assistance to resolve this issue.
https://lz4.overpass-api.de/api/interpreter?
data=[out:json];nodemaxspeed;out%20meta;
I realize the answer will most likely vary based on the desired accuracy. I'm most interested in 3km accuracy (kCLLocationAccuracyThreeKilometers), but data for the other levels would also be useful.
I'm suppose I'm not exactly looking for the average time, but the point in time that I should move on and assume I'm not going to get any more accurate locations. In my use case, the GPS coordinates are not essential to my app, but highly useful.
At that distance, it is unlikely GPS will be used, as the OS will opt for cell tower or wifi triangulation. Therefore, the time is likely to be less than 42 seconds, which seems very high in its own right.
Although I have no specific data on this, I have observed - through testing our own app - that geolocation takes approximately between ten and twenty seconds.
to all i want to know why location manager in iphone gives wrong coordinate at first time when run application.Due to this my distance is come 100 meter at start of application and my average speed is also effected due to this
Each location you receive will have a horizontal accuracy. If the accuracy is above some threshold, say 10 meters, then disregard it. It will take longer to get an accurate read. A negative accuracy means unknown and should also be discarded.
You could also keep your current logic, but reset all data the first time the accuracy is below your threshold. You will still be disregarding inaccurate data, but you can give the user some initial feedback the way map programs do.
Which approach to use depends on your application.