You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: ruminations/010-rumination.md
+34-23
Original file line number
Diff line number
Diff line change
@@ -6,14 +6,16 @@
6
6
7
7
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. The following is my input for these considerations to DS/S-276, the Danish national committee of [ISO Technical Committee 211](https://www.isotc211.org/).
8
8
9
-
The material is initially published here, as a part of the Rust Geodesy [Ruminations](https://github.com/busstoptaktik/geodesy/blob/main/ruminations/README.md), as it is by and large a result of my work with [Rust Geodesy](https://github.com/busstoptaktik/geodesy) as a demonstration platform, outlining a road towards a simpler, leaner ISO-19111.
9
+
The material is initially published here, as a part of the Rust Geodesy [Ruminations](https://github.com/busstoptaktik/geodesy/blob/main/ruminations/README.md), since it is by and large a result of my work with [Rust Geodesy](https://github.com/busstoptaktik/geodesy) as a demonstration platform, outlining a road towards a simpler, leaner ISO-19111.
10
10
11
11
The text is long, and the subject both sprawling and convoluted. But the gist of it is, that:
12
12
13
-
- The original conceptual model behind 19111 was mostly in disagreement with the common geodetic world view. But it was simple and sufficient as long as nothing but metre-level absolute accuracy was required
13
+
- The original conceptual model behind 19111 was mostly in disagreement with the common geodetic world view. But it was simple and sufficient as long as metre-level absolute accuracy was acceptable
14
14
- As accuracy requirements grew, this non-geodetic conceptual model was not feasible anymore, and the 19111 model had to get into closer agreement with modern geodesy
15
15
- The 2019 edition comprises an enormous leap in this direction, but there is still more work worth doing
16
-
- Also, a number of concepts are either too vaguely or too restrictively defined in 19111(2019), and hence should be reconsidered
16
+
- Also, a number of concepts are either too vaguely or too restrictively defined in 19111(2019), and hence should be revised
17
+
18
+
**Also note that** while some of the changes proposed may seem extensive at first glance, they are actually rather clarifications than substantial changes. The aim is to support communication with end users and developers, through better alignment between geomatics and geodesy. The changes should require minor-to-no changes to software implementations of the standard.
17
19
18
20
## Introduction
19
21
@@ -25,7 +27,7 @@ With only a slight dose of exaggeration, that world view can be described in bri
25
27
26
28
> Geodetic coordinate systems, like their mathematical namesakes, are built on an axiomatic foundation, an eternal, immutable ether called WGS84. And **ANY** coordinate system can be strictly defined as a 7 parameter Helmert transformation from WGS84.
27
29
28
-
While surficially nonsensical, this world view is actually quite reasonable: It is simple to implement and sufficiently accurate if the expected georererence accuracy, as in the 1990's, is at the metre level.
30
+
While surficially nonsensical, this world view is actually quite reasonable: It is simple to implement and sufficiently accurate if the expected georeference accuracy is at the metre level, as it was in the 1990's.
29
31
30
32
But with steadily increasing accuracy requirements, and with the ubiquity of GNSS, the conceptual world view of that era has long ago ceased being generally feasible. And with 19111(2019), the standard took huge leaps toward a more geodetically realistic, while still end user applicable, conceptual world view.
31
33
@@ -39,15 +41,14 @@ As 19111 (along with 19161) describes the relation between coordinates as number
39
41
40
42
## Item 0: Empirical contraptions vs. axiomatic idealizations
41
43
42
-
It is still entirely underexposed in 19111, that geodetic reference frames are **empirical contraptions**, while geometric coordinate systems are **axiomatic idealizations**. and that the only way to establish a connection between the abstract coordinate tuples, and the concrete physical world, is by basing that connection on a reference frame squarely embedded in that physical world.
43
-
44
-
So to remedy this, 19111 should stop talking about coordinates referred to metadata (as in [Figure 3](https://docs.ogc.org/as/18-005r4/18-005r4.html#figure_3)): Coordinates are surveyed *according* to rules given in reference **system** definitions, but *referred* to reference **frames**.
44
+
It is still overly underexposed in 19111, that geodetic reference frames are **empirical contraptions**, while geometric coordinate systems are **axiomatic idealizations**. and that the only way to establish a connection between the abstract coordinate tuples, and the concrete physical world, is by basing that connection on a reference frame squarely embedded in that physical world.
45
45
46
-
The georeference does not change when a transformation is applied. But through the transformation, the data referred to reference frame **A** may be made somewhat more interoperable ("aligned") with those referred to frame **B**.
46
+
So to remedy this, 19111 should stop talking about coordinates referenced to metadata (as in [Figure 3](https://docs.ogc.org/as/18-005r4/18-005r4.html#figure_3)), but rather try to make clear that e.g:
47
47
48
-
Transformations are *empirical predictions*, not magic wands conjuring up new georeferences without having to do the surveys.
49
-
50
-
Geodetic reference frames are given as coordinate- and velocity lists (or, equivalently in the satellite navigation case: as ephemerides), not as orthogonal unit vectors in an idealized vector space.
48
+
- Coordinates are surveyed and adjusted *according* to rules given in reference **system** definitions, but *referenced* to reference **frames**.
49
+
- The georeference does not change when a transformation is applied. But through the transformation, the data referenced to reference frame **A** may be made somewhat more interoperable ("aligned") with those referenced to frame **B**.
50
+
- Transformations are *empirical predictions*, not magic wands conjuring up new georeferences without having to do the surveys.
51
+
- Geodetic reference frames are given as coordinate- and velocity lists (or, equivalently in the satellite navigation case: as ephemerides), not as orthogonal unit vectors in an idealized vector space.
51
52
52
53
19111 ties coordinates to the physical reality, and should not be ashamed of that.
53
54
@@ -62,13 +63,13 @@ In section 3.1 "Terms and definitions", the two notes to item 3.1.12 "coordinate
62
63
>
63
64
> - Note 2 to entry: A coordinate transformation is colloquially sometimes referred to as a 'datum transformation'. This is erroneous. A coordinate transformation changes coordinate values. It does not change the definition of the datum. In this document coordinates are referenced to a coordinate reference system. A coordinate transformation operates between two coordinate reference systems, not between two datums.
64
65
65
-
Let's dig deeper into this under item 7 below, but first, let's look at a few easier-to-handle insufficiencies of 19111(2019):
66
+
Let's dig deeper into this under item 7 below, but in the meantime, let's look at a few easier-to-handle insufficiencies of 19111(2019):
66
67
67
68
## Item 2: `CoordinateSet` is vaguely defined, and not sufficiently useful
68
69
69
70
In 19111, `CoordinateSet` is the fundamental interface to actual data (cf. fig 5, sect. 7.4).
70
71
71
-
The `CoordinateSet` interface models something that, in practical implementations would be e.g. *a stack* or *an array* of `CoordinateTuple`s combined with a link to the relevant `CoordinateMetadata`.
72
+
The `CoordinateSet` interface models something that, in practical implementations would be e.g. *a stack, list, or array* of `CoordinateTuple`s combined with a link to the relevant `CoordinateMetadata`.
72
73
73
74
The `CoordinateMetadata` consists of either a `CRSid` or a `CRS`, and (if the CRS is dynamic) a `coordinateEpoch`.
74
75
@@ -88,7 +89,7 @@ But anything derived one way or another from GNSS-observations, is inherently *s
88
89
89
90
**Fourth:** The `CoordinateSet` interface repairs on this missing property by pushing the chronoreference to the metadata-interface, *where at most one epoch is allowed!*
90
91
91
-
I have a very hard time trying to construct a practical use case for this. GNSS-time series consist of observations at epoch `(t_0, t_1,.., t_n)`, and each observation is referred to the dynamic reference frame *at the observation epoch*.
92
+
I have a very hard time trying to construct a practical use case for this. GNSS-time series consist of observations at epoch `(t_0, t_1,.., t_n)`, and each observation is referenced to the dynamic reference frame *at the observation epoch*.
92
93
93
94
**Hence:** No one in their right mind would ever transform their observations to a common epoch, and throw away the time component (making it impossible to transform back to the actual observation).
94
95
@@ -114,14 +115,14 @@ The concept of a CRS (as a brief way of referring to a potentially huge hodge-po
114
115
115
116
But since a CRS *is not a system,* could we find a reasonable alternative expansion of the CRS acronym, replacing "Coordinate Reference System"?
116
117
117
-
**Proposal:***Coordinate Reference **Specifier***seems reasonable to me.
118
+
**Proposal:***Coordinate Reference **Specifier***or *Coordinate Reference **Selector*** both seem reasonable to me, but I'm sure native English speakers can come up with better alternatives.
118
119
119
120
## Item 4: The CRS concept leads to unnecessary complication
120
121
121
122
According to 19111, a CRS has a "definition".
122
123
The typical CRS today, consists of a reference frame plus some kind of coordinate operation
[Figure 3](https://docs.ogc.org/as/18-005r4/18-005r4.html#figure_3)illustrates some of this.
125
126
126
127
Referer til metadata, men geodæsi handler om at referere til virkeligheden. Det er 19111's mission - i modsætning til 19107. Og georeferencen er til en referenceramme, ikke til et sæt metadata.
127
128
@@ -141,7 +142,9 @@ But systems come before realizations, and the first realization of a (planned)
141
142
142
143
## Item 6: Support pipelines of operations
143
144
144
-
**TODO!**
145
+
Coordinate operations can be used to align datasets from different referece frames. But often a series of commonly-implemented operations (e.g. operations from the gamut of EPSG Guidance Note 7-2), is needed to implement the alignment between two CRS. While ISO-19111 allows concatenation, it does so only in cases where intermediate CRS exist for every step.
146
+
147
+
This is quite impractical, and we should try to support a way of more directly supporting operation-pipelines
145
148
146
149
## Item 7: Operations are underspecified, and the definitions given are potentially misleading
147
150
@@ -161,15 +164,13 @@ As mentioned in [Item 1](#item-1-the-concept-of-coordinate-transformations-is-wa
161
164
162
165
Rather than being relegated to a footnote in a sub-section, this distinction should be elaborated on at chapter or at least section level.
163
166
164
-
Additional value could be provided by more clearly describing the relation between reversible operations and their inverses. In the current state of affairs, the transformation from A to B that from B to A are just two unrelated transformations.
167
+
**Additional value** could be provided by more clearly describing the relation between reversible operations and their inverses. In the current state of affairs, the transformation from A to B that from B to A are just two unrelated transformations.
165
168
166
-
## Notes
169
+
## Conclusion?
167
170
168
-
**In the light of that world view,** when the apparent center of mass, related to the ED50 datum differs by approximately 200 m from that of WGS84, then it's because the Wise Fathers of ED50 had figured *"wouldn't it be nice with a coordinate system somewhat offset from the earth's centre-of-mass?".*
169
-
170
-
So they equipped an expedition, and went underground to locate the earth's centre-of-mass. Once found, they surveyed an exactly defined differential distance from there, drove a stake into the earth's inner core at exactly that position, and declared with celebration: **"From here, we will survey our continent".**
171
+
No - but perhaps we should vote for revision!
171
172
172
-
## Further reading
173
+
## Further reading (on Rust Geodesy)
173
174
174
175
### Geodesy ruminations
175
176
@@ -185,3 +186,13 @@ So they equipped an expedition, and went underground to locate the earth's centr
-[Rumination 008](https://github.com/busstoptaktik/geodesy/blob/main/ruminations/008-rumination.md): Geodesy from a PROJ perspective
187
188
-[Rumination 009](https://github.com/busstoptaktik/geodesy/blob/main/ruminations/009-rumination.md): Teach yourself Geodesy in less than 900 seconds (of arc)
189
+
190
+
## Endnotes
191
+
192
+
**In the light of that world view,** when the apparent center of mass, related to the ED50 datum differs by approximately 200 m from that of WGS84, then it's because the Wise Fathers of ED50 had figured *"wouldn't it be nice with a coordinate system somewhat offset from the earth's centre-of-mass?".*
193
+
194
+
So they equipped an expedition, and went underground to locate the earth's centre-of-mass. Once found, they surveyed an exactly defined differential distance from there, drove a stake into the earth's inner core at exactly that position, and declared with celebration: **"From here, we will survey our continent".**
195
+
196
+
problemet med kommunikation når standarden ikke svarer til geodæsien, og kommunikationen bliver stedse vigtigere når nøjagtighedskravene bliver større
197
+
198
+
De praktiske ændringer i implementeringer vil være minimale, men kommunikationen med slutbrugere vil være simplere
0 commit comments