<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<blockquote type="cite"
cite="mid:CADRrdKve-Uf0wNNSRTK=YrY8uz968_ciP76J1=TFp1p_2Hrjgw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div>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"</div>
<div>Do we have biquadratic intepolation for the geoid models?</div>
</div>
</div>
</blockquote>
If you use the generalized +proj=gridshift method, yes, with the
+interpolation=biquadratic flag:
<a class="moz-txt-link-freetext" href="https://proj.org/en/stable/operations/transformations/gridshift.html#cmdoption-arg-interpolation">https://proj.org/en/stable/operations/transformations/gridshift.html#cmdoption-arg-interpolation</a><br>
<blockquote type="cite"
cite="mid:CADRrdKve-Uf0wNNSRTK=YrY8uz968_ciP76J1=TFp1p_2Hrjgw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div><br>
</div>
<div>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)</div>
<div><br>
</div>
<div>But there are other problems:</div>
<div> - 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)</div>
</div>
</div>
</blockquote>
<p>For difference resolution per file, we already have such case
with us_noaa_nadcon5_nad83_2007_nad83_2011_alaska.tif:</p>
<p>$ gdalinfo
GTIFF_DIR:1:/home/even/proj/proj-data-1.21/us_noaa_nadcon5_nad83_2007_nad83_2011_alaska.tif<br>
[...]<br>
Origin = (171.958333333333343,73.041666666666671)<br>
Pixel Size = (0.083333333333333,-0.083333333333333)<br>
[...]<br>
Band 1 Block=256x256 Type=Float32, ColorInterp=Gray<br>
Description = latitude_offset<br>
Unit Type: arc-second<br>
Band 2 Block=256x256 Type=Float32, ColorInterp=Undefined<br>
Description = longitude_offset<br>
Unit Type: arc-second<br>
Metadata:<br>
positive_value=east<br>
<br>
</p>
<p>$ gdalinfo
GTIFF_DIR:2:/home/even/proj/proj-data-1.21/us_noaa_nadcon5_nad83_2007_nad83_2011_alaska.tif<br>
[...]<br>
Origin = (171.875000000000000,73.125000000000000)<br>
Pixel Size = (0.250000000000000,-0.250000000000000)<br>
[...]<br>
Band 1 Block=241x93 Type=Float32, ColorInterp=Gray<br>
Description = ellipsoidal_height_offset<br>
Unit Type: metre<br>
</p>
<blockquote type="cite"
cite="mid:CADRrdKve-Uf0wNNSRTK=YrY8uz968_ciP76J1=TFp1p_2Hrjgw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div>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.</div>
</div>
</div>
</blockquote>
<p>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).</p>
<span style="white-space: pre-wrap">
</span>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>