Review deformation model functional model feature matrix

[ccrook]

Following the 12 April 2021 meeting I have uploaded the deformation model feature analysis spreadsheet to Google Drive document at the link below.

https://drive.google.com/file/d/1HgSZOjFc4yQYTQNOmfWXbBZwK0Wbjbhu/view?usp=sharing

In the meeting it became clear that word "mandatory" is very dependent on point of view. I was thinking of capability of the functional model but we found at least three views on mandatory:

• capability: the functional model can support defining the feature. For example we might say that it is mandatory that the functional model supports a gridded format spatial model, but only desirable that it supports triangulated format models. This ranking supports writing the standard/specification
• model compliance: a compliant data set (ie actual deformation model) must include this information. For example we might say it is mandatory that it includes a source CRS but only desirable that it includes discovery metadata
• software compliance: a compliant software using the model must support this feature. For example we might say that it is mandatory that a software evaluates displacement and desirable that it evaluates uncertainty.

My initial view on this feature matrix is aligned with the first of these, that is it is specifying which features are mandatory for inclusion in the first version of the standard/specification, which are desirable, optional, or even undesirable. For example a feature would be undesirable (IMO) if it isn't required by any existing or proposed deformation models and if its inclusion would discourage potential software implementors.

The link above should allow adding comments directly. If you want to edit the content directly you can download it from this link send an amended copy to me (ccrook@linz.govt.nz) or upload it as an attachment to a new comment this issue.

Thanks for taking the time to look at this.

[ccrook]

@kevinmkelly wrote: deformation-model-feature-matrix-KMK.zip I have made extensive comments/changes to the DMFM feature matrix (attached). Most notably, I have changed the playing field so-to-speak by altering the definitions of the rankings; this made it more straightforward (for me) to populate the matrix. These definitions are included as comments to the rank headings and are repeated below for reference:

• Capability – DMFM must be capable of encoding these features.
• Required – Mandatory for any compliant DMFM encoding. This means that the DMFM cannot be implemented if these ‘required’ features are missing.
• Implementation – Implementations (i.e. software) must be capable of decoding (i.e. recognizing in code) the feature. Note this rank mimics the Capability rank, so may be redundant. Desirable – Neither mandatory nor required for a valid/compliant DMFM. A 'Y' against any feature here means that the DWG/SWG should decide whether to include it in Version 1 of the DMFM or designate it as a future enhancement.
• Optional – Not required for a valid/compliant DMFM, but can be included at the producers discretion. Implementations must be capable of decoding (i.e. recognizing in code) the optional feature.
• Redundant – The feature is not needed since it can be derived from or is already defined by another feature.

All my additions, changes and comments are in light blue text in the spreadsheet. No doubt, I’ve created some inconsistencies, even outright mistakes, but hopefully the modifications make sense, or at least raise issues for further discussion.

[ccrook]

Thinking more about the Capability/Required/Implementation issues I think this has got too complicated.

For this exercise I think it may be simpler to focus on capability, ie what features does the specification need to include to support current and future deformation models.

When we look at implementation then a fully compliant software will support all of the features defined for the standard. However the extent to which it supports it will maybe depend on the application. For example a coordinate transformation software that doesn't report uncertainty might be defined as compliant if it supports all the capabilities for calculating and applying coordinate transformations, but ignores everything relating to uncertainty.

So what is required to be supported by an implementation is defined once the standard is defined. Until then we are mainly concerned with capability. The only reason to consider implementation is to check that we don't define unnecessary capabilities (or very limited use capabilities) that would discourage uptake by implementors.

Both of these are very different to what items of data are required in a compliant DMFM. When we write the standard we can define this, but logically what is mandatory will be defined by what is actually required to evaluate a model. In addition to this we may choose to make some discovery metadata mandatory.

