[PROJ] Proposal for a geodetic deformation model format

[Chris Crook]

Hi Kristian

> > 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.
>
> That is a possibility, yes. From a PROJ stand-point I could see this becoming
> some sort of meta-operation that internally would expand to a pipeline.
> Other applications would probably implement it differently.

That sounds an ideal approach to me.  Definitely I would want a +defmodel=xxxx
command line option to allow testing, otherwise I have no way confidently building
the JSON master file.   But internally the using a pipeline sounds great as it
it is does possibly provide options for optimising conversion between different
versions of the deformation model etc.

> > Reasons are:
> > 1) Inversion should be of the deformation as a whole, not individual
> > steps
>
> We can deal with inversion of a pipeline. This is already being done in some
> complicated situations. As long as the description of how to combine the
> various grids in a transformation is good we should be able to construct a
> pipeline that goes both ways.

In retrospect I'm not sure that it needs to be for the deformation model
as a whole in any case.  I'm realising there are mathematical issues whichever
way it is done.  I'm going to document this in the proposal in more detail.

> > 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
>
> We should be able to deal with that in a pipeline, provided that info on the
> epochs is available in the metadata. As I mentioned in a previous email we
> still need a bit of work regarding time-depending transformations. This would
> be a nice opportunity to change that.

Yes - so long as the pipeline supports a piecewise linear  scale factor function
of time then it can be included.  The implementation will presumably evaluate
the time function and then ignore the corresponding grid if it evaluations to
zero.

> > 3) I suspect it would be slower to run
>
> Marginally, yes. When Thomas implemented the pipeline operator he and I
> did a bunch Of performance tests and generally the pipeline operator itself is
> quite efficient. As a general rule of thumb premature optimization should be
> avoided - using existing operations in PROJ should make the initial
> implementation a lot smoother.

I think you are right - it probably wouldn't make a lot of difference.

On premature optimisation, it should be avoided if it adds unnecessary complexity
 to the code.  That doesn't mean we should ignore performance in implementing algorithms though!

>
> > 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.
>
> Yes, of course.

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