# Tag Info

85

Just look at the path on the sphere. Here it is in Google Earth: The path on your map is strongly curved because your map uses a projection with lots of distortion. (The distortion grows without bound towards the poles and this path is getting close to the north pole.) Edit The distortion is necessary to explain the curvature of this geodesic on the ...

60

In short, the distance can be in error up to roughly 22km or 0.3%, depending on the points in question. That is: The error can be expressed in several natural, useful ways, such as (i) (residual) error, equal to the difference between the two calculated distances (in kilometers), and (ii) relative error, equal to the difference divided by the "correct" (...

55

If your displacements aren't too great (less than a few kilometers) and you're not right at the poles, use the quick and dirty estimate that 111,111 meters (111.111 km) in the y direction is 1 degree (of latitude) and 111,111 * cos(latitude) meters in the x direction is 1 degree (of longitude).

40

The problem is indicated by the word "well-conditioned." It's an issue of computer arithmetic, not mathematics. Here are the basic facts to consider: One radian on the earth spans almost 10^7 meters. The cosine function for arguments x near 0 is approximately equal to 1 - x^2/2. Double-precision floating point has about 15 decimal digits of precision. ...

32

As Liedman says in his answer Williams’s aviation formulas are an invaluable source, and to keep the accuracy within 10 meters for displacements up to 1 km you’ll probably need to use the more complex of these. But if you’re willing to accept errors above 10m for points offset more than approx 200m you may use a simplified flat earth calculation. I think ...

26

UTM uses a transverse Mercator projection with a scale factor of 0.9996 at the central meridian. In the Mercator, the distance scale factor is the secant of the latitude (one source: http://en.wikipedia.org/wiki/Mercator_projection), whence the area scale factor is the square of this scale factor (because it applies in all directions, the Mercator being ...

21

In this projection (Google Mercator), that's what the great circle arc between those two places looks like.

21

I investigated exactly this question 20 years ago when designing a desktop GIS. We needed to find point-to-point distances interactively; our target was to do the computations in less than 1/2 second for thousands of points. Testing (on a 25 MHz 486 PC!) showed that we could compute all the distances, exactly as you describe (with the simple obvious ...

18

Using the Pythagorean formula on positions given in latitude and longitude makes as little sense as, say, computing the area of a circle using the formula for a square: although it produces a number, there is no reason to suppose it ought to work. Although at small scales any smooth surface looks like a plane, the accuracy of the Pythagorean formula depends ...

16

I find that Aviation Formulary, here is great for these types of formulas and algorithms. For your problem, check out the "lat/long given radial and distance":here Note that this algorithm might be a bit too complex for your use, if you want to keep use of trigonometry functions low, etc.

16

It's not much harder on the sphere than on the plane, once you recognize that The points in question are the mutual intersections of three spheres: a sphere centered beneath location x1 (on the earth's surface) of a given radius, a sphere centered beneath location x2 (on the earth's surface) of a given radius, and the earth itself, which is a sphere ...

14

A fast and informative way is to create a distance grid based on the roads. This is usually done in a projected coordinate system, which necessarily introduces some error, but by choosing a good coordinate system the error will not be too great (and can be corrected). The following example defines a "road" as a US Interstate or US or state highway of ...

13

Manually reversing the rotation should do the trick; there should be a formula for rotating spherical coordinate systems somewhere, but since I can't find it, here's the derivation ( ' marks the rotated coordinate system; normal geographic coordinates use plain symbols): First convert the data in the second dataset from spherical (lon', lat') to (x',y',z') ...

12

I'd be curious how results from this formula compare with Esri's pe.dll. (citation). 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 ...

12

Just a quick addition: Also, planes from Asia to US would travel almost over North Pole. In that direction, they will often use the jet stream. In the other direction they will indeed fly over/close to the poles. http://en.wikipedia.org/wiki/Jet_stream

12

I've explored this question recently. I think people want to know what spherical radius should I use? what is the resulting error? A reasonable metric for the quality of the approximation is the maximum absolute relative error in the great-circle distance err = |s_sphere - s_ellipsoid| / s_ellipsoid with the maximum evaluated over all possible pairs ...

11

We usually have data concerning where the ground is, so we have to use that. The ground determines a solid figure in 3D. You project this figure radially onto the unit sphere centered at the viewer: this maps the ground onto a region in the sphere. Compute the area of the remaining region: that's the solid angle subtended by the sky (in steradians). ...

11

The best accuracy is obtained with ellipsoidal models. In the interests of simplicity you want to avoid those when you have to code distances yourself. We pay a price: given that the earth's flattening is about 1/300, using a purely spherical model can potentially introduce a relative distance error of up to 1/300 for very long routes: about 3000 parts per ...

10

Questions like this can often be answered by solving triangles using laws of spherical trigonometry. You can look these up: they are referenced below. Normally, when you know three of the six parts of a spherical triangle, the laws let you find the other three in terms of the sines and cosines of the parts you know. The trick is to draw a useful triangle. ...

10

This requires a kind of "field calculation" in which the value computed (based on a latitude, longitude, central azimuth, uncertainty, and distance) is the bowtie shape rather than a number. Because such field calculation capabilities were made much more difficult in the transition from ArcView 3.x to ArcGIS 8.x and have never been fully restored, nowadays ...

10

Although geodesics do look a little like sine waves in some projections, the formula is incorrect. Here is one geodesic in an Equirectangular projection. Clearly it is not a sine wave: (The background image is taken from http://upload.wikimedia.org/wikipedia/commons/thumb/e/ea/Equirectangular-projection.jpg/800px-Equirectangular-projection.jpg.) ...

9

Note that "Lat/Lon/Alt" is just another name for spherical coordinates, and phi/theta/rho are just another name for latitude, longitude, and altitude. :) (A minor difference: altitude is usually measured from the surface of the sphere; rho is measured from the center -- to convert, just add/subtract the radius of the sphere.) To convert phi/theta/rho to ...

9

9

The question asks for conversion between spherical and cartesian coordinates. This spreadsheet lays out the formulas: Blue lines are input, black are intermediate calculations, and red are output. Within the formulas, the values are referred to by the names in the [Parameter] column (assigned via the Insert|Name|Create operation). They differ from ...

9

WGS-84 is unprojected data. It uses a geodetic coordinate system, which means points are located on a spherical (ellipsoidal to be exact) modelisation of the earth. As a consequence, euclidian geometry is not valid for this kind of data. PostGIS «geometry» data type and associated functions work with planar coordinates and euclidian geometry computations. ...

9

An elegant principle provides a simple answer: All points on a smooth curved surface are flat at a sufficiently large scale. This means that after affine change of coordinates (usually involving just a rescaling of one of them), we can use formulas of Euclidean geometry, such as the Pythagorean Theorem for computing distances and the negative-...

9

It is a consequence of a theorem of Archimedes (c. 287-212 BCE) that for a spherical model of the earth, the area of a cell spanning longitudes l0 to l1 (l1 > l0) and latitudes f0 to f1 (f1 > f0) equals (sin(f1) - sin(f0)) * (l1 - l0) * R^2 where l0 and l1 are expressed in radians (not degrees or whatever). l1 - l0 is calculated modulo 2*pi (e.g., -179 -...

8

The Mercator projection distorts at the poles http://en.wikipedia.org/wiki/Mercator_projection more info Tissot's Indicatrix So the steepness is more acute in the latter poles http://en.wikipedia.org/wiki/Tissot%27s_Indicatrix

8

If you were in a plane, then the point that is r meters away at a bearing of a degrees east of north is displaced by r * cos(a) in the north direction and r * sin(a) in the east direction. (These statements more or less define the sine and cosine.) Although you are not in a plane--you're working on the surface of a curved ellipsoid that models the Earth'...

8

On a sphere you can use trigonometric identities. On an ellipsoid, to compute the angle B in triangle ABC, it is usually best to create points A' and C' at short distances from B along the edges BA and BC respectively, project A'BC' using a conformal projection (which by definition preserves angles), and compute the (Euclidean) angle at the projected point ...

Only top voted, non community-wiki answers of a minimum length are eligible