Discontinuity at the edge of "patch" spatial models

[ccrook]

(Issue from the meeting discussion 2/11/2020) Where a component spatial model does not cover the full extent of the deformation model there was a concern that there could be a discontinuity at the edge of the component. For example if the component is a "patch" representing deformation due to an earthquake then it may only cover the area where the deformation is significant (in the context of the deformation model transformation). However at the edge of the patch the deformation due to the earthquake is non-zero, and when the patch is added into the total deformation this could create discontinuity at that edge.

There are at least three ways that this could be managed:

• Enforce continuity in the formulae defined for evaluating and/or combining a patch component into the model
• Assume that deformation model producers will construct models to ensure continuity (for example by defining the deformation at the edge of the patch to be zero). Specify that deformation models must be constructed to ensure continuity.
• As above but do not require continuity for a valid model - this will make some transformation within the scope of the deformation model impossible or ambiguous where the discontinuity means there are two possible points transformed to the same location
• As above but require producer to specify handling of discontinuity/noninvertibility

This was discussed briefly in a previous meeting at which there may have been a consensus that the functional model should not require continuity, but that it should recommend providers ensure continuity and warn of the implications of not doing so.

Note that a similar issues applies within nested grid spatial components if the deformation at the edge of subgrids does not match that of the parent grid within which they lie (correct terminology for subgrids/parent grid notwithstanding!)

This issue is to track the decision:

• Should the deformation model functional model require continuity of the displacement field

[kevinmkelly]

From a GIS perspective, I would say that continuity is so highly desirable as to make it even mandatory. This does not mean that the DMFM should require continuity of the displacement field, but it should at a minimum encourage producers to construct models to ensure continuity, and, if the model is discontinuous to specify or recommend how the model should be implemented in regions of discontinuity. This approach may not be the most desirable because it leaves the DMFM open to numerous potential implementations by producers of how to proceed in the critical areas of discontinuity. This harks back to the GGXF problem - as many grid formats as producers. So, on the other hand, perhaps the DMFM should require continuity of the displacement field? Please pardon my ambivalence here!

[ccrook]

This approach may not be the most desirable because it leaves the DMFM open to numerous potential implementations by producers of how to proceed in the critical areas of discontinuity.

For any approach I hope that the functional model will be explicit and complete in terms of the algorithms to use and what the result will be. It will mean that some transformations will not be possible (ie will return a no-data value or equivalently throw an exception). One area of potential ambiguity in this case is for a time and location where the spatial model cannot be evaluated because of discontinuity but the time model evaluates to zero so the spatial model is not needed). I think if the time model does evaluate to zero (notwithstanding potential round issues) then the spatial model can be ignored. For example transforming between two epochs after an earthquake should be possible.

That said I agree that continuity is highly desirable even if it is not mandatory. I think the functional model should strongly encourage producers to make models that are continuous. Software tools for checking the conformance of a model with the specification could generate warnings if it is not continuous.

[rstanaway]

From a user's perspective, I would definitely support continuity across the model boundary edge. For low precision applications, a few cm discontinuity (step) at the model edge is insignificant, but for RTK usage that would definitely be an issue. Consider a model edge cutting across a civil project area where RTK and other terrestrial techniques are used. Based on that, deformation model edge values should evaluate to zero. If the model edge is between two different resolution grids in a nested grid structure, interpolation of the "child" grid should be identical to interpolation of the "parent" grid along the child grid edge (for the same reasons as above). The aim would be to reduce artificial strain in the coordinate system.

[ccrook]

Definitely agree that for most users and most producers this is desireable. The question is perhaps whether it is mandatory, and how it is enforced (validity check, algorithms that enforce continuity (but are slightly more complex).

My inclination is to not to use more complex algorithms to enforce continuity. We can implement validation tools to check continuity as well as tools to help build continuous models.

We could also add model metadata to indicate whether the model is continuous or not. Or possibly more a complete statement about where/when the model is unique and invertible

[rouault]

Is the issue only continuity ? You could have a continuous field, but not bijective/invertible. Imagine a grid of 3 columns x 2 rows with 1 degree step, with the values for the longitude shift component being, +1, 0, -1 +1, 0, -1 Bilinear interpolation within that grid will result in a final position being always the same (a constant function is continuous), but it is obviously non invertible

Anyway, it seems to me that any requirement regarding this is a bit like saying "don't put junk into your models". Even if we put a formal requirement for continuity / invertibility, there's no quick way for a software to ensure that this requirement is met (even if there's a metadata item, it could be lying), so software that want to be robust need to be able to deal with something that will not follow the requirement, so for example when evaluating the inverse transformation, it must be ready to exit in error after a number of iterations, if the convergence criterion is not met, for example.

[ccrook]

MD: If we make mandatory then can choose to relax that at a later date. Whereas it would be hard to enforce at a later date if already have models which are not continuous.

ER: Could be very hard to verify in software.

MD: But software does not need to enforce.

ER: Ideally would want test suite for validating model

MD: If have continuity then also need to specify behaviour at discontinuity

[ccrook]

Consider ivnertibility as separate issue?

[desruisseaux]

Just a little correction in the sentence "If have continuity then also need to specify behaviour at discontinuity". I mean "If the standard allowed discontinuity, then it would need to specify behaviour at those discontinuities", which may be difficult. If the standard does not allow discontinuity, then we can said that behaviour at discontinuity is unspecified in current standard (but could be specified in a future version of the standard if desired).

[ccrook]

See also the GGXF issue on continuity at https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/issues/7

[ccrook]

Is the issue only continuity ? You could have a continuous field, but not bijective/invertible.

Mathematically it is possible to define models that are continuous but not invertible as well as invertible but not continuous (eg a block offset across a fault line). However in real deformation model based transformations neither of these is likely.

In the context of transformation invertibility is the more critical characteristic. In particular this is true because the deformation model typically defines the trajectories of points relative to their reference coordinate in an inaccessible coordinate system (eg at a fixed historic epoch). So the only way to access the reference coordinate is using the inverse transformation.

[ccrook]

25 Jan 2021 meeting: Specify that model should be invertible AND continuous.
RL: Does this preclude eg bicubic interpolation? KK: What should guidance producer give if not cont or inv. CP: Model could be accompanied by paper describing how to handle

JF: Real deformation has discontinuities KK: Should eg PMM should maybe handle full detail of model JF: Can be handled by finer grid except within cell containing fault line. Should there be a flag to indicate lack of accuracy in these zones.

MD: Distinguish between discontinuity of actual displacement, and discontinuity due to gridding artefacts. JF: Sees value in a flag indicating significant deformation issue over and above uncertainty

KK: Potential of using model to represent different aspects of deformation (eg deep seated, shallow) by attributes of model components. KR: Is this a question of scale. What is scale of deformation model being provided.

JF: Two issues - continuous creep, major events

Possibility of "multipurpose" model not appropriate for version 1 functional model but should have comment on it for future consideration...

[ccrook]

The abstract specification as written requires a model to be continuous.

The displacement defined by the model is required to be continuous and invertible within the spatial and temporal extent of the model except where it evaluates to no data. This is not necessarily enforced by the mathematical formulation of a model. It is a compliance requirement on producers of functional models. Continuity can be assumed by software implementations of the model.

Also discussed in Appendix A2: Requirement for the model to be continuous and invertible

This issue is now closed - however as noted above there is a related discussion in #29