<div dir="ltr"><div>Martin,<br></div><div><br>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 :-)<br><br>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.<br><br>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".<br><br>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:<br><br>PROJCRS["SWEREF99 TM",<br> BASEGEOGCRS["SWEREF99",<br> DATUM["SWEREF99",<br> ELLIPSOID["GRS 1980",6378137,298.257222101,<br> LENGTHUNIT["metre",1]]],<br> PRIMEM["Greenwich",0,<br> ANGLEUNIT["degree",0.0174532925199433]],<br> ID["EPSG",4619]],<br> CONVERSION["SWEREF99 TM",<br> METHOD["Transverse Mercator",<br> ID["EPSG",9807]],<br> PARAMETER["Latitude of natural origin",0,<br> ANGLEUNIT["degree",0.0174532925199433],<br> ID["EPSG",8801]],<br> PARAMETER["Longitude of natural origin",15,<br> ANGLEUNIT["degree",0.0174532925199433],<br> ID["EPSG",8802]],<br> PARAMETER["Scale factor at natural origin",0.9996,<br> SCALEUNIT["unity",1],<br> ID["EPSG",8805]],<br> PARAMETER["False easting",500000,<br> LENGTHUNIT["metre",1],<br> ID["EPSG",8806]],<br> PARAMETER["False northing",0,<br> LENGTHUNIT["metre",1],<br> ID["EPSG",8807]]],<br> CS[Cartesian,2],<br> AXIS["northing (N)",north,<br> ORDER[1],<br> LENGTHUNIT["metre",1]],<br> AXIS["easting (E)",east,<br> ORDER[2],<br> LENGTHUNIT["metre",1]],<br> USAGE[<br> SCOPE["Topographic mapping (medium and small scale)."],<br> AREA["Sweden - onshore and offshore."],<br> BBOX[54.96,10.03,69.07,24.17]],<br> ID["EPSG",3006]]<br><br><br>Which in my book could be reduced to:<br><br>PROJCRS["SWEREF99 TM",<br> USAGE[<br> SCOPE["Topographic mapping (medium and small scale)."],<br> AREA["Sweden - onshore and offshore."],<br> BBOX[54.96,10.03,69.07,24.17]]<br><br>or even just<br><br>PROJCRS["SWEREF99 TM"]<br><br>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.<br><br>To have any use of it, we need it supplemented by an entry in the transformation table telling the "CONVERSION" part of the story.<br><br>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".<br><br>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.<br><br>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.<br><br>/Thomas<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tor. 2. jun. 2022 kl. 13.22 skrev Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<p>Hello all</p>
<p>Below is just adding a little bit more historical context to
what Thomas said.</p>
<p><br>
</p>
<p>Le 02/06/2022 à 12:39, Thomas Knudsen a écrit :</p>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<p>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.</p>
</div>
</div>
</blockquote>
<p align="justify">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 "<font face="monospace">TOWGS84</font>"
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).<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<p>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.</p>
</div>
</div>
</blockquote>
<p align="justify">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.<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<p>The practically available implementations of the ISO/OGC
standards for "referencing by coordinates" has an
unfortunate focus on systems, rather than transformations.</p>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p> Martin</p>
<p><br>
</p>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>