Map out translation process

[judgej]

The attached sketch shows the process from top left, going clockwise. I started off defining the process for a datum shift alone, then realised much of what happens in the datum shift is dictated by the parameters of the source and destination projections.

Things to note are:

• The projections will convert to and from a geodetic (lat/lon) point using their forward()/inverse() methods.
• Datum shifts can only operate on geocentric points, so that conversion needs to be done.
• If a datum shift is not needed, then converting to geocentric and back again is a wasted operation - just skip that bit.
• Converting from a projection point to a geodetic point will carry forward the datum with it.
• Converting from a geodetic point to a projection is a little more ambiguous, as the point will have a datum of its own, and that may not match the datum that the projection uses (i.e. that, in part, defines the projection). What do we do here? Force a datum shift? Or raise an exception?

Another thing that has confused me, that I would like clarified, is where ellipsoids are defined. A projection has a datum and usually an ellipsoid defined in its "def". A datum also has an ellipsoid defined in its parameters. So do the two always agree? Should a projection ellipsoid override a datum's ellipsoid? Or is it listed in the "def" details just as a bit of human-readable information?

[judgej]

Hmm, a datum consists of an ellipsoid and a set of location and optional rotational mappings.

For geocentric (x, y, z) points the ellipsoid of the datum is not important; a Cartesian set of coordinates does not reference any ellipsoid or shape of any form - it is just a point in space from a "centre". It is only when converting to a geodetic (lat/log/height) point that we care about the ellipsoid details.

So maybe a geocentric point does not have a datum - it just has translation (x, y, z, rotation and scale) parameters. This collection of mappings does not have a collective name, and that is why "datum" is used, and also why an ellipsoid is defined outside of the datum in the proj4 def strings.

So I think we have a geodetic datum, with translation parameters and an ellipsoid. We also have a geocentric datum with just translations parameters, since the ellipsoid is meaningless to a Cartesian coordinate. This has been confusing me for ages, and this dhoh! moment kind of clarifies things a little. Unfortunately, while I think there are two different types of datum (with the same name in Proj.4), the Proj.4 systems in operation don't see it that way. Or I'm just totally wrong! Who knows...