Should the deformation model functional model include rigid body rotation?

[ccrook]

The deformation model (in the context of coordinate transformations) is generally used to represent the movement of points fixed to the earth's surface relative to a global coordinate system such as ITRF. For many jurisdictions the majority of this movement movement is due to the rigid body rotation of the tectonic plate on which the area of interest lies. In this case it is most efficient and clear to use the rigid body transformation for most of the movement (eg time dependent 14 parameter Bursa Wolf transformation) so that the deformation only needs to represent the residual distortion of the surface.

Adding the definition of a rigid body rotation to the deformation model definition is a very small addition to the model and its implementations. It could be a useful addition to if it simplifies defining transformations in coordinate system registries or avoids the need for explicitly defining and registering intermediate coordinate systems.

So should the deformation model functional model allow for a rigid body rotation? Or is there a better way of representing a combined transformations?

[rouault]

You make a good point that having the transformation that describes the rigid body rotation outside of the deformation model would require for people using ISO-19111 based modeling (typically EPSG registry) to have an intermediate CRS that might have no meaning as a standalone one, and could complicate integration of the deformation model. So I think the deformation model should have a way of allowing the rigid body rotation description, either by an explicit method, or using a more generic one.

As far as I can see, in the NZGD2000 deformation model, the rigid body rotation was modeled by a grid covering the whole extent of the deformation model (actually a coarser grid for the whole extent and a refined subgrid for EEZ), with a velocity time function.

The grid-based approach simplifies a bit the deformation model specification and implementation (but probably not that much, since anyone interested in implementing a deformation model specification will much certainly have 14 parameter Bursa Wolf transformation already implemented), but complicates a bit the producer's life since they must derive that grid, and find at which resolution the grid approximation is OK compared to the exact evaluation of the Bursa Wolf transformation. Another consideration is that, from a computation point of view, if the deformation model is evaluated in geographic coordinate space, this also saves doing the geographic <--> geocentric conversions needed to evaluate a Bursa Wolf transformation, which have some runtime cost.

If using 14 parameter Bursa Wolf transformation with all parameters, that could cause ellipsoidal height to be changed in the process. Maybe this is desirable in some cases ? If not, then it should perhaps be specified (or recommended) that only the 3 rotation rate terms are included.

[ccrook]

The NZ model does have a coarse velocity grid covering the EEZ, though it is representing two rigid body plate motions (Australasian and Pacific). The transition between them is based on observations in the land area of NZ but a crude interpolation between them in the ocean where it is not measured (and not particularly useful). This is an area where a "no-data" value would be a valid alternative approach.

I was thinking that including a rigid body rotation in the DMFM could be more useful for a country such as Australia, in which the bulk of a point motion model is 7cm per year rigid body rotation. The residual deformation is much smaller and possibly could be represented by a number of local patches.

[kevinmkelly]

I agree that the DMFM should allow for rigid body rotation (RBR). While RBR it is not deformation in the sense we have defined it, or in the pure continuum mechanics sense, it is also not a coordinate system transformation. Since RBR merely translates points via rotation and time function, the CRS of the point(s) undergoing RBR does not change - even though the functional model used to calculate RBR is the rotation part of the so-called Bursa-Wolf transformation (with zero translation and scale parameters). Moreover, since RBR may form one component of the total deformation at a point, it seems to me that it ought to be included in the overall DMFM.

[kevinmkelly]

Before everyone jumps in to expose my "error", let me qualify it. Yes, a RBR may be used to "transform" between CRS's, for example, from ITRF to some fixed-epoch, plate-fixed CRS. But, if only a RBR is applied, then the question arises "what CRS are the data really referred to"? The unrotated CRS or the rotated CRS with merely a new name? Perhaps a bit too philosophical, but interesting to consider.

[rstanaway]

I think the DMFM in principle would be applied the same way for plate-fixed or Earth-fixed CRS. The advantage of the plate-fixed is that the velocities would be negligible for most portions of a stable plate. In the current Australian implementation, the transformation fro ITRF2014 (Earth-fixed) to GDA2020 (Australian Plate-fixed) is simply a 14 parameter Bursa Wolf transformation where most of the parameters are zero, except for the rotation rate parameters which are those of the Australian plate motion model (PMM) described as rotations of the Cartesian axes of the Australian Plate within ITRS. The concept of a "Rigid plate" is strictly speaking theoretical as there is observable deformation within even the most stable plates.

