Dear @JonathanGregory 

We have progressed with preparing the replies to your proposals. Although there 
are still a couple of open points, we thought it would be useful to share what 
we already have. 

We have numbered your proposal as Proposed Change 1-16 and treated each of 
these separately below. For each of the Proposed Changes, you will find a reply 
to the proposed change as well as the related commit(s).

We are still working on a reply to Proposed Change 15, the other replies are 
completed.

We are still working on completing the corresponding document updates in the 
form of commits for the Proposed Change 1, 2, 8, 13 and 14, the other document 
commits are complete.

We will notify you once all replies and document commits are complete.

Best regards
Anders


**Proposed Change 1 – Combining the tie_point_dimensions and tie_point_indices 
attributes** 

> There is one point where I have a suggestion for changing the content of the 
> proposal, although probably you've already discussed this possibility. If I 
> understand correctly, you must always have both the tie_point_dimensions and 
> tie_point_indices attributes of the interpolation variable, and they must 
> refer to the same tie point dimensions. Therefore I think a simpler design, 
> easier for the both data-writer and data-reader to use, would combine these 
> two attributes into one attribute, whose contents would be 
> "interpolation_dimension: tie_point_interpolation_dimension 
> tie_point_index_variable [interpolation_zone_dimension] 
> [interpolation_dimension: ...]".

**Reply to Proposed Change 1**
We agree with combining the tie_point_dimensions and tie_point_indices 
attributes in a single attribute as you suggest, but propose to put the 
tie_point_index_variable before the dimensions:
` interpolated_dimension: tie_point_index_variable  
tie_point_interpolation_dimension  [interpolation_subarea_dimension] 
[interpolated_dimension: ...].`

**Commit(s) related to Proposed Change 1**
Commit(s) being prepared

**Proposed Change 2 – Naming combined tie_point_dimensions and 
tie_point_indices to tie_points and existing tie_points to interpolation** 

> Also, I have some suggestions for naming:
> •     If you adopt my suggestion for a single attribute to replace 
> tie_point_dimensions and tie_point_indices, an obvious name for it would be 
> tie_points. You've used that name for the attribute of the data variable. 
> However, I would suggest that the attribute of the data variable could 
> equally well be called interpolation, since it names the interpolation 
> variable, and signals that interpolation is to be used.
> 

**Reply to Proposed Change 2**
We propose renaming the `tie_points `attribute of the data variable to 
`coordinate_interpolation `as this makes the name more descriptive. We propose  
to use the name `tie_point_mapping `for the attribute of the interpolation 
variable resulting from combining the `tie_point_dimensions `and 
`tie_point_indices `attributes. We favor this compared to `tie_points`, as the 
attribute does not contain or reference tie point coordinates variables.

**Commit(s) related to Proposed Change 2**
ea5268b
f8cd983
Further commit(s) being prepared

**Proposed Change 3 - Rename term "tie point interpolation dimension" to e.g. 
"tie point reduced dimension"**

> •     Your terminology has "tie point interpolation dimension" and 
> "interpolation dimension", but the former is not a special case of the 
> latter. That could be confusing, in the same way that (unfortunately) in CF 
> terminology an auxiliary coordinate variable is not a special kind of 
> coordinate variable. I suggest you rename "tie point interpolation dimension" 
> as e.g. "tie point reduced dimension" to avoid this misunderstanding.

**Reply to Proposed Change 3**
For the coordinate dimensions in the target domain, we suggest replacing the 
terms “interpolating dimension” and “non-interpolating dimension” with the 
terms “interpolated dimension” and “non-interpolated dimension”.  Then we can 
maintain the term "tie point interpolation dimension” for the tie points.

**Commit(s) related to Proposed Change 3**
7ab0c4f

**Proposed Change 4 - Rename term "tie point variable" to "tie point coordinate 
variable"**

> •     A similar possible confusion is that a tie point index variable is not 
> a special kind of tie point variable. To avoid this confusion and add 
> clarity, I suggest you could rename "tie point variable" as "tie point 
> coordinate variable".

**Reply to Proposed Change 4**
We agree to rename the term "tie point variable" to "tie point coordinate 
variable".

**Commit(s) related to Proposed Change 4**
a6d37b4

**Proposed Change 5 – Renaming of term "interpolation area"**

