Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong scaling in pj_transform #726

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

Wrong scaling in pj_transform #726

busstoptaktik opened this issue Jan 3, 2018 · 1 comment

Comments

@busstoptaktik
Copy link
Member

@busstoptaktik busstoptaktik commented Jan 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.