[PROJ] Calculating meridian convergence

[Thomas Knudsen]

Roger,

The blunt answer to your question is NO, but let me try to qualify that a
bit:

The conceptual problem here is the dubious historical ISO19100/OGC notion
that a CRS has some kind of internal state, which makes it possible to
derive its relation to other CRS.

In geodesy, on the other hand, what amounts to a CRS in ISO/OGC
terminology, really is just a label (i.e. a name for the system), and the
relation between the system with that name and another system with another
name is given by a transformation, which can be described in mathematical
terms.

The meridian convergence (and any other relevant characteristic) is a
property of the transformation (i.e. the mathematical prescription), not of
the CRS per se, because *there is no such thing as a CRS per se*: It is
just a label, and you cannot perform any kind of mathematical analysis on a
label.

So you can infer the meridian convergence by looking at the transformation
taking:

- geographical coordinates labelled EPSG:4619 (SWEREF99 geographic 2D, i.e.
the Swedish realization of EPSG:4258, ETRS89 geographic 2D),

to

- projected coordinates labelled EPSG:3006 (SWEREF99 TM)

i.e. you can infer the meridian convergence *from the transformation, not
from the system*: The meridian convergence is a quality in the space
between two systems, which tells a part of the story about how the first
system is being warped to arrive at the second.

The practically available implementations of the ISO/OGC standards for
"referencing by coordinates" has an unfortunate focus on systems, rather
than transformations.

This leads to needless complications, because the transformations must be
derived from an imaginary internal state of the CRS labels, rather than
just referred to by their own label.

*As an example: *

To go from the *system* labelled *EPSG:4619* to the *system* labelled
*EPSG:3006*, you need to apply the *transformation* (in this case formally
called a conversion) labelled *EPSG:17333*.

Geodetically speaking, the transformation is what matters - the systems are
just labels. And in the case at hand the transformation is purely
mathematical, so it will always go well, it can be derived flawlessly from
the (imaginary) internal state.

In cases including empirically derived parameters (i.e. datum shifts),
there may be a multitude of relevant transformations (e.g. the EPSG
registry has 19 different cases of transforming between the Australian
datums AGD66 and GDA94), and picking the right requires additional
contextual information.

If the user is OK with meter level accuracy, picking any of these is
probably OK, and we can get away with having the user specify just the two
system labels (as in EPSG:4619 and EPSG:3006).

If better accuracy is required, however, we should let the user ask
specifically for a given transformation implementation (as in EPSG:17333).
In that case, the two system labels are redundant information, and can be
used to check that the transformation asked for actually transforms between
the two systems specified.

I talk more about this in my comment in a related issue over at
https://github.com/OSGeo/PROJ/issues/2854#issuecomment-920993274

So in essence, the answer to your question is NO: You might be able to
infer the proper meridian convergence from the transformation EPSG:17333,
but not from the CRS EPSG:3006, and we should get out of the habit of
assigning CRS a more prominent role than they deserve. They are just
labels, after all: The geodetic realities are in the transformations, not
in the labels.

I'm building Rust Geodesy, a platform for experiments with geodetic
software and abstractions, that tries to focus more on transformations than
on CRS, over at https://github.com/busstoptaktik/geodesy - you're welcome
to have a look.

/Thomas

Den tor. 2. jun. 2022 kl. 09.52 skrev Roger Oberholtzer <
roger.oberholtzer at gmail.com>:

> If I use the proj definition instead of the EPSG code, the calculation
> works,. So I guess there is no bug to report for that.
>
> The question is, should I be able to use the EPSG code here? Is this
> an unintended thing that I cannot use it?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220602/3f911d2a/attachment.htm>