[PROJ] FW: Proposal for a geodetic deformation model format

Fri Dec 6 10:36:10 PST 2019

Even

> OK, so a line in your CSV file can be a file with potentially nested
> grids and when using that line, you use the "best" grid.
> But you may find another grid in another line of the CSV file for the
> point considered, and you'll also apply it (depending on time criteria) Am I correct ?

Yes that is it.  With the multiple file implementation each component line in the master CSV file (renamed from metadata file in the document an hour or so ago) would correspond to a GeoTIFF file.

When evaluating the deformation model at a given location and time the algorithm scans CSV file to find components for which the extents included the evaluation point and the time function evaluated to a non-zero value.

For each of these it searches the corresponding GeoTIFF to find the preferred grid for the evaluation point (as I understand the RFC4 that would be the last grid in the IFD containing the point) and uses that to interpolate the deformation parameters de,dn,du at the location.

The interpolated values would be multiplied by the time function and added together to obtain the total de,dn,du displacment.

> > > - I'm still having issues to grasp the practical implications of
> > > the "reverse step". Is my understanding correct that a coordinate
> > > computed for example for
> > > NZGD2000 @ 2010.0 with a deformation model of 2019 might
> > > potentially change with a deformation model of 2020 ? Should the
> > > deformation model used be also captured in the metadata associated
> > > with a coordinate? If so, it looks like a change in the
> > > deformation model would be better handled by defining a revised
> > > version of the datum (but I know you don't want to publish a new
> > > NZGD datum every 6 month). I'm super confused... I'm pretty sure
> > > we
>
> Looking quickly at
> https://www.linz.govt.nz/data/geodetic-system/datums-projections-and-
> heights/
> geodetic-datums/new-zealand-geodetic-datum-2000-nzgd2000/nzgd2000-
> deformation-
> model
> and
> https://github.com/linz/nzgd2000-deformation-model , I now realize
> that the deformation model is for transformaing between a ITRF
> realization and NZGD2000. So the @ epoch qualifier applies to the ITRF
> realization, and in principle not to NZGD2000 which, for the sake of
> its use in ISO-19111 based modelizations (PROJ for example), is a non-dynamic datum.
> Am I correct ?

Pretty much.  The nomenclature of "dynamic" and "static" is to my mind
very unhelpful.   NZGD2000 is based on a dynamic datum - it is realised by
GNSS based ITRF coordinates at CORS reference stations.  But it is modified
by the deformation model to emulate a static datum.   Much of the original
documentation refers to it as a semi-dynamic datum, but I'm not sure that helps!

I'm not sure about using @epoch.  I did start using that myself in the LINZ coordinate conversion software a long time ago but I found it created more
confusion than clarity (for me!)   It associates the epoch with the datum rather than the
coordinate/data set, which I find misleading.

The ITRF coordinate in 2010 refers  to a location measured at that time, as does the NZGD2000 coordinate in 2010.  The same coordinates (ie numerically) in 2019 refer to different locations.  The NZGD2000 tends to track deformation so will more or less refer to the same physical point on the ground as it did in 2010.  The ITRF coordinate will refer to a different physical point on the ground.

So as far as a "fixed feature" (something intuitively fixed such as a building) the
NZGD2000 coordinate does not need an epoch.  Nonetheless I would still want to keep it as important metadata.

The ITRF coordinate still correctly defines where the object was in 2010.  If you want to know where it is in 2019 then you can use the deformation model as a point motion model to predict where it should be.

This applies in an area where we haven't applied an earthquake "patch" (or more strictly a "reverse path").

Where we have applied a patch the situation is different.
In those areas we essentially have given up tracking the ground movement with
NZGD2000 as the distortion is untenable for something purporting to be a geodetic datum.  By that I mean that most users do not/cannot use the deformation model, but still expect to be able to use the NZGD2000 coordinates to do calculations as if they were geodetic coordinates, and
calculate distances etc from them.   If they want to do very accurate calculations
they will need to transform back to ITRF.  But at a lower accuracy most users
do not do this.   To manage the expectation of using the NZGD2000 coordinates
as if they are geodetic coordinates we limit the distortion in them.

Where the ground deformation creates a distortion of more than say
10 part per million we apply a "reverse patch", which in the affected area amounts
to a new local datum and updates the NZGD2000 coordinates.   The deformation model
is still tracking the movement of the featuers, but the NZGD2000 coordinate does not.

