Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle epoch for terrestrial measurements #173

Closed
rogerfraser opened this issue Jan 29, 2022 · 1 comment
Closed

Handle epoch for terrestrial measurements #173

rogerfraser opened this issue Jan 29, 2022 · 1 comment
Labels
feature improve Improve or enhance an existing feature priority 1 (high) Issues which will receive the earliest attention

Comments

@rogerfraser
Copy link
Member

Brief description
A new feature to handle epoch for terrestrial measurements is required.

Related issue(s)
This request relates to issue #170. In particular, when a discontinuity file is loaded, terrestrial measurements containing discontinuity sites are not updated to reflect legitimate discontinuity. This is because epoch is not handled for terrestrial measurements.

Background
The original/default behaviour of DynAdjust for terrestrial measurements does not include any capability to handle epoch. Given the ability for DynAdjust to handle discontinuities, it is now important to be able to update terrestrial measurements connected to stations affected by ground movement.

Basic requirements
Add full functionality to handle epoch for terrestrial measurements.

See the example data files in #170 provided by @nicgowans.

Next steps

  • Add methods for GetEpoch and SetEpoch to the relevant measurement files in measurement_types.
  • Add functionality to SetMeasurementRec, WriteDynaMLMsr and WriteDNAMsr to the relevant measurement files in measurement_types.
  • Update DNA MSR file format to include epoch for terrestrial measurements (columns 123-142, 20 chars wide, format ’dd.mm.yyyy’)

Priority
High priority.

@rogerfraser rogerfraser added feature improve Improve or enhance an existing feature priority 1 (high) Issues which will receive the earliest attention labels Jan 29, 2022
@rogerfraser
Copy link
Member Author

Addressed by #174.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature improve Improve or enhance an existing feature priority 1 (high) Issues which will receive the earliest attention
Projects
None yet
Development

No branches or pull requests

1 participant