Should interpolation container variables be reusable?

[ajelenak]

By reusable I mean apply to more than one interpolated coordinate system in the same file. Properties (attributes) assigned to these container variables should preferably be generic enough to apply to more than one set of subsampled/interpolated coordinates. What if for a specific interpolation method its coefficients and formula are well-known and always the same? Or the interpolation coefficients can be expressed as scalar numbers and the interpolation formula is known and same? This is the same as for projected CRSs in the grid mapping container variable? Grid mapping variable attributes do not specify to which coordinates they apply.

[erget]

Projected CRS don't specify to which coordinates they apply, but the variables that reference them still reference the coordinates to which the grid mappings apply, so they're connected as

grid mapping <--> variable <--> coordinates

Some of the metadata we're currently considering associating with the interpolation variable is specific to individual interpolation zones, which are in turn specific to the location of the observation in question, such as the cartesian vs. EFRS interpolation to allow for interpolation near singularities.

If we were to make the interpolation container reusable (fine) we'd need to makes sure that such metadata is stored closer to the interpolation zones themselves and referenced from there so that it's portable.

[erget]

Note from today's meeting: The container variable should not contain the indices; these should be attached to the data variables themselves. This makes the container reusable.

[davidhassell]

I agree that the indices should not be in the interpolation container, but don't think that they should be attached to the data variable, either. I think that they should not be referenced by any variable, but have an attribute interpolation_dimension that identifies them as a variable of tie points (cf. index and count variables for DSGs).

When a variable is named by the subsampled_coordinates attribute, software knows to look at all of the index variables and use the one which spans the same dimension.

[TomLav]

I agree here. This is the same logic as with grid_mapping and projection_x|y_coordinates .

For grid mappings, we always need an "x" and a "y" (can be "longitude" and "latitude", etc...). Do we need the same for subsampling / interpolation ?

interpolation_x_coordinate and interpolation_y_coordinate ? (names are not important: do they need to be identified as x or y, since we cannot rely on the name of the variables nor the dimensions)?

ons. 27. mai 2020 kl. 10:26 skrev David Hassell notifications@github.com:

I agree that the indices should not be in the interpolation container, but don't think that they should be attached to the data variable, either. I think that they should not be referenced by any variable, but have an attribute interpolation_dimension that identifies them as a variable of tie points (cf. index and count variables for DSGs).

When a variable is named by the subsampled_coordinates attribute, software knows to look at all of the index variables and use the one which spans the same dimension.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/erget/subsampled-coordinates/issues/5#issuecomment-634509940, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACLNBOFQLNWGMBWMYBGZVVTRTTFC5ANCNFSM4NIPJ6WA .

[davidhassell]

Hi, I think that we don't need to insist on special standard names, because the coordinates are unambiguously identified when they are referenced by the subsampled_coordinates attribute. Also, this technique should be generalisable to more than 2 dimensions, which would make it hard to find suitable names!