Re: Proposal for a geodetic deformation model format

Chris,

> I hadn't realised PROJ would be working in a geocentric space.

I just pointed at the particular working of the +proj=deformation 
transformation. Other transformations such as the +proj=hgridshift operate in 
the geographic coordinate space directly.

> What I was thinking when I suggested degrees would be more efficient was
> that had converted coordinates to geographic lon/lat/ellipsoidal height (as
> you need lat/lon to interpolate), then applying a correction to the lon/lat
> coordiantes in metres requires (a little) more calculation than applying
> corrections in degrees.   This could make more difference for an inverse
> calculation, as if you are iterating you could end up converting multiple
> times between geocentric and geographic (and geocentric to geographic is
> itself iterative).
> 
> However if we are applying the correction to geocentric coordinates then
> this doesn't apply.

That's probably mostly a matter of taste to decide if the input/output of an 
operator is geographic or geocentric coordinates. Actually, this is also 
related on how that operator relates to others you might want to chain with 
it. Looking at the examples of
https://proj.org/operations/transformations/deformation.html , the 
proj=deformation operation is surrounded by 2 proj=helmert, which do operate 
in the geocentric coordinate space, so that makes a lot of sense to have 
proj=deformation also operate on it (even if as an implementation detail it 
needs to do an internal geocentric->geographic conversion to retrieve grid 
values)
(I'm guessing in Kristian's mind. Hopefully correctly !)

> No - I've tried to make this clearer in the document.  The proposal is to
> use the same approach as eg NTv2.   A single component (eg deformation due
> to an earthquake) may be defined by multiple grids.  At any location only
> one of those grids will apply.
> 
> However the deformation model as a whole has multiple components (eg
> secular velocity, earthquake 1, earthquake 2, ...) and these are evaluated
> separately and summed together.

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 ?

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

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

Right ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj