ccrook
commented
3 years ago Piecewise function versus using ramp functions
This compares two options for representing piecewise linear time functions in the deformation model function and more particularly in the GGXF group header that will implement the function with a view to choosing which best suits as an implementation approach.
Piecewise functions are desired as an option the deformation model because 1) they can approximate arbitrarily complex time functions, and 2) they are used in the LINZ deformation so required to implement that.
However when implementing into GGXF headers it raised (for me) a question of whether a simpler structure could suffice using ramp functions ...
Option 1: Implementation using a single function with multiple data points.
In a YAML style GGXF header this would look like:
timeFunction:
baseFunctions:
- type: piecewise
epochMultipliers:
- epoch: 2013-05-08T00:00:00Z
multiplier: 0.0
- epoch: 2013-05-08T00:00:00Z
multiplier: 0.9
- epoch: 2014-02-05T00:00:00Z
multiplier: 1.2
- epoch: 2015-01-01T00:00:00Z
multiplier: 1.4 Pro:
- intuitive and simple
- only one base function to evaluate
Con:
- adds a second level of nesting to yaml definition so more complex structure
- little used currently (only NZ model?) so added complexity may have little use
Option 2: Implement a simple "ramp function" base function and create the piecewise representation by adding multiple ramp functions.
A ramp function is a simple function with four parameters, startEpoch, startMultiplier, endEpoch, endMultplier
timeFunction:
baseFunctions:
- type: ramp # red function
startEpoch: 2013-05-08T00:00:00Z
startMultiplier: 0.0
endEpoch: 2013-05-08T00:00:00Z
endMultiplier: 0.9
- type: ramp # blue function
startEpoch: 2013-05-08T00:00:00Z
startMultiplier: 0.0
endEpoch: 2014-02-05T00:00:00Z
endMultiplier: 0.3
- type: ramp # green function
startEpoch: 2014-02-05T00:00:00Z
startMultiplier: 0.0
endEpoch: 2015-01-01T00:00:00Z
endMultiplier: 0.2Pro:
- simplifies the data structure by removing one level
Con:
- not intuitive
- less efficient to evaluate as multiple functions need to be evaluate
Recommendation
Although GGXF implementation should not drive functional model definition the simple ramp function is preferred (after much vacillation)
Meeting 2021-07-05
There was a slight preference for the simpler base function. However the name "ramp function" generally did not resonate (and subsequent investigation shows it is different from the conventional mathematical ramp function.
Conclusion
The functional model will include a function type called piecewise linear function and defined just by a start and end epoch and multiplier. (YAML example in the header updated to reflect this).
The
desruisseaux
The currently proposed time function is documented in the [functional model strawman](https://github.com/opengeospatial/CRS-Deformation-Models/blob/master/functional-model/strawman-cc/functional-model-strawman-cc.adoc#formula-time-function is a composite function calculated by adding one or more base components, each one of:
This provides can support the most likely functions that we expect to be used in deformation models, based on geophysical deformation models and GNSS reference station models. Both of these are generally based on trajectories of individual points. The piecewise function adds a capability to approximate model arbitrarily complex functions.
To progress GGXF in a way that supports Deformation Models we need to identify what is required in it to do that. The deformation model GGXF headers are mostly generic - little different to (for example) a datum transformation grid. However the time function is structurally relatively complex and so we want to offer GGXF a likely draft header.
An (unrealistic) example model to demonstrate each type is:
I would like to have a discussion to gain team consensus on the preferred model to finalize its description in GGXF.