Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
In issue #575, I mention the dangers of using the term geocentric coordinates for what is essentially Earth centered, Earth fixed, 3D cartesian coordinates (colloquially often called ECEF cartesian or just cartesian).
The problem discussed in #575 is that, since geographical coordinates are also Earth centered, Earth fixed (ECEF), and since we support not only geographical latitude coordinates, but also geocentric latitude coordinates, the risk of mental mixup between the two kinds of geocentricity is huge.
Apparently this kind of mixup is exactly what has happened in the scaling logic of the
On input, first thing done in the scaling logic, is to convert the coordinates given in the
Next, if the
To do so, the x, y and z coordinates must first be converted to meters. But since the
This is, however, wrong: When input is ECEF cartesian, the z coordinate has nothing to do with heights, and should never be scaled using a scaling factor for vertical coordinates.
In fact, for a point on the ellipsoid, z increases monotonically as the point moves from the South Pole, where z=-b, to the Equator, where z=0, to the North Pole, where z=b (b is the semimajor axis of the ellipsoid). So in the ECEF cartesian case, if anything z should be considered a “kind of northing”, rather than a “kind of height”.
There is no chance that anyone trying to transform cartesian input coordinates would ever expect these coordinates to be scaled using two different scaling factors. So my guess is that either this functionality has never been in actual use (i.e. all input has been in meter), or the user has discovered the workaround of setting
While this is fine, it is just a workaround: The bug is still a bug, and should be fixed. In fact it has been fixed as part of the preparation/finalization functionality introduced in PR #725, and this bug report is provided mostly for discussion and clarification purposes.