Dear @JonathanGregory , Thank you for your rich set of comments and suggestions. I have provided replies below, in the same format we used for the first set of comments. Several of the replies I have already implemented in the document and indicated the corresponding commit. For others, the reply is not conclusive and if you find time, your feedback on the reply would be valuable.
The comments on the conformance chapter, I would prefer that @davidhassell look at when he is available again. Best regards, Anders **Comment/Proposed Change 17** > Chapter 8: "Tie point mapping attribute" mentions "target dimension", which > is not a phrase used elsewhere. Should this be "interpolated dimension"? **Reply to Comment/Proposed Change 17** You are right, it should be "interpolated dimension" in that section. I have updated the text. **Commit(s) related to Comment/Proposed Change 17** ca81618 **Comment/Proposed Change 18** > Chapter 8: You say, "For the purpose of bounds interpolation, a single bounds > tie point is created for each coordinate tie point, and is selected as the > vertex of the tie point cell that is the closest to the boundary of the > interpolation subarea with respect to each interpolated dimension." I don't > understand why there is a choice of bounds tie points, because there's no > index variable for them. Doesn't the tie point index variable dictate the > choice of tie points for bounds? **Reply to Comment/Proposed Change 18** In the compressed data set we only store one bounds tie points per coordinate tie point. However, in the existing boundary variable defined in section 7.1. Cell Boundaries, requires you to store, in the case of 2D bounds for example, fours bounds. The selection is between those four bounds, of which only one is the correct selection. Did that help? Let me know if you think we can improve the text in that respect. **Commit(s) related to Comment/Proposed Change 18** None **Comment/Proposed Change 19** > Appendix J: The title says Appendix A. Presumably that's something to do with > automatic numbering. **Reply to Comment/Proposed Change 19** Correct, that will be updated as part of the publishing magic. **Commit(s) related to Comment/Proposed Change 19** None. **Comment/Proposed Change 20** > Appendix J: All of the subsections listed at the start (Common Definitions > and Notation, Common conversions and formulas, Interpolation Methods, > Coordinate Compression Steps, Coordinate Uncompression Steps) should have > subsection headings, I think. They will be Sections J.1 etc. At the moment > the last two are labelled as Tables J.1 and J.2 rather than subsections, but > they're never referenced as tables. **Reply to Comment/Proposed Change 20** I agree and have introduced section numbering and removed table captions in Appendix J. **Commit(s) related to Comment/Proposed Change 20** f6f48fb **Comment/Proposed Change 21** > Appendix J: Fig 1ff. s is explained beneath the fig, but it would be useful > it explain it at the side of the fig as well, as you do for tp i and u. **Reply to Comment/Proposed Change 21** Done. Also, I have named s as the “interpolation argument”, which I think is what it is. **Commit(s) related to Comment/Proposed Change 21** 1002806 **Comment/Proposed Change 22** > Appendix J: Also, it would be useful to put the paragraph explaining > notation before Fig 1, because Fig 1 uses the notation. **Reply to Comment/Proposed Change 22** Agree. Done. **Commit(s) related to Comment/Proposed Change 22** 0fdc7e4 **Comment/Proposed Change 23** > You say, "When an interpolation method is referred to as linear or quadratic, > it means that the method is linear or quadratic in the indices of the > interpolated dimensions." Linear also means that the coordinates of the > interpolated points are evenly spaced, doesn't it; if so, that would be > helpful to state. > Appendix J: **Reply to Comment/Proposed Change 23** Good observation, I have added that. **Commit(s) related to Comment/Proposed Change 23** 5f9ad9a **Comment/Proposed Change 24** > Appendix J: You say, "In the case of two dimensional interpolation, the two > variables are equivalently computed as ...". I would say "similarly", not > "equivalently", which I would understand to mean that s1 and s2 are > equivalent. **Reply to Comment/Proposed Change 24** Done. **Commit(s) related to Comment/Proposed Change 24** 0116283 **Comment/Proposed Change 25** > Appendix J: It would be better not to use c for the coefficient, because it > can be confused with the point c. **Reply to Comment/Proposed Change 25** Agreed and renamed from “c” to “w”. Also renamed related function fc() to fw(). **Commit(s) related to Comment/Proposed Change 25** ea474a5 **Comment/Proposed Change 26** > Appendix J: Please put the "Common conversion and formulae" table before the > interpolation methods, or at least refer to it. Otherwise the reader > encounters fdot fcross fplus fminus fmultiply etc. without having seen their > definitions. Actually you list it before the interpolation methods in the > preamble. **Reply to Comment/Proposed Change 26** Good point, section moved. **Commit(s) related to Comment/Proposed Change 26** 4efef82 **Comment/Proposed Change 27** > Appendix J: [bi_]quadratic_remote_sensing. Why not call it > [bi_]quadratic_latitude_longitude, which describes the method, rather than > its typical application? > What does it mean to treat them as Cartesian or not? I would describe > bilinear interpolation in lat,lon as treating them as Cartesian coordinates, > but you must mean something different. Is there a projection plane involved? > **Reply to Comment/Proposed Change 27** We hope to find time after this review to prepare a small paper or a presentation that provides more insight into the interpolation methods and their performance. You are right, it is like a projection plane, but we are using 3D cartesian coordinates. The problem we are addressing is that interpolating directly in latitude/longitude is inadequate when we are close to the poles. So, we temporarily convert the four tie points from lat/lon to xyz, do the interpolation and then convert the result back from xyz to lat/lon. Another common way to address this problem is to project the lat/lon point on the xy plane, do the interpolation and project the point back to lat/lon. However, by using xyz, we can also solve the problem that arises when our interpolation subarea crosses +/-180 deg longitude. Let me try to support the above with a simple example (hoping that I am not upsetting anybody with such a simple example...) Think of a hypothetical remote sensing instrument that scans the Earth in a way that can be approximated as arcs of a great circle on the Earth surface. So, if the instrument scans from point A to point B, then the points it scanned between A and B will be on the great circle between A and B. It will follow this simple principle for any location on Earth. If you are near Equator and A = (0W, 0N) and B= (4W, 4N), then you can generate three points between A and B by interpolating in longitude and latitude separately and will get (1W, 1N), (2W, 2N) and (3W, 3N), which are approximately aligned with the great circle arc between A and B. If you are near the North Pole and A = (0W, 88N) and B= (180W, 88N) and do the interpolation in longitude and latitude separately, you will get (45W, 88N), (90W, 88N) and (135W, 88N), which are on an arc of a small circle and is the wrong result. By first converting to cartesian coordinates, then interpolating and then converting back to longitude latitude, you will get the correct result: (0W, 89N), (0W, 90N) and (180W, 89N), which are on a great circle. That was also why we suggested the name with [bi_]quadratic_remote_sensing. I would be fine [bi_]quadratic_latitude_longitude too. I suggest that we also discuss it in the group during our meeting on Tuesday. **Commit(s) related to Comment/Proposed Change 27** None so far. **Comment/Proposed Change 28** > Appendix J: Where is latitude_limit defined? **Reply to Comment/Proposed Change 28** It is a value to be decided by the creator of the data set, as a trade-off between speed and accuracy, considering that the conversions to and from cartesian coordinates takes longer. Practically, it will be in the order of 85 degree of latitude. I could add that. But I suggest that we also discuss it in the group during our meeting on Tuesday. **Commit(s) related to Comment/Proposed Change 28** None so far. **Comment/Proposed Change 29** > Appendix J: A couple of times, you write, "For each of the interpolated > dimension". There should be an -s. **Reply to Comment/Proposed Change 29** Corrected. **Commit(s) related to Comment/Proposed Change 29** 303aaa4 -- 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-885811067__;Iw!!G2kpM7uM-TzIFchu!mLle3Ue6s3v81QFYajS_Cun1nTLVNAIC-TqQWOjjOiR414WucEVrwzbgIDCwLH2Cbq3UTkpmPaQ$ 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.
