I am building a location based app where users can see distance to other users. What decimal place should I round longitude and latitude to to avoid making it possible for users to triangulate the position of other users? I am not sure what a "reasonable level of uncertainty" for other user's position is.
Round Long/Lat to vary degrees of decimal places to introduce error. Hundredths is a good answer, since on average long/lat lines are .69 miles apart, thus introducing an average .69x.69 square mile error.
You can also use a custom geohashing system to build your own designated shapes to lump points into. Geohashes are better near the poles because they don't risk their area going to zero as the system with long/lat does because latitude lines have a distance of close to zero near the poles, which potentially poses a security risk there for triangulation.
At the end of the day, for a consumer app that nobody is going to use at the poles, rounding seems sufficient.
Related
perhaps this is a simple question.
I have 3 GPS coordinates (one is the current user location). What I want now is to calculate the angle between the user location and the two GPS coordinates. Imagine the user location in the center of the two other points, the three points can be seen as a triangle. And I want to calculate the angle at the user location.
I hope someone can help me because I have no idea how to do this with spherical coordinates like the GPS coordinates I have.
THX - nekro
For short distances (less than 100km, say) you can safely ignore the spherical nature of the calculation and treat the problem as a 2 cartesian coordinate problem. For large distances the spherical geometry gets pretty gnarly. I could probably figure it out, but I don't want to think that hard right now.
Edit:
All you need to do is to convert both coordinates to KM, and then treat it as a cartesian problem. (At a small scale, you can ignore the curved nature of the "lines" and treat them as normal cartesian grid lines, since the curvature is small enough to ignore at that scale)
The distance per degree of latitude is constant. The distance for a degree of longitude changes based on latitude.
Do a google search on "KM per degree of longitude" and find a link that explains it clearly. Here's one: http://www.colorado.edu/geography/gcraft/warmup/aquifer/html/distance.html
You could use thessien polygons and calculate the geometry on those from a strictly GIS perspective. If you have qgis or arcgis this should be fairly simple. These packages offer APIs which might suit your needs.
You're essentially doing two calculations (bearing to (or from) current position to two other positions) and not crosstrack (distance from a great circle line between to other points).
However, both can be found in Ed William's Aviation Formulary which has the most comprehensive collection of formulas for spherical calculations I've found.
You would be looking for "Course between points" which is listed as:
tc1=mod(atan2(sin(lon1-lon2)*cos(lat2),
cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon1-lon2)), 2*pi)
I have a list of latitude and longitude values in a database. Based on a user’s location I need to extract the closest location from the database based on walking distances. For this purpose, I need to first get all values from the database into an array and then calculate WALKING distances to each and then return the lat/long of the shortest distance.
Note: I have no problem extracting the database values. I need help with the calculation of walking distances between 2 points.
I have so far found threads here which either show straight line distances. Is there any way to get walking distances between 2 points? If so, I would appreciate if you could point me in the right direction (link/previous question) or provide some guidance on what classes or functions to use.
You can get the distance in meter using the
CLLocationDistance distance = [locationOne distanceFromLocation:locationTwo];
you can acoordingly convert it into CentiMeter or Kilometer, this may serve your purpose
I frequently use the distanceFromLocation method for CLLocation objects to get their distance from other locations. Enumerating through an array of CLLocations, I then compare each to my reference location using this method.
I'm curious to know the processing/memory implications for using distanceFromLocation, especially for a large number of CLLocation objects in succession. How does this method work - does it connect to the server to get the data, or does it calculate the distance based on some mathematical formula, such as the Haversine Formula?
Is there a more efficient method to compare distances between 1 reference location and an array of CLLocation objects?
They are likely are using the Spherical Law of Cosines instead of the Haversine (why? see this question).
If all you want to do is compare many points against one point to see which is closest, then maybe you don't care about the accuracy of the computed distance and just about performance. In that case perhaps using Pythagoras' theorem would work for you.
All of these algorithms are detailed on this web page, which says in part:
If performance is an issue and accuracy less important, for small
distances Pythagoras’ theorem can be used on an equirectangular
projection:*
You could implement a function using Pythagoras' theorem then benchmark it against the one in CLLocation and against my implementation of distanceInMetersFromRadians that uses the Spherical Law of Cosines to see how much performance difference there is.
From the documentation:
distanceFromLocation:
This method measures the distance between the two locations by tracing a line between them that follows the curvature of the Earth. The resulting arc is a smooth curve and does not take into account specific altitude changes between the two locations.
So yes, I assume it is using the Haversine Formula (or a modification of it).
Have you used Instruments and measured it? Until you have done, it's pointless.
You can take shortcuts. Let's say you want the nearest point. Find a formula that gives you roughly the right result. Usually there's a square root involved, so get a formula for the square of the distance - that's quicker and works just as well. Find the nearest point with your formula. Now say the nearest point is 178.96 meters apart according to your formula. You can then check all points that are say less than 180 meters away with the exact formula.
For small distances and on iOS 9, I have found that the values obtained by distanceFromLocation are reliably close to those found by the Vincenty formula using the WGS-84 ellipsoid. In my experience, they are accurate within about 7 or 8 significant figures.
A spherical model, such as the law of cosines or the Haversine formula, does not compare well for small distances.
For more information, see the geopy documentation and a table of values for comparison.
I'm starting a project where I am mapping a set of points on the Earth using google maps. I want to find the point on the globe which is the average (shortest total distance to all points), but I'm unsure how to handle it considering the distance may be shorter going the other way around the earth. (-178 degrees to 178 degrees longitude is only 4 degrees longitude apart, not 356). What is the best way to approach this, either via an api call or from a mathematical perspective?
I highly doubt there is a slick geometric argument giving a closed form expression for the desired point. Nonetheless here's a simple-minded algorithm which gives an answer to within any desired precision:
https://gist.github.com/amitkgupta/5019163
If you want a mathematically more satisfying solution, I recommend asking over at http://math.stackexchange.com, or they don't avail you, escalate it to http://mathoverflow.net.
I can suggest simple and fast solution (but not to exact initial task). Find the center of gravity of points, then there may be 2 situations:
it's located at center of sphere - don't know what to do (if initial points distributed close to each other - this will not happen)
in other case - consider vector with center of mass and center of sphere as finish and start points, find where such vector intersects surface of sphere, that point - is the answer.
So, you'll get point somewhat similar to 'mid-point', but only in cases when surface under consideration is very small (may be all point lay within the same city). But it is also has nothing to do with minimal average distances from result to initial points.
When an iOS application requests the user's current location, to how many significant figures are the latitude and longitude values returned?
Just looking for the maximum no. of digits for database constraints.
There's no real answer to this. Among other reasons, the accuracy returned by CoreLocation varies and the conversion from degrees to linear distance depends on location.
At this point, I think the lowest accuracy I've seen returned by CoreLocation is 5 meters but in theory this could get better with time.
Wikipedia has a table of conversion from degrees to linear distance at the equator. Six fractional digits gets you down to 10 cm at the equator which is probably higher than the phone is going to provide in the foreseeable future. Five digits gets you to 1 meter but it's not too hard to imagine a future device besting that.