Inconsistency / doc issue in conventions Coordinate Frame vs Position Vector for +towgs84 vs +proj=helmert #1091
Comments
|
@kbevers @busstoptaktik Opinions ? This is something we must resolve before 5.2.0 IHMO |
I vote for this unless it breaks a long-standing convention. Otherwise we'll be doomed to answer this as a FAQ forever, no? |
|
What an unholy mess - I have a suggestion for a potentially safe way of solving this (basically @rouault s "bonus point" slightly extended), but will have to go offline for a few hours now. Will be back with a suggestion/description in the afternoon (UTC) |
|
@rouault: It was definitely not the intention to make proj=helmert incompatible with +towgs84. Your discovery of the incompatibility, and the fact that no one else have noticed for more than a year stresses that this problem is hard - not because it is complex, but because it is intractable. It is akin to the linguistic problem of repeated negations (“I ain’t gonna give nobody none of ...”). Unwrapping the layers to get to the true meaning is intractable because we can do full or partial sign switching of the transformation through a number of concepts, each with their related conventional, but potentially ambiguous interpretation:
While the latter is probably not a problem in general, the convention of giving rotations in arcsec (hinting at navigational convention), rather than e.g. microradians, makes it a source of potential confusion anyway. But let’s ignore the sign convention problem - and the even worse discussion of the order of the rotations. That still leaves us with at least three ways of stating parts of the same numerical thing. When doing a test computation, using a known data point, it is much too easy to convince oneself that “I have probably forgotten a transposition”, or “I probably confused forward and inverse”, and make things work correctly numerically by adding the appropriate, rather than correcting the root cause. So far I have just been stating the obvious, but since the suggested solution is painfully verbose, I want to make it perfectly clear that that level of verbosity really is the lesser evil. With that said, I suggest introducing 2 changes:
i.e. restore compatibility between +towgs84 and +proj=helmert, by not providing a default +proj=helmert convention. Neither PV nor CF. This allows us to fail noisily and early on use of the old syntax, either by choking on +transpose or by detecting the lack of +convention=... It is also easy to communicate to users: Everywhere you use +transpose, replace by +convention=position_vector, everywhere else, insert +convention=coordinate_frame. All in all it is a simple change (+convention=position_vector replaces +transpose, while +convention=coordinate_frame becomes a required no-op), and, if I understand correctly, covering the opinions of both @rouault and @hobu. My schedule is, however, overbooked for the rest of this week, so while I agree it should be done before 5.2.0, I am not volunteering to implement it immediately. |
|
@busstoptaktik Your plan sounds good to me. I can take care of implementing it if other stakeholders are happy with it too. |
|
I too am okay with Thomas' solution. One question though: When using the This is mostly a reminder for myself: Once this is implemented I need to update the init files at https://github.com/NordicGeodesy/NordicTransformations and sync with proj-datumgrids. The ITRF init-files distributed with PROJ will also need to be updated (can't remember if those are covered by the test suite). |
Do you mean like in "+proj=helmert +x= +y= ... +towgs84=...." ? Huh, is it possible ? I'd say this is undefined behaviour. I hope nobody will have the crazy idea of using both |
Sure is: I believe it is used in |
Indeed. This is not documented in helmert.rst and is probably a good thing to avoid any confusion, so we can deal with that as an internal detail. I'd say that if +towgs84 is defined we should check that +convention=position_vector and error out otherwise (such error shouldn't happen if cs2cs_emulation_setup() is the only user of it, once it is updated) |
… forbids +transpose (fixes OSGeo#1091) As identified in OSGeo#1091, Helmert implementation in PROJ 5.0 and 5.1 is confusing. It happens that by default it used the coordinate_frame convention, contrary to the position_vector convention used traditionaly for +towgs84. The documentation of Helmert was also wrongly specifying that the default convention was position_vector. This commit: - bans the confusing +transpose parameter - removes the concept of a default convention, since in practice both are equally found, and requires +convention as soon as a rotational term parameter is present. For translation only, convention is ignored and optional, as having no effect. - fixes all the identified uses of proj=helmert in code, doc and tests This is obviously a breaking change: - users will have to adapt their pipeline expressions - in particular, init files that would use helmert must be adapted However, as designed, the break will be explicit, and not silent.
|
Hi, I still have my notes about errors (bugs) that I found, some of which are maybe fixed in the meanwhile, these are the ones that are Helmert transformation related, I'll report other ones in new issue:
I also found a missing option (feature) for Helmert transformation if we want it to be truly flexible to be used in any country. I wrote about this problem in second email to Thomas, but then I didn't understand the problem completely. For Croatia, we use different rotation matrix, at first I thought it was bug in PROJ, but later I found out that it is programmed for most common rotation matrix, which is obviously calculated as R = Rx * Ry * Rz. In Croatian literature: Issues related to Helmert seven-parameter transformation, there is a formula which is calculated as R = Rz * Ry * Rx, and it is noted in paper that multiplication must not be reversed for our case. I thought that only difference was because of different rotation convention, but if you multiply it different you don't only get reversed signs, but different matrix. As I researched it further I found this Swedish paper On geodetic transformations, there is explanation in the chapter 6.3 - Computational consistency for 3D Helmert, on page 16 just below middle of the page:
So the proper way to implement Helmert transformation should be to implement option for different rotation matrices (6 versions, as stated in Swedish paper), and the already implemented - two rotation conventions. |
|
@phidrho Your point about the order of multiplication of rotation matrices is an interesting one (and quite scary !), and I believe deserve another dedicated ticket so that one remains actionable. I guess this only matters for the case where the +exact flag is used, since with the default small angle approximation (sin(x)=x, cos(x)=1), the order of matrices doesn't matter. |
[BREAKING] Helmert: add +convention=position_vector/coordinate_frame, forbids +transpose (fixes #1091)
The +towgs84 convention used by Proj is to have coefficients in the Position Vector / EPSG:9606 convention: cf https://github.com/OSGeo/proj.4/wiki/GenParms and pj_geocentric_to_wgs84() using the RPV matrix of the EPSG Guidance 7.2 page 136.
https://proj4.org/operations/transformations/helmert.html mentions "Two conventions exists and they seem to be equally popular. PROJ uses the Position Vector rotation convention. The rotation matrix can be transposed by adding the +transpose flag in the transformation setup which makes PROJ follow the Coordinate Frame rotation convention.", so this means that Helmert is supposed to use Position Vector convention too. However the formulas of build_rot_matrix() follow the R matrix (for the exact case) and RCF (for the approximate one) of the EPSG Guidance, that is to see Coordinate Frame.
Relevant extract from EPSG 7.2 guidance:
Extract from build_rot_matrix()
Extract from pj_geocentric_to_wgs84()
And https://proj4.org/usage/transformation.html mentions rightly "the default setting is to use “coordinate frame” convention of the Helmert transform"
Another practical proof that there is a difference of conventions between +towgs84 and +helmert
To get the same result with the new API, you need to use the +transpose flag of helmert
And the cs2cs_emulation_setup() of proj_4D_api.c does add the 'transpose' term when it expands +towgs84 into a helmert transform
So I'm pretty confident that there is indeed a difference of conventions + documentation error in the Helmert page
I can see 2 possibilities:
Bonus point, that can apply to any of those 2 choices, add a new flag to helmert: +convention=position_vector/coordinate_frame flag so that it is immediately obvious which convention is used (+transpose is really technical and assumes you know the default convention)
The text was updated successfully, but these errors were encountered: