[PROJ] Big grid files - side tracking the conversation

[Mircea Neacsu]

Apologies for my side tracking:



>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 you know any reason, apart from historical ones, to use the biquadratic interpolation? I did a https://neacsu.net/docs/programming/2d-interpolation-functions/ and, from what I can see, the biquadratic method is the worst possible one.








-- 



Mircea Neacsu 




---- On Sun, 27 Apr 2025 15:31:07 -0400 Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> wrote ---






On Sun, 27 Apr 2025 at 20:15, Kristian Evers via PROJ <mailto:proj at lists.osgeo.org> wrote:



> On 27 Apr 2025, at 14.57, Greg Troxel via PROJ <mailto:proj at lists.osgeo.org> wrote:
 > 
 > Javier Jimenez Shaw via PROJ <mailto:proj at lists.osgeo.org> writes:
 > 
 >> What I did is using int16. The max error is 1.2 mm (if I did the maths
 >> correctly). The size with that change is about 24 MB
 >> If anybody wants even more accuracy, they can use int32. The reduction is
 >> smaller, but still less than 100 MB.
 > 
 > It's hard to believe that there is true accuracy to 1 mm; that seems
 > state of the art for multi-year observations determining HAE at a
 > national reference station.  But it might be nice to numerically match
 > NGS tools ~exactly as a check.
 > 
 
 That would indeed be nice. Almost required, I’d say. But it sort of seems like
 they have produced a grid file with a resolution that is too high. I get the feeling
 that some of you are in contact with the americans about this, maybe recommend
 them to reduce the resolution a bit. They won’t see much usage if they are
 too big too handle. Remember how problematic the Australian GB-sized grid files
 were before we found a way to compress them?



The resolution is 1 arc-minute. Something pretty normal nowadays in many countries. The problem here is the area: almost 1/4 of the Earth. (The northern hemisphere from far away in the Pacific to the coast of Africa).

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?



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)

 - GGXF: what I did in https://github.com/jjimenezshaw/NSRS-2022-PROJ/ for the geoid model was converting the ggxf to tif manually. That ggxf file has everything included. Maybe first we should think how do we want to package everything. One file? Several?



My initial email was just a notice to start thinking on it, and do not get a surprise the last minute.



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.



Cheers

Javier



 


/Kristian
 
 _______________________________________________
 PROJ mailing list
 mailto:PROJ at lists.osgeo.org
 https://lists.osgeo.org/mailman/listinfo/proj



_______________________________________________
PROJ mailing list 
mailto:PROJ at lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250428/8aff1a64/attachment.htm>