In short, I think we should perhaps remove Required and Implementation from this feature matrix, and clarify that this is a feature matrix for features/capabilities that the proposed standard might or might not support. Once the standard is "feature complete" we can consider what software compliance and data set requirements look like.

Does that sound a clearer approach?

[ccrook]

@kevinmkelly wrote: I agree. We really only need two categories:

• Capability – DMFM must be capable of encoding these features.
• Desirable – Neither mandatory nor required for a valid/compliant DMFM. A 'Y' against any feature here means that the DWG/SWG should decide whether to include it in Version 1 of the DMFM or designate it as a future enhancement.

As I mentioned, my Implementation category was identical to the Capability category. This confirms your ideas that a compliant implementation of a DMFM is one that can decode/parse all the Capability features and calculate correct parameters and displacements.

[ccrook]

@kevinmkelly I think that is still confusing the issue, but that may just be a cut and paste issue in the definition of desirable. So I think we are writing a feature matrix for the specification itself. So as I see it are the options are more like:

• Mandatory: The DMFM standard/specification must support this feature. It will not achieve its purpose if it does not.
• Desirable: The DMFM standard/specification will be achieve its purpose better if it includes this feature
• Possible: This has been identified as a potential feature but adding it to the specification does not help the standard achieve its purpose
• Undesirable: This has been identified as a potential feature but we believe including it will detract from the value/quality of the standard and negatively impact its potential use

The latter two categories mainly serve to record our decision to not include potential features.

These definitions (and indeed the whole exercise) are based "achieving the purpose of the specification/standard".

I think that this is to allow producer agencies to encode deformation models in a common format that software suppliers can implement.

So the success criteria is something like "(within the domain of coordinate operations) the specification can be used to encode all actual or proposed deformation models, and is simple and clear enough to encourage uptake by software developers and other users."

[kevinmkelly]

@ccrook - I question the need for categories: Desirable and Possible as you have defined them.

Desirable: The DMFM standard/specification will be achieve its purpose better if it includes this feature

If the feature will enhance the DMFM, make it operate more efficiently or effectively, then it should be Mandatory. Why publish an inferior standard when it could be "better"? Perhaps another way to view this is as a set of Minimum standards and Extended or Enhanced Standards?'

Possible: This has been identified as a potential feature but adding it to the specification does not help the standard achieve its purpose

Then why add it? It merely overloads the standard to no avail!

There should clearly be a category for potential enhancements to the standard. These would be features that extend the standard so as to include a wider scope of deformation modeling. However, a "Version 1" of the standard is all that is needed at present for it to fulfil its purpose.

[ccrook]

@kevinmkelly Note this is the feature matrix for what we choose to put in the standard. It is not actually what we put in it. This is to guide us in writing the standard.

The main reason I see for distinguishing mandatory and desirable is if some features could make the standard more efficient for producers or users, but might discourage uptake by software developers. A potential example would be Okada fault model formulae which would support HTDP (though personally I would probably rank that as possible). In practice there probably isn't much in this category.

As noted "Possible" is really there mainly to record a decision to not include a feature. It is something that is not in the standard so it won't overload it. But hopefully including it in the feature matrix will reduce re-litigation for decisions that might otherwise be buried deep in github.

When we construct the standard itself we will doubtless include another feature matrix like thing (or a couple). For example which attributes/components are mandatory vs optional in a compliant data set, what features are mandatory for a compliant software (or possibly for a number of specific levels of compliance)

[ccrook]

I have updated the feature matrix at the link in the beginning of this issue with Kevin's simpler version, which also includes amendments from the 10 May meeting. (https://drive.google.com/file/d/1HgSZOjFc4yQYTQNOmfWXbBZwK0Wbjbhu/view?usp=sharing). This is also in this github repository at https://github.com/opengeospatial/CRS-Deformation-Models/blob/master/feature-matrix/deformation-model-feature-matrix.xlsx

[ccrook]

At the December 2021 meeting it was decided that the feature matrix does not need further attention - it has served its purpose.