[PROJ] Big grid files

[Javier Jimenez Shaw]

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

>
>
> > On 27 Apr 2025, at 14.57, Greg Troxel via PROJ <proj at lists.osgeo.org>
> wrote:
> >
> > Javier Jimenez Shaw via PROJ <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
> 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/20250427/6b870976/attachment.htm>