> •     The terms "interpolation zone" and "interpolation area" are unhelpful 
> because it's not obvious from the words which one is bigger, so it's hard to 
> remember. If you stick with "zone" for the small one, for area it would be 
> better to use something which is more obviously much bigger, such as 
> "province" or "realm"! Or perhaps you could use "division" or "department", 
> since the defining characteristic is the discontinuity.

**Reply to Proposed Change 5**
We propose replacing the terms
"interpolation area(s)”, each consisting of one or more “interpolation zone(s)”
with
“continuous area(s)”, each consisting of one or more “interpolation subarea(s)”.

**Commit(s) related to Proposed Change 5**
d6d7ea3

**Proposed Change 6 -  Rewording of first paragraph of Section 8**

> In the first paragraph of Sect 8 we distinguish three methods of reduction of 
> datset size. I would suggest minor clarifications:
> There are three methods for reducing dataset size: packing, lossless 
> compression, and lossy compression. By packing we mean altering the data in a 
> way that reduces its precision (but has no other effect on accuracy). By 
> lossless compression we mean techniques that store the data more efficiently 
> and result in no loss of precision or accuracy. By lossy compression we mean 
> techniques that store the data more efficiently and retain its precision but 
> result in some loss in accuracy.
> 
> Then I think we could start a new paragraph with "Lossless compression only 
> works in certain circumstances ...". By the way, isn't it the case that HDF 
> supports per-variable gzipping? That wasn't available in the old netCDF data 
> format for which this section was first written, so it's not mentioned, but 
> perhaps it should be now.

**Reply to Proposed Change 6**

