Finding distance between two points using latitude and longitude in Degree Minutes Seconds format - distance

I am working on a tool to find the distance between two points whose latitude and longitude are given. Its ok when the latitude and longitude is given in Signed Degree Format. But I couldn't find a way to calculate the distance when latitude and longitude is given in Degree Minutes Seconds Format (ex: N 11° 14' 52').Can anybody suggest me a way to find the distance ?

So first convert the DMS coordinates to your degree format.
e.g. 11°14'52" = 11 + 14/60 + 52/3600 = 11.24777778 degrees
and then continue as you did with your destance calculation that you say already works.
Edit:
Note that latitudes in the southern hemisphere and longitudes in the western hemisphere are negative. So the above formula really should be:
sign(degrees) * (abs(degrees) + minutes/60 + seconds/3600)

Related

Calculating longitude distortion on approach to poles?

I'm working on a game in which players are trying to target points on a sphere.
As targets approach the poles, the game should become more forgiving in longitude because the ratio of longitude distance to latitude distance grows. At the poles, the game should be infinitely forgiving in longitude.
What formula am I looking for that tells me how much longitudinal distance equals 1 unit of latitudinal distance for a particular latitude? Assume that longitude and latitude are expressed as floats ranging from 0-1, and at the equator (0.5) longitude equals latitude.
Formula is rather simple (for usual spherical coordinates with -Pi/2..Pi/2 latitude range):
Lon_Lat_Ratio = Cos(Latitude)
But your parametrization is different, so
Lon_Lat_Ratio = Sin(Latitude_01 * Pi)
Ratio is 1 on equator and 0 at poles

Calculate longitude on the 0 degree latitude line, knowing the starting point (latitude,longitude) and azimuth on ellipsoid Earth model

Input:
Observer (Lat,Lon WGS84 coordinates) and an azimuth angle (degrees)
Output:
By considering only the 0 degrees latitude line, I am trying to get the intersection longitude point from the observer point with the given azimuth. I am considering the ellipsoid Earth model.
If you have the Mapping Toolbox available, you can use the track1 function. See the Mathworks documentation at http://www.mathworks.com/help/map/ref/track1.html?refresh=true.
Basic formula is
lon(lat, lon, Z) = lon - atan(sin(lat)*tan(Z))
(Beware that your calculator uses degrees)

Plot points by Latitude and Longitude in Highmaps

I am trying to plot missing countries on the Highmaps world high resolution map. However it is difficult to get the correct co-ordinates.
It appears this may be difficult because the charts do not correspond with latitude and longitude. For example world high-resolution has 1750 points on the X axis, so half is 875, but GMT is at about 839.
Ideally I am looking for a formula that can be used to convert latitude and longitude to x/y, but do not know how to do this.

Convert Latitude / Longitude in Degree/Radians?

How can i convert Latitude and longitude in degree/radians?
Do you guys any formula or any idea?
I want to show it on MapKit.
Thanks.....
Since Latitude and Longitude are measured in degrees, you can use the following formula to convert to radians, and back to degrees:
Radians = Degrees * PI / 180
and on the inverse,
Degrees = Radians * 180 / PI
If you look at earth like a sphere, latitude and longitude are already given in units of degrees. Longitude is expressed as -180 degrees (-pi radians) to 180 degrees (pi radians) with 0 degrees centered at the prime meridian. Latitude is expressed as -90 degrees (-pi/2 radians) to 90 degrees (pi/2 radians) with respect to the equator. This is already a spherical coordinate system (depending on the caveats I give below) with earth's radius approximately 6371 km.
So just convert by multiplying by pi/180 as you would for convert degrees to radians in any normal sense. If you want to use those radians for doing something specific like calculating distances between two lat/lons then you should look at some pre-existing sources.
Similar questions have been asked before, i.e. Convert Lat-Lon to Cartesian Coordinates.
Generally speaking, the 'correct' answer for a lot of conversion quesitons depends on what error is acceptable in your answer (can it be off 1 mile for distances of 20 miles, etc.) and the model of the world is appropriate in your problem domain. The world is better approximated by an ellipsoid (squashed sphere) than a sphere, but it is easier to perform the calculations assuming earth is a sphere and the error introduced can be minimal. Especially if your program is just looking for 'rough' answers that won't be used for, say, engineering projects.
It is likely that the lat-lons you have are given in a coordinate system called WGS-84 which is what most hardware GPS units use, which assumes an ellipsoid model.
Note that I had a lot more sources, but I guess I have low reputation so I can only post two links. I would suggest reading on wikipedia about WGS-84, earth's radius, spherical coordinates, prime meridian, and equator for some visual references.

How to calculate Cross-Track error (GPS/Core Location)

Does anyone know how to determine determine the "Cross-Track Error"?
For those who are unfamiliar: You are driving along a line from Point "A" to point "B". When in transit, when you veer off that line, the distance from your current position to the line is the cross-track error.
I have a simple algorithm now which works, using basic geometry with the latitude and longitude of the three points - the problem is that it does not take "great circle" calculations into account (i.e. actual meters-per-degree longitude varies depending on your latitude, and does not equal that of the latitude).
In other words - if you know of a "great circle" formula for determining this, please let me know - but it is not a straight Cartesian geometry problem.
Brad,
I'm not sure which ellipsoid model you are using since you don't say. If you aren't using an ellipsoid model in you current calculations, you may find this helpful:
http://www.movable-type.co.uk/scripts/latlong-vincenty.html
The Vincenty algorithm is more accurate that the Haversine algorithm.
Once you have accurate distances for A-B, A-C and B-C, it should be straightforward to determine your distance from C to the line A-B. Something like a binary search of the distances from points on A-B to C, looking for the shortest value.
James
This is this text from the link to the accepted answer - should it go dead:
Here’s a new one: I’ve sometimes been asked about distance of a point from a great-circle path (sometimes called cross track error).
Formula: dxt = asin( sin(δ13) ⋅ sin(θ13−θ12) ) ⋅ R
where:
δ13 is (angular) distance from start point to third point
θ13 is (initial) bearing from start point to third point
θ12 is (initial) bearing from start point to end point
R is the earth’s radius
JavaScript:
var δ13 = d13 / R;
var dXt = Math.asin(Math.sin(δ13)*Math.sin(θ13-θ12)) * R;
Here, the great-circle path is identified by a start point and an end point – depending on what initial data you’re working from, you can use the formulas above to obtain the relevant distance and bearings. The sign of dxt tells you which side of the path the third point is on.
The along-track distance, from the start point to the closest point on the path to the third point, is:
Formula: dat = acos( cos(δ13) / cos(δxt) ) ⋅ R
where:
δ13 is (angular) distance from start point to third point
δxt is (angular) cross-track distance
R is the earth’s radius
JavaScript:
var dAt = Math.acos(Math.cos(δ13)/Math.cos(dXt/R)) * R;
If dealing with latitude and longitude, the forumla you're looking for is the "Haversine" formula. It takes into account the curvature of the earth's surface.
http://en.wikipedia.org/wiki/Haversine_formula
Good luck.
The CLLocation API provides
- (CLLocationDistance)distanceFromLocation:(const CLLocation *)location
Which uses a formula (it does not specify whether is it Haversine or
Vincenty or other) that takes into account the curvature of the earth. This returns the distance in meters between the 2 CLLocations but does not account for any difference in altitude.