SNAP needs to support relative coordinate uncertainty in recode

[ccrook]

In order to derive a more realistic stochastic model of coordinates which reflect uncertainty in the deformation model it is proposed that the recode station option should be enhanced to support including a relative coordinate uncertainty.

With this approach stations in an area significantly affected by an earthquake would be recoded to create a pre-earthquake and post-earthquake code/coordinate for the mark. However the pre-earthquake coordinate will be related to the post-earthquake coordinate by a observation defining them to have be the same coordinate but with a nominated uncertainty (horizontal and vertical error).

This assumes that the deformation model is the best estimate of the the coordinate change at the point, so that its expected error is zero. However it has an uncertainty which applies in fitting pre- and post- earthquake data, and in the accuracy of coordinates for which only pre-earthquake data is available.

This approach ignores the likely spatial correlation of deformation model errors. This could be considered for a future enhancement, though it significantly increases the complexity and size of the adjustment.

The uncertainty will be defined by a set of recode commands which define an affected area and the uncertainty that applies. Where more than one recode applies to a mark (with the same recode suffix), the largest uncertainties (horizontal and vertical) will apply. Where a mark also has a recode command with no uncertainties specified the mark is assumed to be disturbed and no relationship between pre- and post- earthquake coordinates is assumed.

snapspec may also require a small enhancement to make it easy to ignore the pre-earthquake recoded coordinates.

[ccrook]

@ndonnelly @mermy This is the proposed approach for dealing with the deformation model uncertainty. This requires a bit of work on snap - so will likely delay the calculation slightly :-( But will give a much better result. This is discussed a bit in the nga wiki https://github.com/linz/national-geodetic-adjustment/wiki/2018-Kaikoura-refinement-grid (bottom of the page). Thoughts welcome!

[ccrook]

In order to properly support multiple future recoding of a mark the rules for defining relative errors of marks becomes relatively complex!

Firstly - as noted above, where recoding is defined for the same suffix then the maximum uncertainty is used as noted above.

Where multiple recodings apply to a mark then a time history is constructed from the recodings, at each step of which an uncertainty may apply. An offset uncertainty is applied for each step (ie to relate the coordinates before and after each step). If the coordinate at any step can be calculated then the coordinates for all steps will be calculated (as they will all be calculatable).

To simplify this process only recoding which specifies a before or after date will use this logic. Where before or after dates conflict (eg recode xx before 2017-06-01 ... recode xxx after 2016-07-01) a warning will be raised and the dates adjusted to build a rational list. This may result in some steps being removed.

Recoding between dates or without dates will not allow uncertainties.
Recode lists for individual data files will not allow uncertainties.
Station recode files will not allow uncertainties (at least in the initial implmentation)

[ccrook]

Outstanding issues in station recoding:

• need check/warning where one recoding invalidates another
• for warnings and listings need to track where station recoding is defined (file id, line no)
• comparing dates is comparing floating point. Should have some tolerance built in to avoid
  rounding differences in update_stn_recode.
• need to sort out order of recoding to ensure correct dates are picked
• add station recoding relies on linear traverse of existing recodings. Could be too slow if number of stations grows.
• current implementation adds recoded stations to adjustments even if not observed. More efficient to handle covariance separately - adding to that of observed station when required.
• current implementation does not allow recoded station to be floated
• need to handle impact of co-location constraint on station autofix.