Observation epoch vs reference frame epoch: Explicitly distinguish?

[jhaasdyk-au]

The purpose of this github discussion is to:

• record findings, feedback and questions to inform planned discussions with icsm-au/DynAdjust subject matter experts
  i.e. to inform additional user(self)-education, or potential enhancements or defects.

All findings and recommendations are my own and may not correctly represent current or planned DynAdjust behaviour.

---

Should DynAdjust explicitly distinguish observation epoch from reference frame epoch?
(e.g. to support discontinuous stations)
[All document references below are to the DynAdjust Users Manual (Sept 2022) unless otherwise noted]

(Issue raised by Kent Wheeler (Landgate WA) in email 07/09/2022)

---

refran.exe overwrites a measurement's epoch attribute to reflect the output reference frame epoch.
i.e. DynAdjust (v1.2.?) regards the attribute epoch to mean reference frame epoch.
For example:

• ReferenceFrame: ITRF1991 =>GDA2020
• Epoch: 15.09.1992 =>01.01.2020

Therefore to analyse discontinuous stations there are two options:

1. Rename stations BEFORE running refran
   e.g. using import.exe --discontinuity-file option (e.g. Section 3.3.2 Data screening > Station discontinuities) [No change to coding]
2. Enhance DynAdjust executables to maintain both an (optional) observation epoch and the reference frame epoch.

Discuss!

---

BACKGROUND

• In DynAdjust STN and MSR files, the header line supports a (non-mandatory) epoch attribute.

  • Section B.1.2 “The epoch field relates to the reference frame”
  • It is clear that the intended use of epoch throughout the document and schema is as the ‘reference frame epoch’ (and not strictly as the epoch of observation).
  • Section B.1.4 (Measurement information) describes the same attribute epoch for all measurement types.
    • See separate discussion (#196) regarding some epoch and reference frame idiosyncrasies w.r.t. STN and MSR files.

• Interestingly Section B.3.2 (DynaML schema) allows for more than one occurrence of epoch (minOccurs = “0”)

  • I’m not sure how DynAdjust would interpret multiple epoch tags... (testing anyone?)
  • However there is no mechanism to distinguish an ‘observation epoch’ from a ‘reference frame epoch’

• GeodesyML (GeoscienceAustralia/GeodesyML (github.com) on the other hand distinguishes between ‘observedEpoch’(s) and ‘realizationEpoch’/’referenceEpoch’

[jhaasdyk-au]

IMO, the full description of a measurement (and station!) should require the following.
(The original measurement (or station) should always be reproducible from derived information)

• Station(s)
• Reference frame
• Reference frame epoch
• Observation Epoch [not yet in DynAdjust]
• Measurement value
• Measurement uncertainty
• Source
• Lineage (highly desirable) [not yet in DynAdjust]

HOWEVER, its not likely to hit the top of the ToDo list based on current National Adjustment UseCases given - we always have the raw data on hand - DynAjdust can already support station discontinuities, if applied BEFORE refrran.

There may be other relevant UseCases (especially where the raw data is no longer available) AND adding the above would satisfy (and exemplify) best practice imo (and per AZNLIC Metadata WG). Can we get funding ;-) ?

[jhaasdyk-au]

Consider, Is this command (fully) valid?
reftran skye -r GDA94 -e 12.06.2035
If not, why not?

• I think not. The epoch listed above is meaningless as a reference frame epoch, and as a (modified) observation epoch.
• Reftran applies no plate model to a static reference frame such as GDA94.

Consider however that we are happy to import data where 'epoch' implicitly means 'observation epoch'.
If you import to a dynamic datum, that becomes observation epoch' = reference frame epoch (per Section 3.3.1)
if you import to a static datum, then what really happens to epoch through import / reftran / adjust has become a little bit murky to me (per this discussion which lists some discrepancies in reporting of epoch [link to come])