We agree with your proposed text and have updated the text accordingly. 
Additionally, we have opened anissue (Rework intro to Section 8: Accuracy & 
precision · Issue #330 · cf-convention/cf-conventions (github.com)) to address 
per-variable gzipping as well as to verify that the usage if the terms 
precision and accuracy are correct. 

**Commit(s) related to Proposed Change 6**
27d1733

**Proposed Change 7 – Clarification of effect for domain variables**

> There are a few points where I found the text of Sect 8.3 possibly unclear or 
> difficult to follow:
> •     "This form of compression may also be used on a domain variable with 
> the same effect." I think this is an unclear addition. If I understand you 
> correctly, insead of this final sentence you could begin the paragraph with 
> "For some applications the coordinates of a data variable or a domain 
> variable can require considerably more storage than the data in its domain."

**Reply to Proposed Change 7**

We propose to remove the sentence "This form of compression may also be used on 
a domain variable with the same effect." and not replace it, as the the 
definition of the Domain variable already allows for this compression.

**Commit(s) related to Proposed Change 7**
971bfbe

**Proposed Change 8 – Rewording of section on Tie Point Dimensions Attribute**

> •     Tie Point Dimensions Attribute. If you adopt my suggestion above, this 
> subsection would change its name to "Tie points attribute". It would be good 
> to begin the section by saying what the attribute is for. As it stands, it 
> plunges straight into details. The second sentence in particular, about 
> interpolation zones, bewildered me - I didn't know what it was talking about.

**Reply to Proposed Change 8**

As we have agreed to combine the `tie_point_dimensions `and `tie_point_indices 
`attributes (Proposed Change 1 and 2), then we must also reorganise the old 
sections Section 8.3.5, "Tie Point Dimensions Attribute", Section 8.3.6, "Tie 
Point Indices" to reflect this change. When doing this, we will also improve 
the wording.

**Commit(s) related to Proposed Change 8**
Commit(s) being prepared

**Proposed Change 9**

> •     I follow this sentence: "For instance, interpolation dimension 
> dimension1 could be mapped to two different tie point interpolation 
> dimensions with dimension1: tp_dimension1 dimension1: tp_dimension2." But I 
> don't understand the next sentence: "This is necessary when different tie 
> point variables for a particular interpolation dimension do not contain the 
> same number of tie points, and therefore define different numbers of 
> interpolation zones, as is the case in Multiple interpolation variables with 
> interpolation parameter attributes." The situation described does not occur 
> in the example quoted, I think. I wonder if it should say, "This occurs when 
> data variables that share an interpolation dimension and interpolation 
> variable have different tie points for that dimension."

**Reply to Proposed Change 9**
We will delete the reference to the example.

We will update the text as follows:

A single interpolated dimension may be associated with multiple tie point 
interpolation dimensions by repeating the interpolated dimension in the 
`tie_point_mapping` attribute. For instance, interpolated dimension 
`dimension1` could be mapped to two different tie point interpolation 
dimensions with `dimension1: tp_index_variable1  tp_dimension1 dimension1: 
tp_index_variable2 tp_dimension2`. This is necessary when two or more tie point 
coordinate variables have different tie point index variables corresponding to 
the same interpolated dimension. A tie point coordinate variable must span at 
most one of the tie point interpolation dimensions associated with a given 
interpolation dimension. 

**Commit(s) related to Proposed Change 9**
3d4348f

**Proposed Change 10**

> •     Instead of "A tie point variable must span at most one of the tie point 
> interpolation dimensions associated with a given interpolation dimension." I 
> would add a sentence to the first para of "Interpolation and 
> non-interpolation dimension", which I would rewrite as follows:
> For each interpolation variable identified in the tie_points attribute, all 
> the associated tie point variables must share the same set of one or more 
> dimensions. Each of the dimensions of a tie point variable must be either a 
> dimension of the data variable, or a dimension of which is to be interpolated 
> to a dimension of the data variable. A tie point variable must not have more 
> than one dimension corresponding to any given dimension of the data variable, 
> and may have fewer dimensions than the data variable. Dimensions of the tie 
> point variable which are interpolated are called tie point reduced 
> dimensions, and the corresponding data variable dimensions are called 
> interpolation dimensions, while those for which no interpolation is required, 
> being the same in the data variable and the tie point variable, are called 
> non-interpolation dimensions. The size of a tie point reduced dimension must 
> be less than or equal to the size of the corresponding interpolation 
> dimension. 

**Reply to Proposed Change 10**

We propose the new wording:
For each interpolation variable identified in the coordinate_interpolation 
attribute, all of the associated tie point coordinate variables must share the 
same set of one or more dimensions. This set of dimensions must correspond to 
the set of dimensions of the uncompressed coordinate or auxiliary coordinate 
variables, such that each of these dimensions must be either the uncompressed 
dimension itself, or a dimension that is to be interpolated to the uncompressed 
dimension.

Dimensions of the tie point coordinate variable which are to be interpolated 
are called tie point interpolation dimensions, and the corresponding data 
variable dimensions are called interpolated dimensions, while those for which 
no interpolation is required, being the same in the data variable and the tie 
point coordinate variable, are called non-interpolated dimensions. The 
dimensions of a tie point coordinate variable must contain at least one tie 
point interpolation dimension, for each of which the corresponding interpolated 
dimension cannot be included.

**Commit(s) related to Proposed Change 10**
190fdff
7ab0c4f


**Proposed Change 11**

> •     In one place, you say "For each interpolation dimension, the number of 
> interpolation zones is equal to the number of tie points minus the number of 
> interpolation areas," and in another place, "An interpolation zone must span 
> at least two points of each of its corresponding interpolation dimensions." 
> It seems to me that "at least" is wrong - it should be "exactly two".

**Reply to Proposed Change 11**
Both sentences are true, but we can see that it is easily misunderstood.

The “span at least two points” refers to points in the interpolated dimension 
of the target domain. With the proposed Proposed Change 3, the proposed 
rewording of the second sentence is "An interpolation zone must span at least 
two points in each of its corresponding interpolated dimensions"

**Commit(s) related to Proposed Change 11**
d715552
5cfae45

**Proposed Change 12**

> •     "The dimensions of an interpolation parameter variable must be a subset 
> of zero or more of the ...".

**Reply to Proposed Change 12**
We agree.

**Commit(s) related to Proposed Change 12**
fdeef67

**Proposed Change 13**

> •     I suggest a rewriting of the part about the dimensions of interpolation 
> parameter variable, for clarity, if I've understood it correctly, as follows:
> Where an interpolation zone dimension is provided, the variable provides a 
> single value along that dimension for each interpolation zone, assumed to be 
> defined at the centre of interpolation zone.
> Where a tie point reduced dimension is provided, the variable provides a 
> value for each tie point along that dimension. The value applies to the two 
> interpolation zones on either side of the tie point, and is assumed to be 
> defined at the interpolation zone boundary (figure 3).
> 
> In both cases, the implementation of the interpolation method should assume 
> that an interpolation parameter variable applies equally to all interpolation 
> zones along any interpolation dimension which it does not span.

**Reply to Proposed Change 13**
We propose changing this existing text:

“The dimensions of an interpolation parameter variable must be a subset of zero 
or more the tie point variable dimensions, with the possibility of a tie point 
interpolation dimension being replaced with the corresponding interpolation 
zone dimension. The interpretation of an interpolation parameter variable 
depends on which of its dimensions are tie point interpolation dimensions, and 
which are interpolation zone dimensions:
•       If no tie point interpolation dimensions are spanned, then the variable 
provides values for every interpolation zone. This case is akin to values being 
defined at the centre of interpolation zones.
•       If at least one dimension is a tie point interpolation dimension, then 
the variable’s values are to be shared by the interpolation zones that are 
adjacent along each of the specified tie point interpolation dimensions. This 
case is akin to the values being defined at the interpolation zone boundaries, 
and therefore equally applicable to the interpolation zones that share that 
boundary (figure 3).”
In both cases, the implementation of the interpolation method should assume 
that an interpolation parameter variable is broadcast to any interpolation 
zones that it does not span."

with this new text:

“The interpolation parameter variable dimensions must include, for all of the 
interpolation dimensions, either the associated tie point interpolation 
dimension or the associated interpolation subarea dimension. Additionally, any 
subset of zero or more of the non-interpolation dimensions of the tie point 
coordinate variable are permitted as interpolation parameter variable 
dimensions.

The application of an interpolation parameter variable is independent of its 
non-interpolation dimensions, but depends on its set of tie point interpolation 
dimensions and interpolation subarea dimensions: 

-       If the set only contains tie point interpolation dimensions, then the 
variable provides values for every tie point and therefore equally applicable 
to the interpolation zones that share that tie point, see example a) in figure 
3;
-       If the set only contains interpolation subarea dimensions, then the 
variable provides values for every interpolation zone and therefore only 
applicable to that interpolation zone, see example b) in figure 3;
-       If the set contains both tie point interpolation dimensions and 
interpolation zone dimensions, then the variable’s values are to be shared by 
the interpolation zones that are adjacent along each of the specified tie point 
interpolation dimensions. This case is akin to the values being defined at the 
interpolation zone boundaries, and therefore equally applicable to the 
interpolation zones that share that boundary, see example c) and d) in figure 
3;”

In figure 3, the fourth example will be deleted and the broadcast type 
application of interpolation parameter variable values is no longer supported, 
as it was difficult to define accurately. 

**Commit(s) related to Proposed Change 13**
ba4a65e 
Further commit(s) being prepared


**Proposed Change 14**

> •     For "The bounds of a tie point must be the same as the bounds of the 
> corresponding target grid cells," I would suggest, "The bounds of a tie point 
> must be the same as the bounds of the target grid cells whose coordinates are 
> specified as the tie point."

**Reply to Proposed Change 14**

We agree with the proposed new text: "The bounds of a tie point must be the 
same as the bounds of the target grid cells whose coordinates are specified as 
the tie point."

**Commit(s) related to Proposed Change 14**
aceb987

**Proposed Change 15**
> •     I don't understand this sentence: "In this case, though, the tie point 
> index variables are the identifying target domain cells to which the bounds 
> apply, rather than bounds values themselves." A tie point index variable 
> could not possibly contain bounds values.

**Reply to Proposed Change 15**
Reply being prepared

**Commit(s) related to Proposed Change 15**
Commit(s) being prepared

**Proposed Change 16**

> •     In Example 8.5, you need only one (or maybe two) data variables since 
> they're all the same in structure.

**Reply to Proposed Change 16**

In Example 8.5, we propose deleting the data variables `I01_radiance `and 
`I01_reflectance `and to keep `I04_radiance `and `I04_brightness_temperature 
`to demonstrate the reuse of the interpolation variable for data variables with 
different units.

**Commit(s) related to Proposed Change 16**
f439ee5



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/327*issuecomment-867861484__;Iw!!G2kpM7uM-TzIFchu!kvFXfH3POWXVqxozAhf0fwuB30n7AbmDqdhWl1eq4_uIny4wO7Cgk2wWBVUJ2MO07oODQMtzLlc$
 
This list forwards relevant notifications from Github.  It is distinct from 
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the 
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to 
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.

Reply via email to