Re: Proposal for a geodetic deformation model format

Hi Kristian

I'm putting together the details of of the calculation formulae and implementation
approach for proj into the deformation format proposal, and I find I am revisiting
a couple of issues we have discussed previously,

* adapting the existing deformation code using geocentric coordinates
* using (possibly internally constructed) proj pipline for each component.

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

I was unsure that it made sense to use the current method of applying deformation
in a geocentric space.  This requires converting from geographic coordinates to
geocentric to apply the deformation (as well as converting the east north up
deformation to geocentric), and then converting back again to get the geographic
coordinates to use in the next step of the pipeline. The conversion back is
an iterative calculation, so this is potentially quite a lot of extra work at each
point.  In my deformation code I've used a simpler approach based on as
local conversion from metres to degrees at each point and use to scale the east/north
changes.

I haven't been able to access the paper you referenced for using the
geocentric method.  I'm guessing the main reason for the geocentric coordinates
is that at high latitudes the approximate approach I am using breaks down, so using geocentric
coordinates avoids dealing with this special case.

However this bears on the use of the pipeline.  If we convert the deformation model
into a pipeline with a separate step for each component, then this overhead
is incurred for each component of the model

In the LINZ deformation model there are 24 components.  Not all will apply at
every time and location, but potentially many could, so this overhead would
become very significant.

There is another potential issue with the pipeline approach, which is that most
of the components only cover a subset of the area covered by the deformation
model.  If we are converting points in the north of NZ then only a couple of grids
will include those points.  So we would have to add some extra logic to the pipeline
to skip a step if the calculation point is outside the defined area,   Otherwise the
pipeline would need to load the grid, only to discover that it didn't include the
calculation point (and so the deformation from the component is zero). To me it feels
like this is subverting a coordinate transformation pipeline to becoming a code language.

These two factors lead me to think that it makes more sense process the deformation
model as an "elemental operation" which takes the input geographic coordinate,
determines the total east, north, and up displacement at that  point, and then
applies that using the conversion to and from geocentric coordinates.

You mentioned conversion of that algorithm from 2d to 3d, but I don't think that
is necessary - the vertical change can just get added to the height.  Doing that in
geocentric coordinates has no value (and probably isn't the theorerically correct
thing to do in any case)

How does that sound to you?

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 [email protected]) 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.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj