search

opengeospatial / CRS-Deformation-Models

CRS Domain Working Group Deformation Models project
7 stars 6 forks source link

Time function representation in GGXF #37

Closed ccrook closed 3 years ago

ccrook commented 3 years ago

During the 24 May 2021 GGXF meeting the question was raised about how to represent a deformation model time function in the specification. The time function is part of the "group metadata" in the GGXF terminology, where a group is the set of (typically nested) grids representing a deformation model component.

In the GGXF specification metadata are represented as key/pair values. Keys are not necessarily unique, for example the metadata could include:

parameterCount: 2
parameterName: displacementEast
parameterName: displacementNorth

Structurally this is an a list (or array) with a defined order of parameter elements. So the metadata structure is in effect a two level structure comprising an dictionary of key/value pairs where the values may be lists.

The metadata values are arbitrary strings, so they can encode much more complex structures. For example some metadata values include WKT definition of the interpolation coordinate reference system, eg

GEOGCRS["ITRF2005",  
DYNAMIC[FRAMEEPOCH[2000.0]], 
DATUM["International Terrestrial Reference Frame 2005", 
ELLIPSOID["GRS 1980",6378137,298.2572221,LENGTHUNIT["metre",1]]], 
CS[ellipsoidal,2], 
AXIS["Geodetic latitude (Lat)",north], 
AXIS["Geodetic longitude (Lon)",east], 
ANGLEUNIT["degree",0.0174532925199433]]

The question raised is "how should the time function be encoded". Below is a fictitious exmple (in YAML format for compactness) that illustrates the level of complexity that this may require - this is a composite time function (ie a list) which includes a piecewise linear time function, which itself contains a list). These functions are taken from the NZGD2000 model (though they are not a composite function in that model).

time_function:
- type: velocity
  reference_epoch: '2000-01-01T00:00:00Z'
- type: piecewise
  after_last: zero
  before_first: constant
  model:
  - epoch: '2009-07-15T00:00:00Z'
    scale_factor: -1.34
  - epoch: '2009-07-15T00:00:00Z'
    scale_factor: -0.29
  - epoch: '2011-09-01T00:00:00Z'
    scale_factor: 0
- type: reverse_step
  step_epoch: '2010-09-04T00:00:00Z'
ccrook commented 3 years ago

Meeting notes: 2021-06-07

KK: This could be encoded by ordered key pair values such that each key defined what the reader should expect next. ie time function count, then sets of key/pair values for each actual time function, where the first key of the set defines the type of function and therefore what keys follow.

timefunctioncount: 3 timefunction: velocity reference_epoch: .... timefunction: piecewise referencepointcount: 4 epoch value epoch value

MD: Could use UML. Focus on high level specification, not details of carrier.

Final conclusion is that for GGXF it will be useful to have clarity of what is to be encoded in some structured form, essentially a schema. UML may be a suitable way of doing this...

ccrook commented 3 years ago

The discussion on structured data in GGXF header is continued in https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/issues/10

Also a discussion on the time function model is now in https://github.com/opengeospatial/CRS-Deformation-Models/issues/38

This issue is therefore closed