/ PROJ Public

# Wrong scaling in pj_transform#726

Closed
opened this issue Jan 3, 2018 · 1 comment
Closed

# Wrong scaling in pj_transform #726

opened this issue Jan 3, 2018 · 1 comment

### busstoptaktik commented Jan 3, 2018 • edited

 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. The text was updated successfully, but these errors were encountered:
mentioned this issue Jan 3, 2018

### busstoptaktik commented Jan 3, 2018

 Resolved in #725

mentioned this issue Mar 5, 2018