Google Maps: Is the Earth a Sphere or Ellipsoid?

Google Maps sees the Earth as a Spheroid, not an Ellipsoid. This came up through a discussion on the PROJ mailing list and I thought it was interesting to point out how Open Source can even handle projected lat/long systems (such as Google Maps) using a very familiar tool called cs2cs.

Christoper Schmidt wrote about it on his blog and also on his blog he points out the EPSG code to use. The magical number for the Google Mercator Projection (of a lat/long grid based on a sphere) is: 900913

Now onto the fun, showing how we can use Open Source to have our data show within a KML project and Google Maps. Quoting from Frank's FAQ, he provides an excellent example, we see the following the use of cs2cs:

"cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs"

Notice the sphere is being used? a=b

Because we are dealing with a sphere, the Y values will be greatly different from those on an ellipsoid (30 to 100 metres or more).

Quoting Frank again:

"In this case, and many other cases using spherical projections, the desired approach is to actually treat the lat/long locations on the sphere as if they were on WGS84 without any adjustments when using them for converting to other coordinate systems. The solution is to "trick" PROJ.4 into applying no change to the lat/long values when going to (and through) WGS84. This can be accomplished by asking PROJ to use a null grid shift file for switching from your spherical lat/long coordinates to WGS84.

cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs

Note the strategic addition of +nadgrids=@null to the spherical projection definition"

As you can see the value of Open Source and the mailing list and Open Source software is that people are sharing knowledge - whether it be via blogs, lists, or some other means of communication. There is a community out there that supports each other. These are actual users facing everyday problems and looking for solutions. The answers do exist, just the question has to be asked, and the community comes together to help.

cs2cs & BeTA2007 - Open Source, Germany & NTv2

Recently in the PROJ.4 Mailing List there was a discussion about working with the DHDN / Gauss Krueger to WGS84 conversion.

One of the posters listed a site and document that covered BeTA2007 (which means Bundeseinheitliche Transformation fur ATKIS) and allowed me to brush up on my German.

In reviewing the document, we find out that the method of Operation for the datum conversion is based on NTv2 and the coordinate reference system is ETRS89/UTM.

Within the document listed above, they even demonstrate how to do a coordinate coversion using cs2cs and how to use the +nadgrids parameter.

An example from the document shows that the +nadgrids does not have to be specific to North America, only that the data file containing the grid has the same format. This format has been specified by the Canadian Government and has been adopted by many countries (such as South Africa and Australia, to name a few).

This is the published example, using the BETA2007.gsb file and a data file containing these two points:

(1) 2490000.00 5652000.00
(2) 2504000.00 5628000.00


>> cs2cs \
+proj=tmerc +lat_0=0 +lon_0=6 +k=1.0000000 \
+x_0=2500000 +y_0=0 +ellps=bessel +units=m \
+nadgrids=./BETA2007.gsb
+to \
+proj=utm +ellps=GRS80 +zone=32

Resulting in:

2490000.00 5652000.00 <-- Input (1)
279488.01 5654871.71 0.00 <-- UTM 32/GRS80 Answer for (1)

2504000.00 5628000.00 <-- Input (2)
292503.36 5630318.18 0.00 <-- UTM 32/GRS80 Answer for (1)

So cs2cs works with other grid systems as long as they are defined the same as the NTv2 standard.

So all the above makes more sense, let me define, from Wikipedia, what ETRF is: "The European Terrestrial Reference System 1989, usually referred to as ETRS89, is a three-dimensional geodetic frame of reference - a mapping coordinate system used as the standard high accuracy system for GPS in Europe. It coincided with the World Geodetic System 1984 in 1989, hence the name, and is based on the same GRS80 ellipsoid. Unlike WGS84 or ITRS it is centred on Europe and diverges from them with the movements of the tectonic plates associated with this landmass."

Please see: http://en.wikipedia.org/wiki/ETRS89 for ETRS89 and http://en.wikipedia.org/wiki/World_Geodetic_System_1984 for WGS84

The parameters for a datum shift (dx, dy, dz, rx, ry, rz, etc.) between ETRS89 and WGS84 are not constant, due to the movement of the Eurasian geophysical plate with respect to WGS84. The differences between both datums can grow by several centimetres a year. Currently they are a couple of decimetres in difference. For many applications, these differences are not relevant. Coordinates or positions in WGS84 have usually been obtained by GPS and this results in an accuracy at the level of several metres. However, satellite positioning techniques continuously improve in accuracy, also without using differential stations. So the differences between the datum's will grow. Note that many nations are using WGS84 to define boundaries nowadays - so WGS84 is relevant.

One poster from France, to the mailing list, replied that they solved the problem of moving plates by adding a date to the location, and they stated their method as follows:

"We have solved this problem with moving plates by adding a simple date with the coordinates of WGS84. That way you can always go back to the original position of that particular date in WGS84 (or any). The WGS84 datum (with date) will stay accurate for ever, since it is always possible to trace back where the plates were at that specific date.

latitude,
longitude,
(WGS84),
date"

There are always solutions and answers to questions out there. Just feel free to ask, whether it be to a mailing list or your local expert, people are always willing to help and pass on knowledge.