What is wrong with 19111

[busstoptaktik]

The most recent edition of ISO-19111 "Referencing by coordinates" was published in 2019. Hence, according to ISO's 5 year life cycle of standards, 19111 is up for consideration-of-revision in 2024.

This PR is my input to DS/S-276 (the Danish national committee of ISO Technical Committee 211 "Geographic information/Geomatics"), for discussion of that subject.

A more readably rendered version is available here

Still draft, and the most rough parts still partially in Danish, but discussion encouraged.

[desruisseaux]

The discussion about the use of WGS84 as a pivot should said that this practice was in standards that predate ISO 19111, namely OGC 01-009 and WKT 1 in their TOWGS84 element. To my knowledge, all ISO 19111 versions have the same centimetric precision capability for operations between static reference frames (latest revision adds dynamic reference frames).

The discussion should also said that conformance to ISO 19111 model by the industry was unequal. EPSG follows that model (actually ISO 19111 was designed a lot by geodesists from EPSG). GeoTools adopted the ISO 19111:2003 model quickly, while PROJ adopted it around 2018 (we need to check the exact PROJ 6 release year). The fact that PROJ is widely perceived as a reference in map projections may explain the impression that Proj.4 limitations reflected limitations from OGC/ISO standards, while actually PROJ became compliant with ISO model only since PROJ 6.

Given the above, if the document intention is to describe the situation since the 1990 years, then I think that the document title "What is wrong with ISO 19111" should be renamed in something that reflects the longer journey.

ISO 19111:2007 did not have the "Reference Frame" term anywhere in its UML. It used "Geodetic/Vertical datum" terms instead. The only place where the "Reference" word appeared was in "Coordinate Reference System" (CRS), so maybe it was not obvious that "Reference Frame" corresponded to "Geodetic Datum" instead of "CRS". It may explain why the slides that I saw about one year ago were making remarks that would be true if CRSs were Reference Frames (for example, saying that CRSs should be merely identifiers and that all operations between CRSs should be defined in a database — this is true for Reference Frames, while some operations such as unit conversions are possible between CRSs without database). I see that as an example of the importance of naming and a justification for the renaming of GeodeticDatum to GeodeticReferenceFrame in ISO 19111:2019. However, I have hear that there is still discussion about naming in ISO 19111 revision committee. I have also hear that the "Coordinate Reference System" name has been debated a lot in the beginning of ISO 19111 history. The paper in this Pull Request makes another renaming proposals. I have no competence for commenting on that, but it may be worth to add some context like this paragraph.

I agree with the proposal to define the difference between Transformation and Conversion more in terms of whether the operation uses stochastic parameter values, or values adopted by definition. The OGC CRS SWG group already had this debate in an OGC meeting when preparing ISO 19111:2019. The group has choose to not do that, but I do not remember the reason. I would support raising this question again.

In "Item 4: CRS concept", the sentence "the typical CRS today, consists of a reference frame plus some kind of coordinate operation" gives the impression that it is talking about operations embedded in the CRS. If the sentence is referring to CoordinateOperation, which are stored as separated objects (except for DerivedCRS), maybe that sentence should be reformulated.

In "Item 6: pipelines of operations", the sentence "while ISO-19111 allows concatenation, it does so only in cases where intermediate CRS exist for every step" should explain why it is a problem. Is there anything that prevent the definition of those intermediate CRSs as EngineeringCRS, DerivedCRS or something else?

[busstoptaktik]

Hello Martin @desruisseaux!

Thanks for your extensive and thoughtful comments! I will try to incorporate the essentials into the text, although there are also elements where I cannot. Partially because this is an opinion piece, and reflects my opinion (hence open for discussion, and thank you for participating in that!), and partially because I believe you perhaps misinterpret my intentions here and there, and hence argue against opinions I have not intended to express.

In these cases, I will obviously try to clarify the text in the parts I believe may have led to the false impressions. Identifying these will, however, necessarily be based on a hearty dose of personal judgement, so please consider commenting again, if I do not manage to elevate the clarity sufficiently!

But also have in mind that, as this is an opinion piece, we may simply disagree, and in such cases I will not necessarily change the aim of the text - but I will definitely thank you for helping me clarify the argumentation, although it may very well not convince you :-)

I will continue working on the text over the next few weeks, and even after that time nothing is cast in concrete.

There is, however, a few parts of your comments that I will up front not consider incorporating (although I understand your intention, and value your comments). This relates mostly your comments about my NKG presentation, and to those about PROJ.

In the former case because the slides are only part of the story of a presentation: The spoken word elaborates on the material from the slides - which may even, for didactical effect, state a calculated ambiguity, clarified by the spoken word, so nitpicking on what was on the slides, and what the speaker intended is not really relevant here. I may, however, find occasion to elaborate on the subject at a later date - and will remember to invite you to comment on that.

In the latter case because this has nothing at all to do with implementations. And even to the degree it may have, it is based on experience with implementing (parts of) 19111 in Rust Geodesy. PROJ has nothing to do with this.

Rust Geodesy is, however, a consequence of PROJ being too large a beast to do architectural experiments on. The Rust Geodesy code base only amounts to around 2-3 percent of PROJ's, and it does not suffer from 40 years of reality hardening. So it is much easier to experiment with, but it is also much less of a practical work horse. Although in the Rust ecosystem, it is in somewhat higher (although not necessarily wider) use than PROJ.

That was, however, never the intention: Rust Geodesy originated as a platform for experimenting with better data flow models for PROJ, but drifted into being a platform for exploring some of the less trodden corners of 19111.

But back to the subject: ISO 19111/OGC Topic 2 is an enormously important beast, since it is (or at least ought to be) the glue that ties coordinates (as abstract numbers), to concrete locations in the physical world. To do that, it also needs to bridge the canyon between geodesy and geomatics.

And geodesists tend to get away with being linguistically sloppy, because physical reality and human conception are magnificent disambiguators. Geomaticians on the other hand, must be conceptually more strict, since they concern themselves with feeding the bit-crunching monsters, which have neither imagination, nor reason.

So bridging that canyon between contextual sloppiness, and context free rigor is no simple feat. Reaching a common understanding may very well take yet another few decades. But while that understanding materializes, at least we can try to trim, and focus, 19111 in a way such that it doesn't buckle under its own load.

In other words: To fulfill its mission, 19111 must speak geodesy. But since geodesy comes in many dialects, each of which is only spoken reluctantly by geodesists, this is non-trivial. The glossary in 19111 may perhaps serve as a least common denominator, but even that subset may cause both discussion and confusion. And it is definitely neither clear enough or comprehensive enough to serve as basis for communication across the canyon, with non-practitioners (including geomaticians). We may very well agree without realizing. Or the opposite!

[desruisseaux]

Thanks for you reply, all look fine to me. I agree that doing a clean room implementation is one of the best ways to test a standard.

One side-note question: does the Rust language has a mechanism for separating the API from the implementation? In the Java language, it would be interfaces. I'm curious if an OGC GeoAPI in Rust is technically possible or practical.

[busstoptaktik]

One side-note question: does the Rust language has a mechanism for separating the API from the implementation? In the Java language, it would be interfaces. I'm curious if an OGC GeoAPI in Rust is technically possible or practical.

@desruisseaux I wrote my last line of Java code in 1997, so finding equivalences beween Java and Rust is perhaps not my strongest side :-) but for separating API from implementation, I would use traits in Rust. Perhaps this thread and references therein will have some relevance?

As an example, cf the CoordinateTuple trait in https://github.com/busstoptaktik/geodesy/blob/main/src/coordinate/tuple.rs (ignore the macro definitions at the top - the trait starts at line 110)