[Proj] Realigning velocity grid values by Helmert shift - is that normal?

[Kristian Evers]

Hi Even, good questions. Might not be" geodesy business" but still helpful.



> What is the typical format into which you can store those gridded velocities: one of the existing supported grid formats ?

The grid that I have access to now is in a custom format used in the old Danish transformation library TrLib. It is a 3D-grid, but I would convert that to a 2D-grid in NTv2 format for the horizontal parts and a 1D-grid for the vertical part (gtx-format). So yes, formats already supported by PROJ.4.

The bigger issue here is using the existing code for something else that simple coordinate offsets. If I remember correctly it is a bit complicated reading a single grid cell value with current setup. A bit of refactoring is probably warranted.


> So the parameters of this Helmert Transform are always the same for a given grid ? Or per year and/or country ? (this is probably explained in the paper...) If there's just one set of parameter for the grid, this would perhaps make sense to have a pre-processing script to correct the velocity grid.

Yes, always the same parameters. You multiply the grid cells by the timespan from the grid epoch to the desired epoch. That is why it is possible to create a derived grid. It is the solution I prefer, but it does have the slight problem of not being the official transformation. I don't mind that per se, but I do think it is best to implement transformations as close as possible to the original definition.


> Performed when *loading* the grid (ie correcting all values of the grid), or rather performed when selecting the particular velocity of the grid that applies to the coordinate being transformed ? The former could have performance implications if the grid is big and you need to transform only a couple of coordinates.

Implementation detail :-) Your latter proposal would be the way to go.


> Option 3 sounds like a complication in the general framework. Would probably require some parenthesing syntax.

Yes. It is not a path I want to go down, unless absolutely forced to. But it *could* solve the problem.

Kristian

Fra: Even Rouault [mailto:even.rouault at spatialys.com]
Sendt: 14. september 2017 21:11
Til: proj at lists.maptools.org
Cc: Kristian Evers <kreve at sdfe.dk>
Emne: Re: [Proj] Realigning velocity grid values by Helmert shift - is that normal?


Hi Kristian,



I have rather questions than feedback than geodesy business feedback ;-)



> In anticipation of a new velocity model being released soon,

> the original model is instead used by applying a Helmert shift to the

> gridded velocities.



What is the typical format into which you can store those gridded velocities: one of the existing supported grid formats ?



> The simplest

> solution is to just create a new gridded model where the correction has

> been applied, and using it with a "velocitygrid" operation.



So the parameters of this Helmert Transform are always the same for a given grid ? Or per year and/or country ? (this is probably explained in the paper...) If there's just one set of parameter for the grid, this would perhaps make sense to have a pre-processing script to correct the velocity grid.



> Another option

> would be to incorporate the Helmert shift into the velocitygrid operation

> so that the realignment can be performed when loading the grid.



Performed when *loading* the grid (ie correcting all values of the grid), or rather performed when selecting the particular velocity of the grid that applies to the coordinate being transformed ? The former could have performance implications if the grid is big and you need to transform only a couple of coordinates.



> A third

> option is to introduces some a form of nested operation in the pipeline

> framework.

>

> I don't want to make things more complicated than they need to be, so I will

> only consider option two and three above if the concept of "realigning

> gridded velocity models by Helmert shift" is a somewhat common operation.



Option 3 sounds like a complication in the general framework. Would probably require some parenthesing syntax.



Even





--

Spatialys - Geospatial professional services

http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170914/ac46e18f/attachment.html>