In this case the new deformation model includes the earthquake deformation, but it applies to coordinates before the earthquake.  So in an area affected by a patch if you take the ITRF 2010 coordinate and apply the patched deformation model to it (at epoch 2010) to calculate the NZGD2000 coordinate you will get a different value to what you would have obtained using the previous version of the deformation model.  It will still refer to the same physical feature, but the NZGD2000 coordinates will be numerically different.

Still closer to the epicentre there is a region where the deformation is too complex to model in the deformation model at all (at least in any useful way), so while the deformation model will still calculate an NGD2000 coordinate from the ITRF epoch 2010
coordinate, it will no longer refer to the same physical feature.

So essentially there are three situations for users when we update the deformation model with a new reverse patch, depending  on where they are located.

1) Far from the earthquake where the deformation model has absorbed the movement and NZGD2000 coordinates are not updated.
* NZGD2000 coordinates from pre-earthquake data still refer to the same physical location
* ITRF coordinates at any epoch can still be converted using the updated deformation model to get NZGD2000 coordinates (which will be no different the those calculated from the previous model)

2) Close to the earthquake where we have applied a reverse patch, updating both the coordinates and the deformation model.
* NZGD2000 coordinates from before the earthquake need to be updated using a reverse patch model to refer to the same physical feature (ie a new datum locally)
* ITRF coordinates at any epoch can still be converted to the new NZGD2000 coordinates using the deformation model.  This will give different NZGD2000 coordinates to those calculated with the old deformation model).

3) Very close to the earthquake where the deformation is too complex to include in the deformation model.
* NZGD2000 coordinates no longer refer to the same feature even after applying the patch
* ITRF coordinates can be converted to NZGD2000 as in case 2 but will also not refer to the same physical feature.

Depending on the nature of the event then not all the regions will apply.  For example an offshore earthquake may be completely handled by the deformation model, so only 1 will apply.  A deep earthquake may not cause significant surface distortion, so only 1 and 2 may apply.

Apart from earthquake there is also the 5cm per year secular deformation which in NZ is continuously distorting the country.  This is handle is the same as case 1 above - the NZGD2000 coordinates of features do not change.

Note that this description really only applies to horizontal coordinates. Vertical deformation is handled differently.  For horizontal deformation it is useful to "hide" the deformation from the users.  The usage of heights is very different - the relationship to gravity, direction of flow etc means that we want heights to reflect their true current value as far as possible. In the terminology above height movements are always treated as case 2 - reverse patch where coordinates are updated with known vertical movements.

Also our vertical deformation model is much less complete.  We have models for some of the earthquakes but no secular models.  Plus heights are much more subject to smaller scale regional and temporal changes, eg due to mining, groundwater changes, etc.

> > > had that discussion already, but I've forgotten the outcome. I'd
> > > be very interested in having a concrete example of a workflow of
> > > how users are supposed to use such deformation models, and which
> > > metadata they are supposed to store to be able to later reprocess
> > > their
> coordinates.
>
> Let me try to come with an hypothetical workflow of a user "playing"
> with coordinates.
> Let's imagine they captured coordinates in an area that is going to be
> later affected by a earthquake. They get their input coordinates in
> ITRF96 @ 2018.0 .
>
> Because they need to mix this data in a dataset referenced to
> NZGD2000, they use the following transformation:
> ITRF96 @ 2018.0  --> NZGD2000  using deformation model 20171201.
>
> Now an earthquake happens at 2018.1 and the 20180701 deformation model
> is released to take it into account. They have 2 options to get the
> updated
> NZGD2000 coordinates:
> - either they kept their initial coordinates in ITRF96 @ 2018.0 and
> use the new deformation model to transform them to the updated
> NZGD2000
> - or they didn't... In that case they must remember they used model
> 20171201, to convert back to ITRF96 @ 2018.0 and apply model 20180701.
> So this means storing alongside to the NZGD2000 coordinates: the
> initial ITRF realization + the coordinate epoch + the deformation model used.
> (- or they might also just apply the patch correction if they are
> clever enough and use the appropriate tooling )

Hopefully above answers this a bit.

Cheers
Chris

________________________________

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.