How to compute direction between 2 locations - objective-c

Simmilar with Direction between 2 Latitude/Longitude points in C#
but with objective-c
Also I want a formula that works for large distance near the pole if it's possible.

You'll need the following complete but rather difficult stuff. A slightly easier description is found on wikipedia.

Or you could save yourself a lot of time and use CLLocation's distanceFromLocation method:
distanceFromLocation:
Returns the distance (in meters) from the receiver’s location to the specified location.
Discussion
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.
http://developer.apple.com/library/ios/DOCUMENTATION/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html#//apple_ref/occ/instm/CLLocation/distanceFromLocation:

Related

Formula/algorithm to offset GPS coordinations

I have GPS coordinates provided as degrees latitude, longitude and would like to offset them by a distance and an angle.E.g.: What are the new coordinates if I offset 45.12345, 7.34567 by 22km along bearing 104 degrees ?Thanks
For most applications one of these two formulas are sufficient:
"Lat/lon given radial and distance"
The second one is slower, but makes less problems in special situations (see docu on that page).
Read the introduction on that page, and make sure that lat/lon are converted to radians before and back to degrees after having the result.
Make sure that your system uses atan2(y,x) (which is usually the case) and not atan2(x,y) which is the case in Excell.
The link in the previous answer no longer works, here is the link using the way back machine:
https://web.archive.org/web/20161209044600/http://williams.best.vwh.net/avform.htm
The formula is:
A point {lat,lon} is a distance d out on the tc radial from point 1 if:
lat=asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
IF (cos(lat)=0)
lon=lon1 // endpoint a pole
ELSE
lon=mod(lon1-asin(sin(tc)*sin(d)/cos(lat))+pi,2*pi)-pi
ENDIF
This algorithm is limited to distances such that dlon <pi/2, i.e those that extend around less than one quarter of the circumference of the earth in longitude. A completely general, but more complicated algorithm is necessary if greater distances are allowed:
lat =asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
dlon=atan2(sin(tc)*sin(d)*cos(lat1),cos(d)-sin(lat1)*sin(lat))
lon=mod( lon1-dlon +pi,2*pi )-pi

Monte Carlo Integration

Does anyone have any ideas how to implement a monte carlo integration simulator in vb.net.
I have looked around the internet with no luck.
Any code, or ideas as to how to start it would be of help.
Well i guess we are talking about a 2 dimensional problem. I assume you have a polygon of which you want to calculate the area.
1) First you need a function to check if a point is inside the polygon.
2) Now you define an area with a known size around the polygon.
3) Now you need random points inside your known area, some of them will be in your polygon, some will be outside, count them!
4) Now you have two relations: First the relations of all points to points inside your polygon. Second the area around your polygon which you know, to the area of the polygon you don't know.
5) The relations is the same --> you can calculate the area of your polygon! (Area of polygon should be: points in you polygon / all your points * size of known area)
Example: 3 points hits hit the polygon, 20 points where "shot", the area of the polygon is 0.6m²
NOTE: This area is only an approach! The more points you have, the better the approach gets.
You can implement a fancy method to display this in your vb program of course. Was this what you needed? Is my assumption about the polygon correct? Do you need help with the "point inside polygon" algorithm?
There is nothing specific to VB.net with this problem, except maybe for the choice of a random number generator from the library.
Numerically solving integrals of a function f(x_1,...,x_n) by using can become infeasible (in acceptable time) for high dimensions n, because the number of sample points needed for a given sampling distance grows exponentially with the dimension of the problem. The fundamental idea with Monte Carlo Integration is to replace the uniform sampling of the variables x_1,...,x_n with random sampling, taking n random numbers per sample. With these samples, estimate the integral. The more samples, the better the estimate. And the major benefit of MC integration is, that you can use standard statistical methods to estimate the error of your result.
So, how to start: Implement integration by uniform sampling of the integration space, then go to random sampling and add error estimation.

Finding coordinates between longitude and latitude

How to find a few coordinates that are in the straight line, between 2 coordinates?
For example:
Start coordinate: Lat=X1 Long=Y1
End coordinate: Lat=X2 Long=Y2
Make a straight line from X1,Y1 to X2,Y2.
Then find 5 points that are located in that line, that are spread in the same distance.
Anyone can help to find the algorithm and calculation?
The coordinate is in decimal format, e.g. 50.123456, 6.123456
Thanks.
There are no "straight lines" on a sphere (or ellipsoid).
Anyway, you'll need to:
Calculate the distance and initial azimuth from (x1,y1) to (x2,y2).
You can use Vincenty's inverse method.
Calculate the coordinate of points with distance (0,25d, 0.5d, 0.75d) from (x1,y1) at that azimuth (plus points (x1,y1) and (x2,y2) of course).
You can use Vincenty's direct method.
Both direct and inverse methods are described on Wikipedia.
An extremely accurate implementations for both direct and inverse problems are available as part of GeographicLib.
Less accurate, but much simpler methods are described in Aviation Formulary.

Simplification / optimization of GPS track

