Wrong scaling in pj_transform

[busstoptaktik]

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 pj_transform function.

pj_transform supports two different linear scaling parameters: to_meter and vto_meter, the latter intended for conversion of vertical coordinates.

On input, first thing done in the scaling logic, is to convert the coordinates given in the z input array, using the vto_meter factor, assuming they represent some kind of height.

Next, if the is_geocent flag is set on the source system definition, the “geocentric” (i.e. ECEF cartesian) coordinates are converted to geographical (i.e. ECEF angular).

To do so, the x, y and z coordinates must first be converted to meters. But since the z coordinate array was already converted, using the vto_meter factor, only the x and y coordinate arrays are handled now.

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 vto_meter = to_meter.

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.

[busstoptaktik]

Resolved in #725