[PROJ] Calculating meridian convergence

[Martin Desruisseaux]

Hello Thomas

Thanks for your email (and no worry if my email was "dry" - I just tried 
to focus on some points without making the mail too long). Just a few 
notes about my understanding of ISO 19111 subtleties:

Le 02/06/2022 à 16:02, Thomas Knudsen a écrit :

> Regarding "internal state" and ISO19111, there is still a number of 
> places that the notion that a that a CRS should be "defined" pops up, 
> cf. e.g. ISO19111 clause C.5.1: "The associated map projection 
> effectively **defines** the projected CRS from the geodetic CRS.
>
ISO 19111 makes a distinction between "conversion" and "transformation". 
In ISO 19111 terminology, a conversion is always between two CRS using 
the same datum. So conversions are not impacted by changes in the figure 
of the Earth (plate motions, etc), is defined by pure mathematical 
formulas and has theoretically an infinite precision (ignoring floating 
point rounding errors and approximations by series expansions). By 
contrast, a transformation is between two CRS using different datum. 
Transformation are determined empirically, have unavoidable stochastic 
errors (not caused by software limitation), change with time and 
location, etc.

Map projections fall in the "conversion" category while datum shifts 
fall in the "transformation" category. In ISO 19111 model, a projected 
CRS is a special case of derived CRS, i.e. a CRS related to another CRS 
by a conversion. The model restricts this relationship to conversions; 
it is not possible in ISO 19111 model to define a derived CRS using a 
transformation. So the ISO model forces the use of a database such as 
EPSG for all empirically-defined relationship between CRS. Only the 
mathematically-defined relationship can be associated to the CRS. I 
presume this is because the latter are considered stable.


> But the real deluge of internal state first becomes clear when turning 
> to ISO19162/OGC18-010, "WKT representation of CRS", which, I believe, 
> you are one of the primary authors of.
>
The merit goes to Roger Lott; I only provided some comments. Even also 
contributed well.


> (…snip…) Which in my book could be reduced to (…) just
>
> PROJCRS["SWEREF99 TM"]
>
> i.e: "There exists a projected coordinate system called SWEREF99 TM". 
> We also know that it's known as EPSG:3006, since that is the key we 
> used to look it up. To have any use of it, we need it supplemented by 
> an entry in the transformation table telling the "CONVERSION" part of 
> the story.

Yes we agree :-) With a nuance: the labels are not applied on the CRS, 
but on the datum. And indeed any transformation between different datum 
requires the use of a database (ignoring "bound CRS"). So the model is 
already the way you describe, if we keep in mind that as soon as there 
is a change of datum, the relationship between two CRS is no longer a 
conversion (it become something with at least one transformation) and 
consequently can not be used anymore in the definition of a derived or 
projected CRS. The "CONVERSION" element in "PROJCRS" definition is 
restricted by the model to a narrower case bounded by mathematics. By 
contrast, the problem about the "TOWGS84" element was that is was 
associated to the datum, not the CRS. So it was defining a 
transformation (as opposed to conversion), which we agree should not 
appear in a WKT.

     Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220602/b3d87743/attachment.htm>