Choose base term for naming new attributes

[ajelenak]

There are at least two different naming schemes for new attributes currently in use. Since the number of these new attributes seems to be stabilizing, now would be a good time to pick a base term from which to derive new attribute names.

These two terms have been used so far: subsample and interpolate. Additional options: reduce, restore.

A related issue is the term tie point. It is somewhat specific to remote sensing. Perhaps anchor is a more generic term but equally applicable?

Other naming suggestions are welcome!

[erget]

Here's my opinions on terms:

• Tie point vs. ground control point vs. geotiepoint vs. anchor vs. subsampled coordinate: I'm in favour of "tie point" because:
  • "Subsampled coordinate" implies for me that we're "thinning" coordinates, which can be the case but is not always the case, as we are sometimes interpolating pixel centres from provided corner coordinates.
  • "Anchor" is not in common use AFAIK.
  • "Geotiepoint" is in common use within one community that we are familiar with (PyTroll), but beyond that I haven't heard of it and it introduces the added complexity of trying to define what the "geo" part means. Geoid? Ellipsoid? What happens if and when we introduce terrain correction? What happens if we're viewing a point in the atmosphere, not on the ground?
  • "Ground control point" has similar issues as "geotiepoint" and is also used in other communities for orthorectification or georeferencing, which are different concerns than what we have here.
  • "Tie point" is general enough to accurately describe interpolating from pixel corners, centres, etc., meaning that it's already widespread in remote sensing but is also general enough to accurately describe other use cases.
• Subsampling vs. compaction vs. reduction: I'm for "compaction" to describe delivering the limited set of coordinates that the user interpolates in accordance with the provided directives. In fact we are not necessarily subsampling coordinates, for when we use corner coordinates we're doing something that's more complex. Therefore I believe that both "subsampling" and "reduction" are not general enough for the use cases we are covering.
• Uncompacted vs. restored vs. full vs. complete vs. upsampled: Originally, I advocated using the term "full coordinates" to discuss the coordinates that result from interpolating as we advise the user, for much the same reason that I advocate using the term "compaction" to describe the reduction of the number of coordinates we provide. However, @davidhassell notes that "un"-compacting coordinates would correspond with current vocabulary. The term feels a bit clunky in the mouth but I prefer precision to aesthetics.
• Proposed title of the proposal (for later): Parametrised coordinate interpolation. The issue that spawned this was named "Standard way to define subsampled coordinates" and that is accurate for many, but not all use cases we are developing. What is clear in all cases is that we are interpolating, that this interpolation is parametrised (in some cases this is very straightforward, in other cases this may be more complex), and that what we are interpolating are coordinates (to be specific auxiliary coordinate variables in most cases).

[davidhassell]

"Subsampled coordinate" implies for me that we're "thinning" coordinates, which can be the case but is not always the case, as we are sometimes interpolating pixel centres from provided corner coordinates.

I get the message here - that a "subsampled" coordinate does not need to correspond to exact location of one of the full (post-interpolation) coordinates. I don't follow the example, though: I not sure what "corner coordinates" are. Is the conical scanner case an example of this?

Thanks!

[davidhassell]

Restored vs. full vs. complete vs. upsampled: I advocate using the term "full coordinates" to discuss the coordinates that result from interpolating as we advise the user, for much the same reason that I advocate using the term "compaction" to describe the reduction of the number of coordinates we provide.

Perhaps the result from interpolating should be "un" the name of the provided values, which is analogous to (un)packed and (un)compressed - terms which are already in use. I.e. if we were to call the values in the file "compacted", then result of interpolation could be "uncompacted".

[erget]

The specific example I had in mind was the VIIRS case - there the tiepoints correspond to the corners of interpolation groups. This example demonstrates a lot of the advantages:

A, B, C, and D are the corners of the interpolation zone. The grid spanned between them is split into individual pixels, whose centres are dots. By specifying how the tie-points are offset from the closest pixel corners and how to bend the lines AB and CD, AD and BC respectively, you can reconstruct all of those dots from A, B, C, D and the parameterization.

Thus A, B, C, and D don't belong to the original, "full" set of coordinates.

By specifying different offsets of course we could use tie-points whose positions are collocated with the centres of their corresponding pixels. Using the corners is nice because it allows us to store one set of tie-points that can be applied to observations from multiple instruments that observe on similar grids but at different resolutions (in the case of VIIRS these are the M- and I-bands).

[erget]

From @davidhassell:

Perhaps the result from interpolating should be "un" the name of the provided values, which is analogous to (un)packed and (un)compressed - terms which are already in use. I.e. if we were to call the values in the file "compacted", then result of interpolation could be "uncompacted".

Lots of wisdom there, I've edited my comment to say

• Uncompacted vs. restored vs. full vs. complete vs. upsampled: Originally, I advocated using the term "full coordinates" to discuss the coordinates that result from interpolating as we advise the user, for much the same reason that I advocate using the term "compaction" to describe the reduction of the number of coordinates we provide. However, @davidhassell notes that "un"-compacting coordinates would correspond with current vocabulary. The term feels a bit clunky in the mouth but I prefer precision to aesthetics.

[erget]

We're considering this agreed and adopting this into the proposal's terms.

[davidhassell]

@erget - could you re-e-mail the zoom link? Thanks!

[ajelenak]

Wasn't clear for me towards the end of today's meeting, should this issue be reopened to discuss the specific attribute names using the adopted "compact" base term or should there be separate issue?

[erget]

I had understood this issue to refer to general terminology issues - are you referring to namespacing or a similar concern?

[ajelenak]

I am thinking of the next step, which would be to apply the adopted base term "compact" to actual new attribute names. Is this what you call "namespacing"?

[erget]

I think so. Let's see with some examples:

• Say we're talking about the "compact dimensions" that the tie points span, we would call them something like compact_dimension
• Tie points would be called compact_tie_point in order to use the same prefix, thus making them easier to find

Is this what you mean?

[AndersMS]

I was thinking of the "compaction" more as a description of the overall process, not necessarily as a word that would appear in variable or attribute names.

See also my comment here: #6 (comment)

[ajelenak]

No, this issue was not for just the term describing the overall process but for the term to apply in new attribute names.

[erget]

OK. I'd be fine with using interpolation_ as a prefix, if you think it makes sense in light of our describing the overarching process as "compaction".