Re: Proposal for a geodetic deformation model format

Chris,

A well-thought and thorough proposal !

A few questions/observations:

- regarding "The horizontal displacement is represented by metres east and 
north. Typically base datum will be a geographic coordinate system using 
latitude and longitude and it would be more efficient to define displacement 
in terms of degrees.".
Is it the same convention as PROJ deformation method
(https://proj.org/operations/transformations/deformation.html) which uses 
grids to store corrections in the ENU space as far as I understand ? 

(more a question for Kristian: I presume this ENU space is the same as the UVW 
topocentric coordinate system described in 4.1.2 "Geocentric/topocentric 
conversions" of 
https://www.iogp.org/wp-content/uploads/2019/09/373-07-02.pdf ?)

For the easting, northing I presume yes. But I'm not sure if the convention 
you mention for vertical correction "The vertical direction will be the local 
vertical of the coordinate system." corresponds to the U of ENU. Or perhaps 
this falls in your remark "For deformation
there is no practical need to distinguish gravitational and geometric 
vertical" ?
That said, PROJ deformation method is a bit different in that it is meant to 
perate with input and output coordinates in geocentric space: it uses 
internally a geocentric to geodetic conversion to be able to retrieve the 
correction values from the grid(s), and then convert those corrections from 
the ENU space to the geocentric space.

- regarding "Strictly the inverse calculation of the deformation model is an 
iterative calculation, as the location of a point in the interpolation 
coordinate system is not known until it is transformed back to that system."
I just want to mention that PROJ uses an iterative method for the inverse of 
horizontal shift grids (NTv2 etc), so wouldn't be a problem to use that for 
deformation models as well. Actually PROJ deformation method also uses that 
iterative method.

- regarding nesting of grids, is my understanding correct that if you have a 
grid G, that has subgrids G_1 et G_2, and that a point falls in G and G_1, 
then the corections of both G and G_1 should be applied ? Just wanted to 
underline this, as it is different of the NTv2 model where you apply one or 
the other (preferably G_1), but not both.

- it could help for a better understanding to have a small example of a CSV 
file illustrating the different concepts you expose. Nested grids, different 
time functions etc.

- The approach master CSV file + separate grids in dedicated files has its 
merits indeed. The actual grid format, GTiff, HDF5 or whatever raw binary 
format that can support multiple samples per grid node will make little 
difference because the specificities/complexities of the description of the 
deformation model is in the CSV file itself.

- So if a earthquake happens, basically you'll create a new grid in the area 
that is affected, and create a new version of the CSV file where you add an 
extra row that references it, right ? (I'm probably over-simplifying)

- Any indication of the number of grids a deformation model might have ? For 
the NZ case for example

- Just a detail: regarding "velocity f(t) = (t – t0)/(365.2425 days)", if time 
and volicities are expressed respectively in decimal year and 
some_linear_unit/decimal_year, that should probably be just f(t) = t-t0

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

Even

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