The idea of embedding a PMM within a 14 parameter time-dependent transformation model might seem like overkill considering that 11 of the 14 parameters are zero. The idea of doing that was to minimise the proliferation of different transformation models and to avoid confusion with the use of other conventional three parameter transformations (which are not time-dependent).

[ccrook]

@rstanaway - fair comment on the parameterisation of a rigid body rotation. Do you think the DMFM specification should include rigid body rotation. It would most likely be a simple rotation rate that would apply to the entire area of the model.

[rstanaway]

Hi Chris @ccrook - Yes, for ITRF to local/national/regional frame transformations the PMM (let's say embedded within a 14 parameter model) can account for most of the secular horizontal velocity component of the time-dependent transformation. There may be some residual secular velocity (e.g. near the plate boundary, or where there is intraplate deformation, GIA or other geodynamics process at play) and that could be modelled using a plate-fixed velocity grid. In that situation most velocities would be near zero. The alternative is to just use the direct ITRF velocity grid without the PMM step in which case most velocities would be non-zero.

Countries which straddle plate boundary zones could use a PMM/residual velocity model for each plate, but perhaps more simply use an ITRF velocity grid (like NZ). The use of two PMM within one jurisdiction would require careful definition of the polygon where the PMM would be valid.

[ccrook]

Countries which straddle plate boundary zones could use a PMM/residual velocity model for each plate, but perhaps more simply use an ITRF velocity grid (like NZ). The use of two PMM within one jurisdiction would require careful definition of the polygon where the PMM would be valid.

I think that it would probably very hard to manage the transition between two PMM models. One approach which was hinted at in the last DMFM meeting was using a grid of rotation parameters rather than a grid of displacements. That could certainly work and could be good approach for eg polar areas too. So each grid node would have 3 parameters to define a rotation for horizontal velocity and possible a fourth for vertical velocity. Slightly more complex to build and use (and of course an extra parameter at each node).

I'm not sure if this is in use as a method anywhere. If it were then maybe it could be added to the functional model. My feeling is it is better to keep the model minimal rather than add unnecessary features that are not currently required.

[ccrook]

In the 30 November meeting there was general agreement that it is worth including an optional rigid body rotation. There was also a brief discussion on representation of rotation using a 14 (15ish) parameter Bursa-Wolf transformation, or using a 3(4) parameter Euler rotation pole and rate. There was general preference for a 14 parameter option, even though it allows more than just rigid body rotation, as it is simpler to implement and already built into most coordinate transformation software.

[kevinmkelly]

I suggest we not choose between the two representations and provide both formulations in our document: 14-parameter similarity transformation and Euler pole active transformation, and leave the choice to the implementation.

[ccrook]

This comment from @RogerLott in regard to inclusion of 14 parameter transformations:

1. Should a GGXF file have provision to carry a 14/15-parameter time-dependent Helmert transformation? [this might be a separate Github issue in its own right]

   a) There is nothing grid-related in this. So is this a requirement of a deformation model that is outside the scope of GGXF?

   b) If you want to carry none-gridded coordinate operation methods, why limit it to this particular coordinate operation method - is this to be a general provision for any coordinate operation method?

   c) If there is a case for only a 14/15-parameter time-dependent Helmert transformation (personally I do not think there is in GGXF, there may be in the DM), then why limit it to the "rotation convention used by IERS" (may not be the exact words you used, this to show the intent). That would be what EPSG describes as Position Vector. Other than IERS itself and its inter ITRF (and CTRS > ITRS) transformations, there are probably more cases of the opposite Coordinate Frame rotation convention in practical use in government national mapping agencies across the world today – Australia being an example

[ccrook]

To summarise the comments from above plus some others in favour of implementing a rigid body rotation I think the general agreement was that:

• The rigid body transformation is often a "base transformation" implementing the bulk of deformation, with the gridded model(s) providing detailed perturbation.
• From a testing point of view it is more convenient to be able to test the deformation model in isolation.
• The intermediate coordinate system is not meaningful and implementors may prefer that this not be explicitly defined. I cannot recall whether the coordinate operation can be defined by compiling multiple steps, but if so that remove this objection
• Embedding the 14 parameter transformation in the DM avoids the risk of applying one or other in isolation, or using the wrong 14 parameter transformation, in the same way as compiling the GGXF into a single file avoids incomplete or incorrect versions being used.

On a) above. I believe inclusion in GGXF is valid - it is simple deformation specific metadata in the same way as time functions. I don't see why it should be explicitly excluded just because it happens to implement a coordinate transformation if that is required by the deformation model functional model.

On b) inclusion of a rigid body rotation is specifically included because it is used in practice. Most other coordinate operations are unrelated to physical models (eg projections are purely about mapping, not about the physical earth itself).

On c) totally agree that there is discussion to be had about how it could be represented. My proposal was to support at least one implementation in GGXF. Kevin is suggesting multiple representations above (Euler pole plus 14 param), let alone options for how a 14 parameter transformation is encoded. There is a temptation a decision (and a burden on producers) by supporting multiple options. This however does create an alternative burden on implementers and on the size of the documentation.

I suggest details of encoding options can be sorted once we have broadly agreed content and keywords. Fine tuning proof of concept implementations and documentation after that shouldn't be too hard.

[rstanaway]

A 14/15 parameter transformation that embeds a plate motion model / Euler Pole can be used to estimate a velocity grid (which can then be used as a basis for a supplementary intraframe/intraplate velocity grid). The parametric model by itself is not part of the GGXF scope I wouldn't think. In that sense it is more a functional model issue than a GGXF one.

[ccrook]

@rstanaway definitely it is a FM model issue. The question is whether the GGXF representation of the DM fully encompasses the functional model, or whether it partially implemented in GGXF and partly in some other (implementation dependent) 14 parmeter coordinate transformation specification and implementation. I favour having the full implementation embedded in the single GGXF file, with implementations guaranteeing how the GGXF is calculated (including the 14 param transformation).

[ccrook]

Discussed again at December 2021 meeting but still no general agreement!

[RogerLott]

There seems to be agreement that a 14(15) parameter transformation that is part of a deformation model should be included in the model description. This allows the full model to be described. The issue is whether, and if so how, GGXF should accomodate this non-gridded information.

In the context of a geodetic registry following the 19111 data model, the 14(15) parameter transformation and the gridded data can be separated and described individually, then brought together as a concatenated operation. The advantage of this is that use of only the 14(15) parameter transformation (without any gridded deformation data, so describing secular plate motion) is significantly simplified as the transformation description is straightforward (see e.g. EPSG:9459 or ISOGR:790 for the Australian PMM) and allows implementation use without the [significant] overhead of reading a GGXF file.

So, if a deformation model includes a 14(15) parameter transformation as one of its elements [components :-( ], how does this project team recommend it gets included in a GGXF file?

• Reference to the 14(15) parameter transformation in a geodetic registry?
• A header record containing a well-known text string?
• A header record with an ordered array of parameter values [so including any producer-declared units] and the rotation convention used?
• All of the above?
• If header record, is that the file header or a group header? (Latter will significantly alter requirements of a group header)

If this information is to be included in a GGXF file, I suggest that the deformation model documentation needs to clearly state that a 14(15) parameter transformation can be described in a geodetic registry without any reference to a GGXF file, i.e. a GGXF file and indeed a deformation model is not the recommended mechanism for describing secular motion alone.

[ccrook]

@RogerLott Thanks for suggestions, and excellent questions.

In terms of where it would be included in the model I think it would be a GGXF header attribute(!) It applies to the whole deformation model, not just one element(group). So no worries for the group header.

The argument for including it in the deformation model is where the 14(15) param transformation is a custom transformation implementing the bulk of the deformation, from which the rest of the deformation model defines regional perturbations. The output of the 14(15) param transformation is not a coordinate in a defined CRS. Possibly it is not required to be in a concatenated coordinate operation?

However I think you are also suggesting that users may choose as a fast, low accuracy version of the deformation model transformation. How appropriate that would be would depend on the nature of the deformation I guess. For example in the US a 14 parameter transformation could be a good approximation for most of the continental US, but it would be very bad on the western seaboard. Where it does work it could certainly be valuable in fast, relatively low accuracy operations such as web mapping.

I think the other concern that has been raised is that having a separate 14(15) parameter definition would increase the risk of it being not used in the deformation model, or being out of sync with it. Essentially the same concern as that of having a deformation model distributed across several files rather than in one single file.

Hmmm - I see I am reiterating the comment above at https://github.com/opengeospatial/CRS-Deformation-Models/issues/23#issuecomment-883970104

[ccrook]

This was discussed at length (!) at the meeting on 14/2/2022 - conclusion is 14/15 parameter not appropriate within the context of the deformation model specification.

The main argument in favour of keeping this that an approach such as using a concatenated coordinate transformation does not work if the deformation model is used as a point motion model (describing motion within a coordinate system rather than as a transformation between coordinate systems).

However it was noted that this could be emulated be a coarse resolution grid which would be very efficient to calculate if the model did include a rotation like secular component.

On that basis it has been removed from the abstract specification and this issue finally closed!