Comments on C. Crook’s
“Deformation Model Functional Model straw man”
Comments by Kevin M. Kelly
Overview
“A deformation model is a model of the displacement of the earth’s surface within a defined spatial and temporal extent. It predicts the location of a point fixed to the surface at an any time within the temporal extent in terms of an accessible coordinate system. The coordinate of the point is calculated as a displacement from a time independent reference coordinate for that point.”
Comment: I thought we modified this definition?
“5. The deformation model defines a trajectory for each point on the physical surface by adding the calculated displacement as function of time to the position used to evaluate the spatial model. This trajectory is terms of an explicitly defined accessible coordinate system.”
Comment: Is the trajectory given on the “physical surface” or is it given on the ellipsoid or mapping plane, neither of which is the physical surface? Item 4 states displacement can be in degrees, which must be given on the ellipsoid.
“6. The position used to calculate the spatial model is not defined in a currently accessible coordinate system - it may be in terms on an accessible coordinate system at a specific epoch. Its value is only accessible by an inverse calculation using the deformation model. See the inverse calculation method below.”
Comment: This begs the question of what is meant by “accessible coordinate system” in the definition of the deformation model given in the Overview.
CC I'm not sure who came up with the term "accessible". (Dana? Mike?) - but I understood it to be a term defined in the OGC/standards world. It would be good to find a source reference for it and confirm it is what I think it is!
“7. The spatial model may be represented by either:”
Comment: The idea that “…the nesting algorithm identifies which grid is applicable…” is subject to interpretation on implementation. The DMFM must specify this algorithm.
CC The DMFM details may specify a specific scheme for nesting. In the high level specification I was thinking it is sufficient to say that there much be an algorithm that uniquely identifies which grid is used at a particular location. In fact this is all that is required for a multiple grid spatial model - it doesn't actually need to be nested or have any other particular spatial organisation. But nesting and aligned parent child grids makes it easier to ensure conditions such as spatial continuity of the spatial model
Comment: “Grids with rows equally spaced and columns equally spaced.” In the section Calculation formulae, the statement is made: “Note that the longitude and latitude grid spacing need not be equal…” Are these two statements conflicting?
CC not intentionally. The are two different ways of trying to say the same thing. rows (latitude) are equally spaced, columns (longitude) are equally spaced. the latitude spacing is not necessarily the same as the longitude spacing. I'll reword this to be clearer. Amended the second to "the longitude grid spacing need not be equal to the latitude grid spacing"
Comment: “Grids are strictly nested….” This needs a definition of “root grid”, “parent grid” and “child grid”.
“9. Each component includes metadata defining:”
Comment: Attempt to provide an exhaustive list of metadata, if this one is not.
CC I agree this should be a minimum required list of metadata. Implementations may choose to include additional metadata of course. I imagine that other members of the meeting will identify what is missing.
“10. Each deformation model includes metadata defining:”
Comment: Attempt to provide an exhaustive list of metadata, if this one is not. Though the following statement is listed in this metadata point: “The target CRS definition (if the deformation model is implemented as a point motion model this will be the same as the source CRS).” In the broader DMFM design, what if the deformation model is a plate motion model which typically does not specify a CRS as per ISO 19111?
Comment: Need to add: Units of the time function. This is decimal years as per the section Time functions.
CC The units of the spatial model are the units of the values it defined, not the units of the definition space (typically degrees). The time function defines a value which is a scalar function and has no units
Comment: “The algorithm used to apply add the deformation to the reference position coordinates.” Presumably, this is just a name because clearly, this is not metadata, but part of the deformation model itself?
Comment: This strawman model specifies only bilinear interpolation. Is this method optimal or appropriate in all cases? What other interpolation methods could be specified or recommended, if any? If other methods are allowed, how would the standard ensure all methods yield acceptable results?
CC To be implementable the specification must define all the algorithms that may be required. I have put in bilinear as it is widely used (and I can copy documentation I have already written). As a group we can decide if we want to add other methods. Each method we add is an extra burden for implementation - though probably not a very large one.
Time functions
Comment: Software implementations can apply their algorithms of choice to convert between decimal year and other time units/scales, but should “certain” time conversion algorithms be provided or referenced as part of the DMFM?
Comment: yyyy-01-01T00:00:00Z may be ambiguous and needs to be defined/clarified. See also previous comment.
“For the uncertainties eh, ev the scale factor fe(t) is defined as √abs(f(t)-f(t0)) where t0 is the uncertainty reference epoch of the model.”
Comment: This is confusing; what does it mean and why is it here?
Comment: “velocity f(t) = (t – t0) all values of t” – For practical/geodetic applications, should t be bounded, possibly in both directions? Presumably, a local/regional velocity model is limited in both spatial and temporal extent, unlike a plate motion model which could possibly permit unbounded t.
CC I've amended the opening paragraph of "Time functions" to include "The deformation model metadata defines a temporal extent of the model from tmin to tmax. Time functions are considered undefined and the model cannot be evaluated for times before tmin or after tmax."
Combination of components
“To calculate the total deformation at a time and location, the displacement and uncertainties due to each component are calculated independently and then summed together to obtain the total displacement at a location.”
Comment: We do not need to sum uncertainties to calculate and apply the total displacement. Also, take care in terminology: we can sum variances, but if uncertainty is given as a standard error, we cannot sum these. The wording here is inconsistent with the (correct) example given a few lines down.
CC: Amended to "To calculate the total deformation at a time and location, the displacement and uncertainties due to each component are calculated independently and then combined using the formulate below to obtain the total displacement and uncertainty at a location."
Comment: The terms “time” and “epoch” are used, presumably interchangeably. If there is no distinction, choose one term throughout – it seems “epoch” is the lingua franca in this domain.
“The same input position coordinate is used for each component - the components are not applied sequentially (ie the coordinate is not updated by the first component before being used to calculate the deformation on the second component). See the discussion below on using the same position for each component.”
Comment: Proposed change for less confusion: “The same input position coordinate is used to interpolate each component.”
“One extra subtlety that may occur in calculating errors is that more than one component may use the same grid file. In this case the scale factors for the components using the grid are simply added together before being combined with the other components using RSS.”
Comment: Confusing; difficult to know clearly what this means.
CC I agree. I'll amend the functional model to remove this and (as per issue https://github.com/opengeospatial/CRS-Deformation-Models/issues/18) allow the time function to have multiple components. This was a careless hangover from the LINZ CSV format into the PROJ JSON/GeoTIFF format that I really should have done better then!
Applying the offset to a coordinate
“The method used to add the calculated displacement to the coordinates of the reference position is defined in the deformation model metadata.”
Comment: What is meant by “reference position” here? It is really “the point in question” or the “calculation point”, or something like that. “Reference position” connotes an idea like “reference epoch” which is not what is meant here.
CC I've added a description of "reference coordinate" at the beginning of this section. Does that help?
Addition method
“If the source and target coordinate systems are projected coordinate systems then the units must be metres and the east and north displacements are simply added to the easting, northing ordinate.”
Comment: This implies that the displacement grid(s) are supplied in a projected coordinate system (PCS). If so, this is not dealt with clearly in this “strawman” DMFM. I have never seen velocity model grids or displacement grids delivered in a PCS, though that does not mean there aren’t any, it’s just not common practice. Without clarity, I can see implementers adding topocentric NEU displacements to PCS Northings and Eastings, which is incorrect and would yield erroneous results.
CC Indeed it is proposing that displacement grids could be supplied in a projected coordinate system. I could imagine more local usages of a deformation model doing that. Also it is an alternative way of managing a deformation model in a polar region. I put this in the JSON/GeoTIFF format as I could see a reason to exclude it, and have carried it through to this straw man.
Comment: The given equation for b cannot be correct; it states that b is a function of b.
CC Asciidoc formatting error - three lines of equations merged in to one
“The vertical offset is always in metres and is simply added to the height coordinate.”
Comment: What is the “vertical offset”? Is this the vertical displacement interpolated from the deformation grid?
CC - yes it is. I have been horribly inconsistent. I've fixed some of the inconsistencies based on your comments but if we end up using this we can fix up what's left in the final editing.
Can confusion and subsequent errors arise if we have a 2D geographic CRS and a 1D gravity-based vertical coordinate system (VCS). If the vertical displacement from the DMFM is along the ellipsoidal normal in the topocentric NEU system, then the U-coordinate will differ from this VCS vertical coordinate by the deflection of the vertical and the quoted statement above would not apply. Though perhaps not an issue for the DMFM itself, but rather its implementation.
CC In practice I think this is not likely to be an issue but in terms of providing an authoritative definition it does need to be resolved. I think the answer is that it is whatever the target coordinate system defines as vertical, and if it does not define a vertical coordinate then it is undefined.
Geocentric addition method
“The vertical coordinate is always calculated by simple addition of the height displacement to the reference coordinate height.”
Comment: Do the terms: “height displacement”, “vertical offset” and “vertical displacement” mean the same thing? What is meant by “reference coordinate height”? Needs consistency.
CC yes they do .. and yes it does
“This is shown in the figure where the grey vector shows adding an offset to the longitude, and the black vector shows applying the offset as a vector offset to the coordinate. Close to the pole the eastward vector is different to changing the longitude coordinate”
Comment: What is the difference between “the longitude” and “the coordinate”? We now introduce the term “vector offset” for the first time. Some confusion arises about applying a vector offset to a single direction or to the “longitude component” of a position vector. Also, the “eastward vector” is really the “east component”.
“In particular the conversion from geocentric to geographic coordinates does not have a closed formula, so this calculation must be iterated to obtain the required accuracy for the conversion.”
Comment: Just a note that there are non-iterative methods to convert from Cartesian to geodetic coordinates. [See e.g.: Turner, J.D., 2009. A non-iterative and non-singular perturbation solution for transforming Cartesian to geodetic coordinates. J. Geod. 83 (2), 139–145; Borkowski, K.M., 1987. “Transformation of Geocentric to Geodetic Coordinates Without Approximations”, Astrophysics and Space Science, 139: 1-4; Borkowski, K.M., 1989. “Accurate Algorithms to Transform Geocentric to Geodetic Coordinates”, Bulletin Géodésique, 63: 50-56.]
CC Yes ... thanks for the reminder. My brain seems to be in the past on this one. I need to implement this in code then I'll remember it hopefully!
Discussion points
Decomposition into components
“Currently deformation models for coordinate operations have not included this level of detail. It may be that this is a requirement in the future however.”
Comment: Not sure about this. The U.S. NGS program Horizontal Time-Dependent Positioning (HTDP) has a deformation model for postseismic displacement due to the November 3, 2002 Mw7.9 Denali earthquake and is applied as a coordinate operation. [See: Snay RA, Freymueller JT, Pearson C (2013) Crustal motion models developed for version 3.2 of the Horizontal Time-Dependent Positioning utility, J. Appl. Geod., 7:173-190, doi: 10.1515/jag-2013-0005.]
Comment: Also, ITRF2014 is generated with an enhanced modeling of nonlinear station motions, including seasonal (annual and semiannual) signals of station positions and postseismic deformation for sites that were subject to major earthquakes. These are also in the class of coordinate operations. [See: Altamimi, Z., Rebischung, P., Métivier, L., & Collilieux, X. (2016). ITRF2014: A new release of the International Terrestrial Reference Frame modeling nonlinear station motions. Journal of Geophysical Research: Solid Earth, 121(8), 6109-6131.]
Comment: This “level of detail” is required currently for many recent large magnitude events.
CC I think I wasn't clear what I mean be "level of detail". The proposal allows for any amount of detail in the spatial model and in the time function. It doesn't provide for a model that cannot be built this way. For example one built on a triangulation between nodes which have different time functions (eg ITRF2014 reference stations).
CC The plate motion models are I suppose deformation models, though I do not believe they actually handle deformation in the boundaries between plates, they just define the rigid body motion of each plate. AFAIK the discontinuity at the boundary where the deformation happens is not handled? I've added a note to the discussion of decomposition of the model. I think these are out of scope for us?
Time functions
“This can be encoded using this functional model by a series of gridded spatial models with time functions as illustrated below to interpolate between them.”
Comment: The diagram is not very useful without an explanation and/or example.
CC I agree - it doesn't add much to the discussion and I have removed it and slightly amended the discussion
Geocentric interpolation near poles
Comment: There are many ambiguous and confusing items in this section. Paragraph 1. What “…difference in direction…”? Explain. Where is B? What does “past A” mean? Are we interpolating a “vector”? What does “error of orientation” mean? “Vector error”? Why is it justified to approximate sin(λ) as λ? How did we go from an error in radians to a metric error of 2cm? The term “vector” in this section does not seem to be used correctly or consistently.
Comment: Paragraphs 2 and 3. In the section “Geocentric bilinear interpolation”, there is no mention of du nor its interpolation, it first appears in this section. What is the “leakage” all about? Explain why is it an issue? Why are we concerned about a “scale error”? Or is this an absolute error of 0.2 mm in 1 m? In scale error terms this amounts to 0.2 PPM.
“The reduction is approximately scaling by the cosine of the angle between the vertical at the calculation point and the vertical at each grid node.”
Comment: This angle will be different at each grid node, so evaluating the “error” may be complex.
“Note that this is a 1 degree extent measured on the globe - not a 1 degree extent of longitude which may be much smaller near the poles.”
Comment: Confusing. What does this mean? What may be “much smaller near the poles”?
CC This has suffered cut and paste syndrome - it was originally placed with the formulae for the geocentric bilinear method. I've commented out the confusing and unnecessary second paragraph about "leakage" and added a bit more introduction to the first section estimating the difference between bilinear interpolation and the geocentric implementation.
Sequential or parallel evaluation of components
“The same input position coordinate is used to calculate the deformation for each component.”
Comment: This is confusing because the term “component” is used to refer to different entities: (1) a complete displacement vector in a sum of multiple displacement vectors, and (2) a component, i.e. dn, de, du, of a single displacement vector. This needs clarification and consistency throughout the DMFM.
CC Agreed - I haven't found a better word yet for either and this has been a recurring issue for me documenting deformation models. For the moment I'll leave it and maybe as a team we can decide what we prefer and then edit the document to match
“Neither method is more correct from a theoretical point of view.”
Comment: But if the two methods are not equivalent, there must be some convincing rationale to recommend one over the other. The example is not convincing.
CC I have given three reasons for preferring the recommended approach. That is as much rationale as I can come up with. Mainly I think it doesn't matter (it hardly ever will in practice) but we have to specify one preferred method to ensure that producers of models can build them with confidence that the consumers will interpret them in the same way.
Significance of iteration for the inverse deformation model evaluation
Comment: A detailed and fully worked out numerical example should be provided.
CC I guess this comment applies to all the formulae? Maybe that can be a job once we have agreed the functional model definition.
Comment: Is the trajectory given on the “physical surface” or is it given on the ellipsoid or mapping plane, neither of which is the physical surface? Item 4 states displacement can be in degrees, which must be given on the ellipsoid.
The trajectory is of the point, ie it should identify where the point is at any given time (though actually it is of any point which is identified with the 2 dimensional location (lat/lon) by adding the appropriate height to it. But the one it is calculated from is typically (more or less) in the surface. It is of course an imperfect representation of that true trajectory of a point, but the purpose of this statement is to say that it is tracking (or attempting to track) a physical object.
A deformation model is a model of the displacement of the earth’s surface within a defined spatial and temporal extent. It predicts the location of a point fixed to the surface at any time within the temporal extent in terms of an accessible coordinate system. The position of the point is represented as a displacement from a reference position for that point.
The strawman has this definition:
A deformation model is a model of the displacement of the earth’s surface within a defined spatial and temporal extent. It predicts the location of a point fixed to the surface at an any time within the temporal extent in terms of an accessible coordinate system. The coordinate of the point is calculated as a displacement from a time independent reference coordinate for that point.
Comment: “The algorithm used to apply add the deformation to the reference position coordinates.” Presumably, this is just a name because clearly, this is not metadata, but part of the deformation model itself?
For me this falls in a grey area between metadata and data. Things like the grid longitude and latitude extent I think are data. The algorithms used to evaluate and apply the deformation must be agreed to ensure they are evaluated in a consistent way could be data, or they could be part of a specification. Similarly the coordinate systems could be data but they also come from the registries which identify which deformation model is used in a particular instance. Things like the licence, publisher, etc are clearly metadata that are not required to use the model (but may be required to assess its usefulness). Doubtless this can be debated at length - and I'll readily defer to those with more experience of standards.
In this case I would imagine that the algorithm data/metadata is an enumerated value (aka name!) that specifies which algorithms are to be used. The specification should include the formulae that are to be used for each possible value of that enumeration.
Comment: Software implementations can apply their algorithms of choice to convert between decimal year and other time units/scales, but should “certain” time conversion algorithms be provided or referenced as part of the DMFM?
As written the strawman assumes an algorithm to convert a date/time to an epoch in seconds. I suspect (from your other comments) this could be worded more clearly! I don't think the specification needs to provide this - it is well defined and implemented in every language+standard library I know of. On the other hand conversion to decimal years is non-standard.
It is arguable that we shouldn't do this, as it is a "non-uniform" unit of time, being different between leap years and non-leap years (as well as the occasional leap second). But because standard practice in the deformation world has to express rates as a per year velocity it makes sense to me to use this approach.
A deformation model is a model of the displacement of the earth’s surface within a defined spatial and temporal extent. It predicts the location of a point fixed to the surface at any time within the temporal extent in terms of an accessible coordinate system. The position of the point is represented as a displacement from a reference position for that point.
The strawman has this definition:
A deformation model is a model of the displacement of the earth’s surface within a defined spatial and temporal extent. It predicts the location of a point fixed to the surface at an any time within the temporal extent in terms of an accessible coordinate system. The coordinate of the point is calculated as a displacement from a time independent reference coordinate for that point.
Hmmm ... I think I need my eyes tested. Now (I earnestly hope) reading the same as our definition
“For the uncertainties eh, ev the scale factor fe(t) is defined as √abs(f(t)-f(t0)) where t0 is the uncertainty reference epoch of the model.”
Comment: This is confusing; what does it mean and why is it here?
I have amended this to
For the uncertainties eh, ev the magnitude of the uncertainty is determined relative to the uncertainty reference epch. The scale factor to apply to undertainties is fe(t) is defined as √abs(f(t)-f(t0)) where t0 is the uncertainty reference epoch of the model.
@kevinmkelly I have now addressed all you points. This has greatly improved the strawman, even though there there is doubtless a way to go. (at a very minimum adding additional time function base functions and adding formulae for triangulated networks). Thanks for the detailed review
I think perhaps the next step is to diagram the entire DMFM out in a process flowchart showing the numerical parameters and data needed, where they will come from and how they are used in an actual computation. This should, of course, include all branch and/or decision points. We should also have a few numerical examples of common deformation computations, if not fully calculated, then showing the algorithm(s) to use to get "the answer". Such an exercise may help with designing an encoding/format of the data and parameters consumed by an application to compute a result.
@kevinmkelly I can't quite picture what you are suggesting in terms of the diagram. Is there an example of the sort of thing that you could point me to?
“A deformation model is a model of the displacement of the earth’s surface within a defined spatial and temporal extent. It predicts the location of a point fixed to the surface at an any time within the temporal extent in terms of an accessible coordinate system. The coordinate of the point is calculated as a displacement from a time independent reference coordinate for that point.” Comment: I thought we modified this definition?
Functional definition of the deformation model
“5. The deformation model defines a trajectory for each point on the physical surface by adding the calculated displacement as function of time to the position used to evaluate the spatial model. This trajectory is terms of an explicitly defined accessible coordinate system.” Comment: Is the trajectory given on the “physical surface” or is it given on the ellipsoid or mapping plane, neither of which is the physical surface? Item 4 states displacement can be in degrees, which must be given on the ellipsoid.
“6. The position used to calculate the spatial model is not defined in a currently accessible coordinate system - it may be in terms on an accessible coordinate system at a specific epoch. Its value is only accessible by an inverse calculation using the deformation model. See the inverse calculation method below.” Comment: This begs the question of what is meant by “accessible coordinate system” in the definition of the deformation model given in the Overview.
“7. The spatial model may be represented by either:” Comment: The idea that “…the nesting algorithm identifies which grid is applicable…” is subject to interpretation on implementation. The DMFM must specify this algorithm.
Comment: “Grids with rows equally spaced and columns equally spaced.” In the section Calculation formulae, the statement is made: “Note that the longitude and latitude grid spacing need not be equal…” Are these two statements conflicting?
Comment: “Grids are strictly nested….” This needs a definition of “root grid”, “parent grid” and “child grid”.
“9. Each component includes metadata defining:” Comment: Attempt to provide an exhaustive list of metadata, if this one is not.
“10. Each deformation model includes metadata defining:” Comment: Attempt to provide an exhaustive list of metadata, if this one is not. Though the following statement is listed in this metadata point: “The target CRS definition (if the deformation model is implemented as a point motion model this will be the same as the source CRS).” In the broader DMFM design, what if the deformation model is a plate motion model which typically does not specify a CRS as per ISO 19111? Comment: Need to add: Units of the time function. This is decimal years as per the section Time functions.
Comment: “The algorithm used to apply add the deformation to the reference position coordinates.” Presumably, this is just a name because clearly, this is not metadata, but part of the deformation model itself?
Calculation formulae
Comment: This strawman model specifies only bilinear interpolation. Is this method optimal or appropriate in all cases? What other interpolation methods could be specified or recommended, if any? If other methods are allowed, how would the standard ensure all methods yield acceptable results?
Time functions
Comment: Software implementations can apply their algorithms of choice to convert between decimal year and other time units/scales, but should “certain” time conversion algorithms be provided or referenced as part of the DMFM?
Comment: yyyy-01-01T00:00:00Z may be ambiguous and needs to be defined/clarified. See also previous comment.
“For the uncertainties eh, ev the scale factor fe(t) is defined as √abs(f(t)-f(t0)) where t0 is the uncertainty reference epoch of the model.” Comment: This is confusing; what does it mean and why is it here?
Comment: “velocity f(t) = (t – t0) all values of t” – For practical/geodetic applications, should t be bounded, possibly in both directions? Presumably, a local/regional velocity model is limited in both spatial and temporal extent, unlike a plate motion model which could possibly permit unbounded t.
Combination of components
“To calculate the total deformation at a time and location, the displacement and uncertainties due to each component are calculated independently and then summed together to obtain the total displacement at a location.”
Comment: We do not need to sum uncertainties to calculate and apply the total displacement. Also, take care in terminology: we can sum variances, but if uncertainty is given as a standard error, we cannot sum these. The wording here is inconsistent with the (correct) example given a few lines down.
Comment: The terms “time” and “epoch” are used, presumably interchangeably. If there is no distinction, choose one term throughout – it seems “epoch” is the lingua franca in this domain.
“The same input position coordinate is used for each component - the components are not applied sequentially (ie the coordinate is not updated by the first component before being used to calculate the deformation on the second component). See the discussion below on using the same position for each component.” Comment: Proposed change for less confusion: “The same input position coordinate is used to interpolate each component.”
“One extra subtlety that may occur in calculating errors is that more than one component may use the same grid file. In this case the scale factors for the components using the grid are simply added together before being combined with the other components using RSS.” Comment: Confusing; difficult to know clearly what this means.
Applying the offset to a coordinate
“The method used to add the calculated displacement to the coordinates of the reference position is defined in the deformation model metadata.” Comment: What is meant by “reference position” here? It is really “the point in question” or the “calculation point”, or something like that. “Reference position” connotes an idea like “reference epoch” which is not what is meant here.
Addition method
“If the source and target coordinate systems are projected coordinate systems then the units must be metres and the east and north displacements are simply added to the easting, northing ordinate.” Comment: This implies that the displacement grid(s) are supplied in a projected coordinate system (PCS). If so, this is not dealt with clearly in this “strawman” DMFM. I have never seen velocity model grids or displacement grids delivered in a PCS, though that does not mean there aren’t any, it’s just not common practice. Without clarity, I can see implementers adding topocentric NEU displacements to PCS Northings and Eastings, which is incorrect and would yield erroneous results.
Comment: The given equation for b cannot be correct; it states that b is a function of b.
“The vertical offset is always in metres and is simply added to the height coordinate.” Comment: What is the “vertical offset”? Is this the vertical displacement interpolated from the deformation grid?
Can confusion and subsequent errors arise if we have a 2D geographic CRS and a 1D gravity-based vertical coordinate system (VCS). If the vertical displacement from the DMFM is along the ellipsoidal normal in the topocentric NEU system, then the U-coordinate will differ from this VCS vertical coordinate by the deflection of the vertical and the quoted statement above would not apply. Though perhaps not an issue for the DMFM itself, but rather its implementation.
Geocentric addition method
“The vertical coordinate is always calculated by simple addition of the height displacement to the reference coordinate height.” Comment: Do the terms: “height displacement”, “vertical offset” and “vertical displacement” mean the same thing? What is meant by “reference coordinate height”? Needs consistency.
“This is shown in the figure where the grey vector shows adding an offset to the longitude, and the black vector shows applying the offset as a vector offset to the coordinate. Close to the pole the eastward vector is different to changing the longitude coordinate” Comment: What is the difference between “the longitude” and “the coordinate”? We now introduce the term “vector offset” for the first time. Some confusion arises about applying a vector offset to a single direction or to the “longitude component” of a position vector. Also, the “eastward vector” is really the “east component”.
“In particular the conversion from geocentric to geographic coordinates does not have a closed formula, so this calculation must be iterated to obtain the required accuracy for the conversion.” Comment: Just a note that there are non-iterative methods to convert from Cartesian to geodetic coordinates. [See e.g.: Turner, J.D., 2009. A non-iterative and non-singular perturbation solution for transforming Cartesian to geodetic coordinates. J. Geod. 83 (2), 139–145; Borkowski, K.M., 1987. “Transformation of Geocentric to Geodetic Coordinates Without Approximations”, Astrophysics and Space Science, 139: 1-4; Borkowski, K.M., 1989. “Accurate Algorithms to Transform Geocentric to Geodetic Coordinates”, Bulletin Géodésique, 63: 50-56.]
Discussion points
Decomposition into components
“Currently deformation models for coordinate operations have not included this level of detail. It may be that this is a requirement in the future however.” Comment: Not sure about this. The U.S. NGS program Horizontal Time-Dependent Positioning (HTDP) has a deformation model for postseismic displacement due to the November 3, 2002 Mw7.9 Denali earthquake and is applied as a coordinate operation. [See: Snay RA, Freymueller JT, Pearson C (2013) Crustal motion models developed for version 3.2 of the Horizontal Time-Dependent Positioning utility, J. Appl. Geod., 7:173-190, doi: 10.1515/jag-2013-0005.]
Comment: Also, ITRF2014 is generated with an enhanced modeling of nonlinear station motions, including seasonal (annual and semiannual) signals of station positions and postseismic deformation for sites that were subject to major earthquakes. These are also in the class of coordinate operations. [See: Altamimi, Z., Rebischung, P., Métivier, L., & Collilieux, X. (2016). ITRF2014: A new release of the International Terrestrial Reference Frame modeling nonlinear station motions. Journal of Geophysical Research: Solid Earth, 121(8), 6109-6131.] Comment: This “level of detail” is required currently for many recent large magnitude events.
Spatial model types
“In practice nearly all current deformation models use grid representations. There is a small usage of triangulated models which is included in this functional model specification.” Comment: It seems this is presupposing deformations models use either grids or TINs. A plate motion model (PMM) can be considered a deformation model; it is not gridded, not a TIN and is widely used. Trimble implements the MORVEL-56 PMM in their CENTERPOINT© RTX POST-PROCESSING SERVICE. Comment: The aforementioned ITRF2014 postseismic motion model can be considered a deformation model; it is not gridded and not a TIN, though not so widely used in the surveying/mapping/GIS domains.
Time functions
“This can be encoded using this functional model by a series of gridded spatial models with time functions as illustrated below to interpolate between them.” Comment: The diagram is not very useful without an explanation and/or example.
Geocentric interpolation near poles
Comment: There are many ambiguous and confusing items in this section. Paragraph 1. What “…difference in direction…”? Explain. Where is B? What does “past A” mean? Are we interpolating a “vector”? What does “error of orientation” mean? “Vector error”? Why is it justified to approximate sin(λ) as λ? How did we go from an error in radians to a metric error of 2cm? The term “vector” in this section does not seem to be used correctly or consistently. Comment: Paragraphs 2 and 3. In the section “Geocentric bilinear interpolation”, there is no mention of du nor its interpolation, it first appears in this section. What is the “leakage” all about? Explain why is it an issue? Why are we concerned about a “scale error”? Or is this an absolute error of 0.2 mm in 1 m? In scale error terms this amounts to 0.2 PPM.
“The reduction is approximately scaling by the cosine of the angle between the vertical at the calculation point and the vertical at each grid node.” Comment: This angle will be different at each grid node, so evaluating the “error” may be complex.
“Note that this is a 1 degree extent measured on the globe - not a 1 degree extent of longitude which may be much smaller near the poles.” Comment: Confusing. What does this mean? What may be “much smaller near the poles”?
Sequential or parallel evaluation of components
“The same input position coordinate is used to calculate the deformation for each component.” Comment: This is confusing because the term “component” is used to refer to different entities: (1) a complete displacement vector in a sum of multiple displacement vectors, and (2) a component, i.e. dn, de, du, of a single displacement vector. This needs clarification and consistency throughout the DMFM.
“Neither method is more correct from a theoretical point of view.” Comment: But if the two methods are not equivalent, there must be some convincing rationale to recommend one over the other. The example is not convincing.
Significance of iteration for the inverse deformation model evaluation
Comment: A detailed and fully worked out numerical example should be provided.
The trajectory is of the point, ie it should identify where the point is at any given time (though actually it is of any point which is identified with the 2 dimensional location (lat/lon) by adding the appropriate height to it. But the one it is calculated from is typically (more or less) in the surface. It is of course an imperfect representation of that true trajectory of a point, but the purpose of this statement is to say that it is tracking (or attempting to track) a physical object.
I thought I had used the modified definition - this is what I had in the definition https://github.com/opengeospatial/CRS-Deformation-Models/blob/master/products/report/clause_2_definition.adoc#definition-of-a-deformation-model at the end of the last meeting. What you do think is different (from what was agreed in the meeting that is)?
I thought we agreed on this definition:
The strawman has this definition:
For me this falls in a grey area between metadata and data. Things like the grid longitude and latitude extent I think are data. The algorithms used to evaluate and apply the deformation must be agreed to ensure they are evaluated in a consistent way could be data, or they could be part of a specification. Similarly the coordinate systems could be data but they also come from the registries which identify which deformation model is used in a particular instance. Things like the licence, publisher, etc are clearly metadata that are not required to use the model (but may be required to assess its usefulness). Doubtless this can be debated at length - and I'll readily defer to those with more experience of standards.
In this case I would imagine that the algorithm data/metadata is an enumerated value (aka name!) that specifies which algorithms are to be used. The specification should include the formulae that are to be used for each possible value of that enumeration.
As written the strawman assumes an algorithm to convert a date/time to an epoch in seconds. I suspect (from your other comments) this could be worded more clearly! I don't think the specification needs to provide this - it is well defined and implemented in every language+standard library I know of. On the other hand conversion to decimal years is non-standard.
It is arguable that we shouldn't do this, as it is a "non-uniform" unit of time, being different between leap years and non-leap years (as well as the occasional leap second). But because standard practice in the deformation world has to express rates as a per year velocity it makes sense to me to use this approach.
Hmmm ... I think I need my eyes tested. Now (I earnestly hope) reading the same as our definition
I have amended this to
This may not help much - it requires first understanding the uncertainty reference epoch.
Also I am not sure this is completely correct - the error isn't necessarily zero at this epoch. This needs a bit more thinking (along with the entirety of handling uncertainty - see https://github.com/opengeospatial/CRS-Deformation-Models/issues/9
@kevinmkelly I have now addressed all you points. This has greatly improved the strawman, even though there there is doubtless a way to go. (at a very minimum adding additional time function base functions and adding formulae for triangulated networks). Thanks for the detailed review
No worries. You are welcome.
I think perhaps the next step is to diagram the entire DMFM out in a process flowchart showing the numerical parameters and data needed, where they will come from and how they are used in an actual computation. This should, of course, include all branch and/or decision points. We should also have a few numerical examples of common deformation computations, if not fully calculated, then showing the algorithm(s) to use to get "the answer". Such an exercise may help with designing an encoding/format of the data and parameters consumed by an application to compute a result.
@kevinmkelly I can't quite picture what you are suggesting in terms of the diagram. Is there an example of the sort of thing that you could point me to?
I think the points in this have now been adequately covered in the strawman document. @kevinmkelly are you ok with closing this issue