[PROJ] Calculating meridian convergence

[Thomas Knudsen]

Martin,

Thanks - it is hard to keep both the narrative on the track, and all
details accounted for at once, so your clarifications are much appreciated
:-)

Also, I am obviously aware of your Java based work, and have even enjoyed
reading some of the code. I have, however, never had any opportunity to
actually use it.

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. The claim is probably
related to the notion that (clause C.5.7): "Coordinate transformation
services should be able to automatically derive coordinate operations that
are not stored explicitly in any permanent data store", and the precaution
(C.5.2) that: "To facilitate recognition and validation it is recommended
that the coordinate operation method formulae be included or referenced in
the relevant object, if possible wih a worked example".

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. While the standard itself is not necessarily
the cause of the deluge, its practical use certainly is. Take for example
the representation of Roger's case of EPSG:3006. If we look that up in the
EPSG registry, or using projinfo EPSG:3006, we get this load of internal
state:

PROJCRS["SWEREF99 TM",
    BASEGEOGCRS["SWEREF99",
        DATUM["SWEREF99",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4619]],
    CONVERSION["SWEREF99 TM",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",15,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["northing (N)",north,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["easting (E)",east,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Topographic mapping (medium and small scale)."],
        AREA["Sweden - onshore and offshore."],
        BBOX[54.96,10.03,69.07,24.17]],
    ID["EPSG",3006]]


Which in my book could be reduced to:

PROJCRS["SWEREF99 TM",
    USAGE[
        SCOPE["Topographic mapping (medium and small scale)."],
        AREA["Sweden - onshore and offshore."],
        BBOX[54.96,10.03,69.07,24.17]]

or even 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.

And everything is not done with that: We would also need a transformation
entry taking EPSG:3006 to screen coordinates. So there will still be a need
for the transformation system to identify and string together partial
transformations as needed, but we are more honest about the CRS being a
stateless label, and the transformations associated with that label are the
"real stuff".

In its role as an abstract model, ISO19111 is in a sense an empty shell,
and I cannot relieve myself of the feeling that by focusing so deeply on
the CRS, rather than the transformations, we have lost an opportunity to
standardize and codify the stuff that actually matters: We have spent an
inordinate amount of effort specifying stateless labels, while we could
have been spending our focus on specifying the behavior of the partial
operations that can be used for building the transformations between CRS.

Today these are codified excellently in e.g. the IOGP Geomatics Guidance
Note number 7, part 2, which is a wonderfully clear and useful resource -
but it is not a standard, and I do not necessarily see any obvious opening
for that to happen.

/Thomas

Den tor. 2. jun. 2022 kl. 13.22 skrev Martin Desruisseaux <
martin.desruisseaux at geomatys.com>:

> Hello all
>
> Below is just adding a little bit more historical context to what Thomas
> said.
>
>
> Le 02/06/2022 à 12:39, Thomas Knudsen a écrit :
>
> 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.
>
> This notion came from OGC 01-009, which was prior to ISO 19111. The (now
> superseded) OGC 01-009 standard had a notion of CRS state in the form of "
> TOWGS84" information, and this design has been used by PROJ4 as well. But
> ISO 19111 never had this notion as far as I know. The "bound CRS" notion
> introduced in WKT 2 is somewhat similar, but the specification said that
> this is a compromise for existing practices, not something that they
> recommend. The EPSG documentation discusses the problem of "statefull CRS"
> in their discussion about "early binding" (stateful CRS) versus "late
> binding" (stateless CRS) implementations of map projection libraries. PROJ
> 4 was an "early binding" implementation, PROJ 6 and later are now "late
> binding" implementations (but it seems to me that habits inherited from
> PROJ 4 are still well entrenched).
>
>
> 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.
>
> OGC 01-009 specified a way to not only transform coordinates, but also to
> obtain the Jacobian matrix at a given point for a given transformation.
> That was (I think) a very good feature from OGC 01-009 which has not been
> kept by ISO 19111. Maybe because considered too complex, I do not know.
>
>
> The practically available implementations of the ISO/OGC standards for
> "referencing by coordinates" has an unfortunate focus on systems, rather
> than transformations.
>
> It may be a matter of popularity. The Java world has some implementations
> of ISO/OGC standards done in the "right" way (late-binding implementation +
> support of Jacobian matrices) for 10~20 years. But they are not well-known
> like PROJ, which may give the impression that they do not exist.
>
>     Martin
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220602/870caa7c/attachment-0001.htm>