Given the following input:
known longitudes/latitudes of 1..n locations
known distance between locations 1..n and another location "m"
How can I calculate the longitude/latitude of the location "m"?
This sounds like a basic latitude-longitude triangulation question. The common approaches are outlined in a Yahoo! Answers topic here. There are likely libraries to do this in many languages. A google search for "latitude longitude triangulation" plus your language of choice will likely reveal some existing code to use. "Geocoding" is another common task rolled into similar libraries, so that may be another useful keyword.
Edit: As others have mentioned, "trilateration" seems to be the best term. However, depending on your data and requirements, there are simpler approximation solutions that may satisfy your requirements.
The Yahoo! Answers post is quoted below for convenience:
"For larger distances, spherical
geometry. For relatively small ones,
treat the earth as flat, and the
coordinates as xy coordinates. For the
distances to work with the degrees of
the coordinates, you will have to use
the cosine function to convert from
one to the other. (While degrees of
latitude are about 69 miles all over
the earth, degrees of longitude vary
from the same at the equator to 0 at
the poles.)
You have the center points of three
circles and the radius of those
circles. They are supposed to
intersect at one point, so you can
treat them in pairs to find the
intersection points of each and throw
out the ones that don't match
http://mathworld.wolfram.com/Circle-CircleIntersection.html."
(mike1942f)
Trilateration is what you want. This only requires 3 of your reference points, however the rest can be used to increase accuracy if you want to get really clever.
The trickiest part is working with long/lat as opposed to Cartesian coordinates, especially as the earth is not a perfect sphere.
This is a trilateration problem. In your case, you have multiple points of reference, so you can minimize the sum of squared-errors between the given distances and those corresponding to the optimal position of m.
Related
I have data of locations of thousands of sensors in MySQL. I want to identify the sensor closest to the user's location and show that specific sensor's data. All the location data is available as lat lng.
I understand that one approach can be to find displacements between the origin and all the sensors using Haversine formula and select the one with the shortest distance. The problem here is that there are tens of thousands of sensors.
Any suggestions/leads?
Spatial index allows efficient query of points within any specific distance. The problem of course is one might not know the search radius needed in specific case. Unfortunately, a large radius causes inefficient queries, and a small radius might result in no match at all.
A possible solution is to search with increasing radius, until the search returns some results, and then find the closest result among those.
This article describes this solution for BigQuery, would require some adaptation for MySQL script dialect:
https://mentin.medium.com/nearest-neighbor-using-bq-scripting-373241f5b2f5
Not the MySQL answer you are looking for but Postgresql's popular PostGIS extension has an inbuilt K Nearest Neighbor operator class). Also, see its documentation. It works great!
Also, I am aware of this Go library that allows you to do KNN in memory after building a Quadtree with your sensor locations.
For only thousands, a simple bounding box with two 2-column indexes may be fast enough.
For better speed, see SPATIAL indexing.
For details on those two solutions, plus two faster ones, see Find Nearest
Which is better for calculating the distance between two latitude/longitude points, The Haversine Formula or The Vincenty's Formula? Why?
The distance is obviously being calculated on Earth. Does WGS84 vs GCJ02 coordinates impact the calculation or distance (The Vincenty's formula takes the WGS84 axis into consideration)?
For example, in Android, the Haversine Formula is used in Google Map Utils, but the Vincenty Formula is used by the android.Location object (Location.distanceBetween()).
Haversine and Vincenty are two algorithms for solving different
problems. Haversine computes the great circle distance on a sphere
while Vincenty computes the shortest (geodesic) distance on the surface of an
ellipsoid of revolution. So the answer to your question can be broken
into 2 parts:
Do you want to compute the distance on a sphere on an ellipsoid?
How accurate is Haversine or Vincenty at calculating the given problem?
For terrestrial applications, an ellipsoid of revolution is a reasonable
approximation to "mean sea level"; the error is ± 100 m. The
flattening of this ellipsoid is small, about 1/300, and so can be
approximated by a sphere (of equal volume, for example).
Great circle distances differ from geodesic distances by up to 0.5%. In
some applications, e.g., what's the distance from the Cape to Cairo?,
this error can be neglected. In other applications, e.g., determining
maritime boundaries, it is far too large (it's 5 m over a distance of 1
km). In general, you're safer using the geodesic distance.
If you're interested is distance traveled (by car, boat, or plane),
there are lots of constraints on the path taken and neither the great
circle or geodesic distance, which measure the length of shortest paths
on an ideal surface, would be appropriate.
On the question of whether the algorithms are accurate:
Haversine is accurate to round-off unless the points are nearly
antipodal. Better formulas are given in the
Wikipedia article on great-circle distances.
Vincenty is usually accurate to about 0.1 mm. However if the points are
nearly antipodal, the algorithm fails to converge and the error is
much larger. I give a better algorithm for solving the geodesic problem
in Algorithms for geodesics. See also the
Wikipedia article on geodesics on an ellipsoid.
Solving the geodesic problem is slower than solving for the
great-circle. But it's still very fast (about 1 μs per calculation), so
this shouldn't be a reason to prefer great circle distances.
ADENDUM
Here is the Java package which implements my algorithm
for finding geodesic distances. Unlike Vincenty's method, this is accurate
to round-off and converges everywhere.
Haversine is a simpler computation but it does not provide the high accuracy Vincenty offers.
Vincenty is more accurate but is also more computationally intensive and will therefore perform slower and increase battery usage.
As with anything "better" is a matter of your particular application. For your application, Vincenty may be a "better" choice than Haversine, but for a different application, Haversine may be a better choice. You will have to look at the particulars of your use cases and make a determination based upon what you find there.
I have around 200k latitude & longitude data points. How can I cluster them so that each clusters have latitude & longitude points strictly within radius = 1 km from centroid only?
I tried leadercluster algorithm/package in R but eventhough I specify radius =1 km its not strictly enforcing it i.e. its give clusters with lot of point say 5 - 10 kms from cluster centroid also within the same cluster. So its not meeting my requirement.
Number of points in a cluster can vary & its not problem.
Is there a way to enforce the strict radius constraint in heirarchical or another clustering algorithm? I am looking for the steps & implementation in R/python.
I tried searching in stackoverflow but couldn't find a solution in r/python.
How to visualize cluster centroids in google maps after the clustering in done?
EDIT
Parameters I am using in ELKI. Please verify
This is not so much a clustering, but a set cover type of problem. At least if you are looking for a good cover. A clustering algorithm is about finding structure in your data; but you are looking for some forced quantization.
Anyway, here are two strategies you can try e.g. in ELKI:
Canopy preclustering with T1=T2=your radius. This should yield a greedy approximation to the cover scenario.
Complete linkage hierarchical agglomerative clustering, cut at the desired height. This is fairly expensive (O(n^3)). Any two points in the same cluster have at most this distance, so this is a bit stricter than your requirement.
Beware that you should be using haversine ("geo") distances, not Euclidean!
I am looking for a way to get the nearly geo positions from one geo position. I can calculate the difference from two position, but I need to find all geo positions from a point with a radius of 10-20 miles. I find a similaire on flickr:
http://m.flickr.com/#/nearby/
Anybody an idear how it works? They must convert a latitude and longitude to a unique value and must find all entries nearly this position or something else.
Thanks for help!
You might use Voronoi Diagrams, but probably pre-sorting your data by each coordinate (separately) and then finding an intersection of point sets which lay nearby for each of coordinates would solve your problem easier.
A point location data structure can be built on top of the Voronoi diagram in order to answer nearest neighbor queries, where one wants to find the object that is closest to a given query point. Nearest neighbor queries have numerous applications.
You can use a kd-Tree. Some time ago I tried this one and it worked quite well:
https://github.com/jmhodges/kdtree2
Use a (point-)quad tree, or k-d tree, or if the number of points is not high, you even could use a brute force search.
Do not use voronoi diagrams. They are one of the most complex algos to implement.
I would like to store thousands of latitude/longitude points in a MySQL db. I was successful at setting up the tables and adding the data using the geospatial extensions where the column 'coord' is a Point(lat, lng).
Problem:
I want to quickly find the 'N' closest entries to latitude 'X' degrees and longitude 'Y' degrees. Since the Distance() function has not yet been implemented, I used GLength() function to calculate the distance between (X,Y) and each of the entries, sorting by ascending distance, and limiting to 'N' results. The problem is that this is not calculating shortest distance with spherical geometry. Which means if Y = 179.9 degrees, the list of closest entries will only include longitudes of starting at 179.9 and decreasing even though closer entries exist with longitudes increasing from -179.9.
How does one typically handle the discontinuity in longitude when working with spherical geometries in databases? There has to be an easy solution to this, but I must just be searching for the wrong thing because I have not found anything helpful.
Should I just forget the GLength() function and create my own function for calculating angular separation? If I do this, will it still be fast and take advantage of the geospatial extensions?
Thanks!
josh
UPDATE:
This is exactly what I am describing above. However, it is only for SQL Server. Apparently SQL Server has a Geometry and Geography datatypes. The geography does exactly what I need. Is there something similar in MySQL?
How does one typically handle the discontinuity in longitude when working with spherical geometries in databases?
Not many people use MySQL for this, because it's geospatial extensions aren't really up to snuff.
From the docs:
"All calculations are done assuming Euclidean (planar) geometry."
The solution is usually to roll your own.
Alternatively, you can fake it -- if your distances are less than a 500 miles or so, then you can treat your latitude and longitude as rectangular coordinates and just use the euclidean distance formula (sqrt(a^2 + b^2)).