[PROJ] Big grid files

[Javier Jimenez Shaw]

On Sun, 27 Apr 2025 at 21:53, Even Rouault <even.rouault at spatialys.com>
wrote:

>
> During the summit I asked about the interpolation method. The metadata
> says that it should be biquadratic. The answer was: "for the undulation
> there is almost no difference. But for other magnitudes, like vertical
> deflection, it is more noticeable. However, to match our values you have to
> do biquadratic interpolation"
> Do we have biquadratic intepolation for the geoid models?
>
> If you use the generalized +proj=gridshift method, yes, with the
> +interpolation=biquadratic flag:
> https://proj.org/en/stable/operations/transformations/gridshift.html#cmdoption-arg-interpolation
>

Yes, I found that. But it has to be done with directly with the pipeline,
right? not with cs2cs.


> I would be very surprised that they release something at a different
> resolution. Some people asked for a GeoTIFF, and they were reluctant (but
> not completely oposite). They want to minimize the different formats and
> file to deal with (one ggxf for everything)
>
> But there are other problems:
>  - velocities: the full model, considering time evolution, has a velocity
> component. N_t = N_2020 + (t-t0) * v. The resolution of that velocity is
> different if I checked correctly. And we do not have such a model in PROJ.
> (It will appear in EPSG at some point)
>
> For difference resolution per file, we already have such case with
> us_noaa_nadcon5_nad83_2007_nad83_2011_alaska.tif:
>
Cool. Then adding velocities in the same file will be "easier".

> $ gdalinfo
> GTIFF_DIR:1:/home/even/proj/proj-data-1.21/us_noaa_nadcon5_nad83_2007_nad83_2011_alaska.tif
> [...]
> Origin = (171.958333333333343,73.041666666666671)
> Pixel Size = (0.083333333333333,-0.083333333333333)
> [...]
> Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
>   Description = latitude_offset
>   Unit Type: arc-second
> Band 2 Block=256x256 Type=Float32, ColorInterp=Undefined
>   Description = longitude_offset
>   Unit Type: arc-second
>   Metadata:
>     positive_value=east
>
> $ gdalinfo
> GTIFF_DIR:2:/home/even/proj/proj-data-1.21/us_noaa_nadcon5_nad83_2007_nad83_2011_alaska.tif
> [...]
> Origin = (171.875000000000000,73.125000000000000)
> Pixel Size = (0.250000000000000,-0.250000000000000)
> [...]
> Band 1 Block=241x93 Type=Float32, ColorInterp=Gray
>   Description = ellipsoidal_height_offset
>   Unit Type: metre
>
> One more thing: I do not expect them publishing the intra frame
> deformation model (IFDM2022). Every time they mentioned it they added
> "Danger!". That leave a feeling of "incompleteness" among the audience, as
> that model is needed for some time dependant transformations (like bringing
> measurements to the frame epoch, 2020.0). They will offer it in their
> webpage somehow.
>
> What about NAD83(2011) to NATRF2022: did they mention something ?
> Currently PROJ uses NAD83(2011)->ITRF2020 (EPSG:10334) and
> ITRF2020->NATRF2022 (using Euler Pole Rotation).
>
They mentioned, but not published (yet). They are doing something called
"14H", a collection of Helmert transformations to connect a bunch of
reference systems, including all the ITRF*. IIRC, there were like 35
transformations there.
There was one (named 7A,7B,7C) that was exactly NAD83(2011) to NATRF2022 (I
have no idea about the epoch). My hope is that it is equivalent to the
concatenation PROJ is doing, but let's see.
I expect they publish the slides of the summit (not a recording).

See that at 2020.0, NATRF2022 and ITRF2020 (epoch 2020.0) are identical.
There was some chaos with the different epochs and transformations
available.
It is going to be fun telling the users (and applications) that now they
have to take time into consideration (and do it properly)


> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250427/4d628a07/attachment-0001.htm>