Programmers beware! You need to be especially careful with converting geodetic lat/lon/alt coordinates to and from other systems, particularly with the Earth-centered, Earth-fixed system (basically a Cartesian x,y,z coordinate grid). Do it incorrectly, and you might find yourself buried under several meters of dirt ;)
All too often I've come across code that started out by assuming a spherical Earth (wrong!) or trying to compensate by multiplying by a factor to adjust for the oblation (still wrong!). Doing this calculation accurately is very much non-trivial and still a topic of active research in geodesy.
Fortunately, there's libraries to do the hard work for you:
It gets better still! Did you know that GPS data and KML (Google Earth's format), despite both using the WGS84 spheroid, are not compatible? GPS computes altitude above the spheroid (shape of the earth), while KML requires altitude above the geoid (shape of the sea). These differ by several hundred feet in many areas. (The geoid is 30 m below the ellipsoid where I am.)
But wait there's more! Just using lat/long and ignoring elevation? Guess what, the verticals for GPS and KML differ too! GPS looks down a line normal to the spheroid; KML looks down a line normal to the geoid (in the direction of gravity). Those are almost always different. So unless your GPS readings were taken at sea level, your data's still wrong!
The picture here explains what's going on: http://en.wikipedia.org/wiki/Geoid#Description The "plumb lines" are what are used by KML; the other lines are what are used by GPS. Notice how they point to different locations...
(P.S. I'm not a GIS-icist, but this comes from experience of collecting and correcting GPS data and reading spec sheets. I'd love if an actual GIS or Google person told me I was wrong but I'm not holding my breath.)
Sure it doesn't but interestingly enough the article does not go into its roots. In France after the Revolution the Metrical or Decimal system of measures was introduced. The fundamental standard adopted was that of a quandrant meridian; This quandrant was divided into ten millions of equal parts, and one parts or divisions was called the Metre, which was adopted as the unit of length and painfully measured by triangulation by M.M. Delambre and Mechain by measuring an arc of the meridian between the parallels of Dunkirk and Barcelona!
They do but with the metric system it was the first time since the Greek stadia that an earth measure was used to define units of measurements as compared to the body (feet, inches etc). They are a bit of a recursive topic, each defining each other in a way (besides geometry calculations, which are totally theoretical).
That specific mile you are talking about is not one of the examples I am talking about. Have a look at nautical miles, sea miles, and geographic miles and you will find they were based on the Earth at times during that period. Apparently the Chaldeans used an Earth-based "mile" also.
If you're curious about the history of this topic, Dava Sobel's Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time is well worth reading.
basically don't do projection/unprojection/coordinate transformations on your own, if you really want to write the code use the specs directly (good luck!) or use a lib if you can.
Best thing: stick to WGS84+webmercator as much as you can (some people can't help it: continents drifts, legacy compatibility etc.)
Geography geekness is fun for geographs and pisses everybody else in the world (and I'm doing GIS stuff for a living).
Except we can't, because standards dictate stupid this. My example: GPS data gives altitude above the spheroid; KML requires altitude above the geoid. This means that even 2D GPS coordinates that were not taken at sea level cannot be used directly in KML and hence Google Maps.
Converting this requires projecting spheroid data into 3-space and reprojecting it onto the geoid (which is a complex geometrical shape). Neither of these steps is trivial. Of course it's easy if you've got proj4; but this kind of stuff just does not ship with Android.
The first part of this is key: geocentric vs geographic. There are actually several corrections needed if you try to combine the two in celestial navigation.
This somewhat counter-intuitive definition is a result of the need for backward compatibility with existing latitude data, taken long before people had any idea of the Earth's oblation.
Originally, sextants were used to measure latitude based on solar elevation. This definition of latitude is easily measured by sextant: 90 degrees minus the maximum (i.e. noon) solar altitude on the equinox.
No - one degree of latitude still varies. One minute of latitude is a "sea mile", which varies. A nautical mile is 1852 meters which is the closest round number to the mean sea mile.
No. It has to do with how coordinates were calculated before we had good data on the Earth's oblation. Latitude was calculated based on the solar elevation (measured by sextant) at noon. For example, at 40 degrees north (by definition) the sun will be at 50 degrees at noon on an equinox.
Longitude is a different story; it's relatively recent that we've been able to calculate that. Sailors in the 17th century had sextants and solar tables and could figure out their latitude easily, but had no idea where they were in terms of longitude.
Replying off the top of my head, but IIRC once astronomical phenomena became known and observable, these could provide constant "clocks" which could be verified at different points on the Earth's surface. In particular, transits/occlusions of planets, moons, or stars could be viewed from different points. While observations regarding the Earth's moon are subject to some parallax, by the time you're looking at other planets (or their lunar systems), the error is minimal.
We're talking Keplerian / Gallilean times onward (telescopic observation and orbital mechanics) for the most part, though some observations may have been possible / performed in earlier times. Turns out that Gallileo and Halley proposed such methods in 1612 and ~1683.
Accurate navigational chronometers came along in the late 18th century.
All too often I've come across code that started out by assuming a spherical Earth (wrong!) or trying to compensate by multiplying by a factor to adjust for the oblation (still wrong!). Doing this calculation accurately is very much non-trivial and still a topic of active research in geodesy.
Fortunately, there's libraries to do the hard work for you:
http://earth-info.nga.mil/GandG/geotrans/
http://geographiclib.sourceforge.net/