I've got a GPS track produced by gpxlogger(1) (supplied as a client for gpsd). GPS receiver updates its coordinates every 1 second, gpxlogger's logic is very simple, it writes down location (lat, lon, ele) and a timestamp (time) received from GPS every n seconds (n = 3 in my case).
After writing down a several hours worth of track, gpxlogger saves several megabyte long GPX file that includes several thousands of points. Afterwards, I try to plot this track on a map and use it with OpenLayers. It works, but several thousands of points make using the map a sloppy and slow experience.
I understand that having several thousands of points of suboptimal. There are myriads of points that can be deleted without losing almost anything: when there are several points making up roughly the straight line and we're moving with the same constant speed between them, we can just leave the first and the last point and throw away anything else.
I thought of using gpsbabel for such track simplification / optimization job, but, alas, it's simplification filter works only with routes, i.e. analyzing only geometrical shape of path, without timestamps (i.e. not checking that the speed was roughly constant).
Is there some ready-made utility / library / algorithm available to optimize tracks? Or may be I'm missing some clever option with gpsbabel?
Yes, as mentioned before, the Douglas-Peucker algorithm is a straightforward way to simplify 2D connected paths. But as you have pointed out, you will need to extend it to the 3D case to properly simplify a GPS track with an inherent time dimension associated with every point. I have done so for a web application of my own using a PHP implementation of Douglas-Peucker.
It's easy to extend the algorithm to the 3D case with a little understanding of how the algorithm works. Say you have input path consisting of 26 points labeled A to Z. The simplest version of this path has two points, A and Z, so we start there. Imagine a line segment between A and Z. Now scan through all remaining points B through Y to find the point furthest away from the line segment AZ. Say that point furthest away is J. Then, you scan the points between B and I to find the furthest point from line segment AJ and scan points K through Y to find the point furthest from segment JZ, and so on, until the remaining points all lie within some desired distance threshold.
This will require some simple vector operations. Logically, it's the same process in 3D as in 2D. If you find a Douglas-Peucker algorithm implemented in your language, it might have some 2D vector math implemented, and you'll need to extend those to use 3 dimensions.
You can find a 3D C++ implementation here: 3D Douglas-Peucker in C++
Your x and y coordinates will probably be in degrees of latitude/longitude, and the z (time) coordinate might be in seconds since the unix epoch. You can resolve this discrepancy by deciding on an appropriate spatial-temporal relationship; let's say you want to view one day of activity over a map area of 1 square mile. Imagining this relationship as a cube of 1 mile by 1 mile by 1 day, you must prescale the time variable. Conversion from degrees to surface distance is non-trivial, but for this case we simplify and say one degree is 60 miles; then one mile is .0167 degrees. One day is 86400 seconds; then to make the units equivalent, our prescale factor for your timestamp is .0167/86400, or about 1/5,000,000.
If, say, you want to view the GPS activity within the same 1 square mile map area over 2 days instead, time resolution becomes half as important, so scale it down twice further, to 1/10,000,000. Have fun.
Have a look at Ramer-Douglas-Peucker algorithm for smoothening complex polygons, also Douglas-Peucker line simplification algorithm can help you reduce your points.
OpenSource GeoKarambola java library (no Android dependencies but can be used in Android) that includes a GpxPathManipulator class that does both route & track simplification/reduction (3D/elevation aware).
If the points have timestamp information that will not be discarded.
https://sourceforge.net/projects/geokarambola/
This is the algorith in action, interactively
https://lh3.googleusercontent.com/-hvHFyZfcY58/Vsye7nVrmiI/AAAAAAAAHdg/2-NFVfofbd4ShZcvtyCDpi2vXoYkZVFlQ/w360-h640-no/movie360x640_05_82_05.gif
This algorithm is based on reducing the number of points by eliminating those that have the greatest XTD (cross track distance) error until a tolerated error is satisfied or the maximum number of points is reached (both parameters of the function), wichever comes first.
An alternative algorithm, for on-the-run stream like track simplification (I call it "streamplification") is:
you keep a small buffer of the points the GPS sensor gives you, each time a GPS point is added to the buffer (elevation included) you calculate the max XTD (cross track distance) of all the points in the buffer to the line segment that unites the first point with the (newly added) last point of the buffer. If the point with the greatest XTD violates your max tolerated XTD error (25m has given me great results) then you cut the buffer at that point, register it as a selected point to be appended to the streamplified track, trim the trailing part of the buffer up to that cut point, and keep going. At the end of the track the last point of the buffer is also added/flushed to the solution.
This algorithm is lightweight enough that it runs on an AndroidWear smartwatch and gives optimal output regardless of if you move slow or fast, or stand idle at the same place for a long time. The ONLY thing that maters is the SHAPE of your track. You can go for many minutes/kilometers and, as long as you are moving in a straight line (a corridor within +/- tolerated XTD error deviations) the streamplify algorithm will only output 2 points: those of the exit form last curve and entry on next curve.
I ran in to a similar issue. The rate at which the gps unit takes points is much larger that needed. Many of the points are not geographically far away from each other. The approach that I took is to calculate the distance between the points using the haversine formula. If the distance was not larger than my threshold (0.1 miles in my case) I threw away the point. This quickly gets the number of points down to a manageable size.
I don't know what language you are looking for. Here is a C# project that I was working on. At the bottom you will find the haversine code.
http://blog.bobcravens.com/2010/09/gps-using-the-netduino/
Hope this gets you going.
Bob
This is probably NP-hard. Suppose you have points A, B, C, D, E.
Let's try a simple deterministic algorithm. Suppose you calculate the distance from point B to line A-C and it's smaller than your threshold (1 meter). So you delete B. Then you try the same for C to line A-D, but it's bigger and D for C-E, which is also bigger.
But it turns out that the optimal solution is A, B, E, because point C and D are close to the line B-E, yet on opposite sides.
If you delete 1 point, you cannot be sure that it should be a point that you should keep, unless you try every single possible solution (which can be n^n in size, so on n=80 that's more than the minimum number of atoms in the known universe).
Next step: try a brute force or branch and bound algorithm. Doesn't scale, doesn't work for real-world size. You can safely skip this step :)
Next step: First do a determinstic algorithm and improve upon that with a metaheuristic algorithm (tabu search, simulated annealing, genetic algorithms). In java there are a couple of open source implementations, such as Drools Planner.
All in all, you 'll probably have a workable solution (although not optimal) with the first simple deterministic algorithm, because you only have 1 constraint.
A far cousin of this problem is probably the Traveling Salesman Problem variant in which the salesman cannot visit all cities but has to select a few.
You want to throw away uninteresting points. So you need a function that computes how interesting a point is, then you can compute how interesting all the points are and throw away the N least interesting points, where you choose N to slim the data set sufficiently. It sounds like your definition of interesting corresponds to high acceleration (deviation from straight-line motion), which is easy to compute.
Try this, it's free and opensource online Service:
https://opengeo.tech/maps/gpx-simplify-optimizer/
I guess you need to keep points where you change direction. If you split your track into the set of intervals of constant direction, you can leave only boundary points of these intervals.
And, as Raedwald pointed out, you'll want to leave points where your acceleration is not zero.
Not sure how well this will work, but how about taking your list of points, working out the distance between them and therefore the total distance of the route and then deciding on a resolution distance and then just linear interpolating the position based on each step of x meters. ie for each fix you have a "distance from start" measure and you just interpolate where n*x is for your entire route. (you could decide how many points you want and divide the total distance by this to get your resolution distance). On top of this you could add a windowing function taking maybe the current point +/- z points and applying a weighting like exp(-k* dist^2/accuracy^2) to get the weighted average of a set of points where dist is the distance from the raw interpolated point and accuracy is the supposed accuracy of the gps position.
One really simple method is to repeatedly remove the point that creates the largest angle (in the range of 0° to 180° where 180° means it's on a straight line between its neighbors) between its neighbors until you have few enough points. That will start off removing all points that are perfectly in line with their neighbors and will go from there.
You can do that in Ο(n log(n)) by making a list of each index and its angle, sorting that list in descending order of angle, keeping how many you need from the front of the list, sorting that shorter list in descending order of index, and removing the indexes from the list of points.
def simplify_points(points, how_many_points_to_remove)
angle_map = Array.new
(2..points.length - 1).each { |next_index|
removal_list.add([next_index - 1, angle_between(points[next_index - 2], points[next_index - 1], points[next_index])])
}
removal_list = removal_list.sort_by { |index, angle| angle }.reverse
removal_list = removal_list.first(how_many_points_to_remove)
removal_list = removal_list.sort_by { |index, angle| index }.reverse
removal_list.each { |index| points.delete_at(index) }
return points
end

calculating new gps coordinates given initial coordinate and *Small* range

I'm trying to figure out how to calculate a min/max lat/long bound on the specific given range of a gps coordinate.
for example: gps coord 37.42935699924869,-122.16962099075317 range .2 miles
I'm looking at the point + range + bearing in the http://www.movable-type.co.uk/scripts/latlong.html site but im not sure if this is exactly what i want.
This gives 4 unique lat/long pairs and I want/need a max/min lat and a max/min long.
Calculate the distance between the (constant) central point and the point you want to test. (This page should give you the distance (in meters)).
If (distance < 0.2) then ...
Well, given a point and a distance, you will get a circle.
You're looking for two points, which will essentially describe a square (two opposite corners). The two points you're looking for won't even be on the circle. I'm not exactly sure why you want this, but I don't think there is an answer to your question.
Perhaps you could tell us what you're trying to accomplish.
EDIT: Added image to illustrate. The orange line is the distance from the centre (e.g. 0.2 miles)
alt text http://img155.imageshack.us/img155/1315/diagramp.png
After your clarification, here is a less elegant answer that might give you what you want. Well, you want the inverse of a really complicated function. I'm afraid my math skills aren't up to the task, but it should be doable.
A less elegant solution is to find it by trial and error. Essentially, keep longitude the same and vary latitude. Using the right algorithm, you should be able to find one that is very close to the distance you want. This will give you a point on the circle (one of four that is also on the square).
Then keep latitude the same and vary longitude. This will give you a second point on the square (on the middle of one of the sides), from there you can find the 4 corners of the square.
This will slow, depending on how often you have to do it, that might or might not matter.