[PROJ] Proposal for a geodetic deformation model format

[Chris Crook]

Kristian

> I am late to the party so let me just try to comment on a few things

I think the party has hardly started :-)

> COORDINATE SPACE(S)
>
> I originally wrote the deformation operation with the sole purpose of
> providing a practical implementation of the transformations described in the
> paper by Häkli et al [0]. This obviously influenced the implementation and
> there is the possibility that it isn't generic enough for all purposes, although I
> haven't yet come across a situation that wouldn't fit regarding the use 3D
> deformation models in coordinate transformations.
>
> The deformation operation in PROJ works in a mix of geocentric and
> geographic coordinates [1]. Actual adjustments are done in
> geocentric/cartesian space. This is analogous to e.g. a Helmert operation
> which also works in geocentric space. And as Even points out the
> deformation operation is often use in a pipeline in conjunction with one or
> more Helmert operations. I generally prefer to work in geocentric space
> when doing this sort of work since it is the "native" coordinate space of the
> frame and because it is nice to work within a linear coordinate systems with
> axes that intersects at right angles. Unfortunately it is not really possible to
> create a grid of surface displacements or velocities in geocentric space
> without creating a massive sparse 3D matrix which is not practical in any way.
> This is the reason why the deformation operation requires grids in
> topocentric/ENU space and internally converts between the two coordinate
> systems. It does come with a bit of overhead, especially in the inverse mode,
> but it isn't too bad compared to let's say a 14-parameter Helmert operation.

In NZ case we have generally different implementations of horizontal and vertical
deformation, so the ENU system is much more practical.  Also for the most part the
measurement systems and modelling approaches (not to mention tectonic behaviour)
can have quite different behaviours for horizontal and vertical (or indeed only provide
horizontal or vertical deformation).   So at the moment for LINZ the more pragmatic
approach is to work in ENU space for a while longer.  Or more briefly - gravity makes
a difference.

> Doing gridshift adjustments in degrees generally works quite well and it what
> has been done for years and years in PROJ. The main disadvantage, I think, is
> that it is difficult for the human eye to interpret values in the grid. I tend to
> find it quite useful to plot the grids I use in QGIS and having the values
> expressed in meters or millimeters gives me an immediate advantage.
> There's nothing in the way to support both types of gridshifts. I do think
> though that expressing velocities in terms of degrees is a bad idea (I don't
> think that was the intention, just putting it out there).

Thanks.  I also favour using metres rather than degrees.  Having human readable/easily
plottable grids is another plus.  Plus as in the proposal uncertainties in degrees are nonsensical
(especially as I am proposing a single circular horizontal uncertainty) and it feels very unclean
to use different units for displacement and its uncertainty.

> Regarding the iterative inverse deformation operation, it works but it isn't
> particularly good to be honest. I reworked the existing iterative algorithm
> used for horizontal grid shifts into a 3D version and I never quite got it right. It
> doesn't perform well in a round-trip test and after about ten trips back and
> forth it has introduced too much noise due to numerical inaccuracy in the
> algorithm. Improving this could be a fun challenge for  some one more
> mathematically inclined than me.

I wonder if it is easiest to do the inversion in the lat/lon space (even a simple
approximation of metre to degrees should get  a fairly accurate result).  While an
imperfect inverse is not ideal, it is nothing compared to the imperfections in the
deformation model in the first place.  Ultimately a trade off between perfect and
efficient.  Maybe this could be a user definable option somehow if it is a concern?

> I agree that it doesn't make much of a difference whether adjustments in
> the up components are done in relation to a gravimetric or geometric
> reference.

Nice to have a second opinion on this assertion :-)

> GRID DELIVERY METHOD (SINGLE VS. MULTI FILE)
>
> I agree with the proposal that the multi file solution is preferable. Especially if
> zipped up a in aggregate package. This was also touched upon in the original
> GitHub discussion 18 months ago. I think JSON would be preferable to a CSV
> based format since it offers a bit more structure and you would be able to
> define a proper JSON schema that can be used to validate the format of the
> file. PROJ has the ability to parse JSON already.

I'm sold!  I'll amend the document to propose JSON next week.   It is also much more
suitable for web services and so on.

I realised another benefit of the multiple file format is that it provides the possibility
of optimising conversions between different versions of a datum for which most of the
grids are the same.   I'll add that to the document also.

> A package of a number of grid files and a metadata file describing the use of
> the grids should be fairly simple to translate to a PROJ pipeline, provided that
> the usage of the grids align with operations available in PROJ. It would of
> course be much simpler if everything was just expressed as a PROJ pipeline
> but I guess we can't assume that everyone will be using PROJ :-)

I haven't raised the implementation approach in PROJ in this proposal (yet!).
I'm wondering if it would be better implemented as a +proj=(deformation is taken,
something like that) method, rather than breaking up into multiple steps in
in the pipeline as I think you are suggesting.

Reasons are:
1) Inversion should be of the deformation as a whole, not individual steps
2) The pipeline would be different for different epochs.   Generally I imagine that data
will be of a consistent epoch but I don't think that would necessarily be true
3) I suspect it would be slower to run

> RELEVANT USE CASE: GREENLAND
>   ...

Thanks for these  - very interesting.  Is it Ok if I include these in the document
(attributed to you).  I'm thinking I'll add an appendix summarising the discussion
with Even around the NZ usage, and it would be great to add these too.

Regards
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.