I've got courier tracking android app, which posts every 30s gps coords of the courier to a postgis database.
We need to calculate how many kilometers couriers do in order to provide them gas(petrol) refund.
How would you do that, fellow developers?
Sum the great-circle distances between consecutive measurement points to get an approximation (lower bound actually) for the distance traveled.
You can probably also get away (and get better numerical stability) with calculating the 3D ECEF positions from the spherical coordinates and summing the Euclidean distances between these points because it's pretty much impossible to cover a significant curvature on Earth in 30 seconds.
Related
I want to calculate distances between two coordinates but sometimes the origin coordinate is over / beyond the destination coordinate. And it is really problematic at one-way roads, because in this case the distance can be eg. 1 km to get back to the destination. In real life it is OK, but actually the real distance is only eg. 10 meters (if I could turn back on one-way roads). So only the direction is wrong.
I can resolve this problem if I call the API twice (origins=my_origin_coordinate&destinations=my_destination_coordinate and origins=my_destination_coordinate&destinations=my_origin_coordinate).
But is there a easier way to get both distance in one query? (to save my query limit...)
The distance matrix allows multiple results in a single query. You can do origins=my_origin_coordinate|my_destination_coordinate&destinations=my_origin_coordinate|my_destination_coordinate in a single request, which will give you both results. That won't really help with your quota though as the quota is based on "elements", and whether you do it in one query or two, it will be the same number of "elements".
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 a list of about 3000 points (lon,lat) and I need to create an application to find for any given position on map (lon, lat) all points from this list, which are reachable in 10 minutes by car.
I can easily calculate this task for distance in metres, eg. all points inside a circle, but I need to do it using duration in minutes, not distance in metres.
Which part of Google Maps API should I use?
It looks like you'll need to use the Google Distance Matrix. However, because of the limits, you'll probably need to get crafty with filtering the list of possible locations before sending the request.
100 elements per query.
100 elements per 10 seconds.
2,500 elements per 24 hour period.
You are trying to create a isochrone map
I would suggest something like this (a v2 example by Marcelo). The original is gone, here is a copy, and a version ported to the v3 API.
Start by drawing a circle (or not, but conceptually) with a radius that is greater that 10 minutes driving time (10 miles should work). Find all the points in your database in that circle (that are less than the radius/10 miles from the center point).
This should narrow down your points to a manageable number. Use the DistanceMatrix to further refine the number, eliminating those that are within the circle but greater than 10 minutes away.
proof of concept
uses the places search for locations, pares down the results to those in a 10 mile radius, then sends those results to the DirectionsMatrix, discarding any results with a duration of greater than 10 minutes.
I have mysql query to calculate distance between given longitudes and latitude within 50 meter radius. Here I want to know that by performance, speed and distance accuracy wise which one is better, haversine or pythagorean?
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.