the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
A climate data record of year-round global sea-ice drift from the EUMETSAT Ocean and Sea Ice Satellite Application Facility (OSI SAF)
Emily Down
Download
- Final revised paper (published on 20 Dec 2023)
- Preprint (discussion started on 07 Mar 2023)
Interactive discussion
Status: closed
-
RC1: 'Comment on essd-2023-40', Anonymous Referee #1, 24 Apr 2023
The authors introduced a new climate data record of sea ice drift vectors from 1991-2020, which covers both Arctic and Antarctic. This provides good continuity data for long time series observation of sea ice motion in polar regions, and is useful for quantifying the response of sea ice motion to climate change. The overall organization of this manuscript is clear and the methods are well described in detail. However, the comparative analysis of the product with other products in the manuscript is relatively vague and there is a lack of elaboration on the areas in which the product could be applied. After refining the above deficiencies, I consider this article would be more in line with the main purpose of the Earth System Science Data. Some improvements could be made, as listed below.
Major comments:
1. The introduction describes relatively little about the importance of sea ice drift, although much of it is well known. For readers unfamiliar with the field, what is the need to produce sea ice drift products? What can we apply sea ice drift products for? Please emphasize this in the introduction.
2. Usually buoy data are considered to have a certain level of authenticity and accuracy, and the reason for not choosing buoy data as one of the input sources in the section on multi-source merging (Section 3.4) needs to be elaborated more than just emphasizing the difference from existing sea ice motion products (L285).
3. The lack of comparisons with existing sea ice motion products would be relatively strange. For users of the data, a general overview comparison with widely used products is necessary. It is also useful to have a visual overview of the advantages of this new CDR product.
4. After reading the whole manuscript, my main concern is, what exactly are the advantages of the new sea ice drift CDR product? This needs to be highlighted and detailed, but there is no summary paragraph in the introduction or in section 4.3 (Discussion, known limitations and outlook), which is not convincing. According to the manuscript, the new CDR has a coarse spatial resolution of 75 km and a time length of 1991-2020, which is not as fine as the products provided by NSIDC and IFREMER in terms of time length and spatial resolution.
5. Section 4.3.4 mentions that for the free-drift model, the authors' method does not capture the multi-year interdecadal variability of the relationship between wind and sea ice motion vectors, which is a non-negligible problem for summer sea ice motion. I would like to know how this problem is handled by other products that have been applied besides the mentioned solution by Brunette et al., (2022). You only seem to mention that the NSIDC product use a constant wind-ice-ocean transfer coefficient.
Minor comments:
1. “The first/second part of the period” appears several times in the manuscript, e.g., L631, L632 and L640. It would be more appropriate to clarify the period in which the product showed a large bias when reminding users of the precautions (Section 4.3.4).
2. L222 “The model is expected to be less valid in winter than in summer, and less in the Arctic than in the Antarctic, because of neglecting internal sea-ice stresses.” This statement is a bit difficult for me to understand, please explain it in more detail.
3. L412 I tried to find the Appendix B but couldn't.
4. L508 Given that the multi-oi summer sea ice drift product is obtained by merging only wind-driven product, their RMSEs are exactly equal rather than very similar by comparing Tables 7 and 6.Citation: https://doi.org/10.5194/essd-2023-40-RC1 -
RC2: 'Comment on essd-2023-40', Anonymous Referee #2, 21 May 2023
Review of
A Climate DAta Record of year-round global sea ice drift from the EUMETSAT OSI SAF
by
T. Lavergne and E. Down
Summary:
This paper introduces a long needed alternative to the NSIDC sea-ice motion data set based on satellite microwave radiometer observations. Albeit shorter, i.e. for 1991-2020, the description of the data set itself, how it has been derived from a well-established high-quality inter-sensor calibrated microwave brightness temperature data set and ERA5 near-surface wind speed data input to a free-drift sea ice model, and how the data have been evaluated with buoy observation is very good and provides a quite comprehensive insight into this new data set. The data set is available for both hemispheres at daily temporal resolution. While the data set is year-round only the winter months are based solely on satellite observations. Summer months data are solely based on free-drift sea ice model forced with ERA5 near-surface winds tuned to summer sea-ice motion derived from the latest generation of satellite microwave radiometer observations. Transition months are a blend. An essential detail to know is that the product contains sea ice displacement together with position and temporal information; the product does not contain readily derived sea ice drift velocity. The data set itself follows latest CF-conventions, is very-well documented in the netCDF files' global attributes and contains a useful set of flag values. The data are accessible via tools such as ncview and the Climate Data Operators (cdos), documenting their usability.General comments:
GC1: There are a few aspects detailed in my specific comments that require a bit more information and/or rewriting parts of the text. To this belongs usage of different frequency channels for SSM/I / SSMIS versus AMSRX, the transition of sea-ice model based sea ice velocity to sea ice displacement, and an even more comprehensive motivation of and emphasis on the fact that the product contains displacement along the x- and y-axis of the EASE grid used - which makes an easy uptake and usage of the product not straightforward for quite a fraction of users. Also not clear is why on the one hand summer sea ice motion is derived from the free-drift sea-ice model but on the other hand the summer sea ice motion data are considered good enough for the required tuning.GC2: I am not convinced that the discussion added regarding apparent differences in the bias been buoy and satellite (or multi-oi) data is mature enough to be kept in the form as is in this manuscript. What I am missing instead and was hoping that it would be touched somewhere in the discussion is the consideration of the free-drift assumption during summer. How "accurate" are the summer sea ice displacement estimates for sea ice concentrations below, say, 80%, or for almost closed sea ice conditions?
Specific comments:
L72: It seems you decided to use the near-90 GHz channels for your product because of their comparably fine resolution. But what about the weather influence at this frequency which is known to be considerably larger than at the other channels offered by SSM/I or SSM/IS?
In fact this is contrasting what you write later-on about AMSR-E/2 where you explicitly state that you are NOT using the 89 GHz channels because of the larger atmospheric influence. This inconsistency needs to be clarified.L92: "free drift" requires sea ice concentrations below about 80%. What is the uncertainty / bias in case this constraint is not met? Is this discussed and if yes in what context?
L134/135: "in particular ... and 24 UTC" --> I have a problem understanding this. Every point in the polar hemisphere is covered by a number of satellite overpasses every day - those closer to the poles more often. I can imagine that for some regions there are overlapping overpasses at (roughly, don't count me on the full hours please), for instance, 4 UTC and 6 UTC and then later on at 15 UTC and 17 UTC (i.e. four overpasses in total) whereas there are other regions where these overpasses occur at 9 UTC and 11 UTC and later on at 20 UTC and 22 UTC. Does your weighing scheme mean that in the first case overpasses at 15 UTC and 17 UTC would given more weight than the other two (because of being closer to 12 UTC) while in the second case it would be the overpasses at 9UTC and 11 UTC? Doesn't this result in a preference of using TB values always from the same time of the day since overpass times are rather stable - within certain bounds? It seems to me that this results in regions where gridded TB values are predominantly either from the ascending overpasses or from the descending ones. Is this the intention?
L136-138: "we compute ... is useful ..." I have two comments here.
- 1) Does the mean observation time use the same weighing as introduced above? If not my first case from the previous comment would result in 10:30 UTC and the second case in 15:30 UTC - which would not reflect the time of those swaths that has been given more weight than others.
- 2) You state that the users of the CDR and your own evaluation activities would need this mean time. I agree. You might want to state for what and hereby stress that your CDR does not include any speed information but is solely about the displacement.
- This puts the question in my mind whether, when doing the consistency checks of your data set, investigated whether the time difference between two consecutive displacement maps provides a reasonable ice motion speed estimate when used to compute the velocity.L142/143: The influence of this Laplacian filter seems to be quite delicate because on the one hand it removes gradients in the intensity while on the other hand it is supposed to enhance patterns. As written this seems contradictory and I invite you to provide sample information about how such a gradient might look like and where it comes from (i.e. what is its cause), and how one can discriminate between a gradient and a pattern.
L145: "rotated onto the EASE2 ..." --> It is inherently recognizable that you thereby switch from the meteorological convention of directions to the "grid world" and are only interested in the components along the x- and y-directions of the grid.
I guess this is the right moment to comment that: If you would have decided to provide a sea-ice motion instead of a sea-ice displacement product, then this step would have been obsolete. I haven't found yet the motivation why you prefer to derive a sea-ice displacement product. I fear that the uptake of such a product by the user community won't be straightforward - particularly in light of the NSIDC sea ice motion product providing motion in x- and y-direction of the grid they used and the modificed version of this product offered by ICDC which comes up with the u- and v-component of the ice motion in meteorological notation - an, to my opinion, much more handy product as it immediately represents the action of cyclones on the sea ice. In your product, one does not only need to play around with the time information to derive the motion (and with that to be at the same level as the NSIDC product) but one also needs to be very careful in the interpretation of the data as a positive x-displacement means eastward drift just north of Svalbard, southward drift in the Laptev Sea, and westward drift north of Bering Strait ... complicated ... and error-prone for a user.L183-189: Since your product is a sea ice displacement it would be good to provide a number for the maximum displacement in addition to the 0.45 ms-1. That way a reader can go back to the product and eventually check how far away a particular value in the displacement maps is from this maximum displacement value.
L202-203: "value less than rho = 0.5" --> It seems that this is the first time you mention a threshold for the correlation. How about in all the other cases, i.e. before the rogue vector filtering: Is there a minimum value of rho which needs to be exceeded or will also displacement vectors with a rho = 0.35 (as an example) make it into the product?
L218: "... during summer" --> I suggest to somewhere in this paragraph add information that surface melting reduces the identification of patterns in the observed TBs that are required for the tracking; one classical example applying to the Arctic is the loss of the radiometric difference between FYI and MYI. Without this additional information a reader might think this lower accuracy is merely due to melt pond coverage.
L224: I note that you switch from displacement (during winter) to velocity (during summer) here.
L234-236: I have two questions here:
- 1) You stated that during summer the CMCC algorithm is not suited well to derive ice motion (displacement vectors). But here you use maps of ice motion vectors from July derived nevertheless with the CMCC for the tuning. This needs to be explained better as it seems contradictionary.
- 2) You state that you use data of years 2002 through 2020. Did you perform the tuning individually for every year? Or did you average over data of all June, all July, and all August months of the years 2002-2020, respectively, to arrive at one set of tuning parameters per month?L240-242: I agree that during the earlier decade of the CDR the sea ice covered more area during summer and I welcome the thought to be able to apply the wind-driven model also in the early decade of the CDR. However, I am wondering whether the extrapolation isn't potentially causing artefacts that negative influence the tuning, and whether without this extrapolation the tuning wouldn't be as good as with. After all, all you need is a representative set of conditions relating sea ice displacement observed to ERA5 near-surface wind vectors and I would assume your AMSRX period is long enough for this purpose.
L243: "small radius" --> consider providing a value. How small?
L247 / Fig. 2: It might be a trick of my eyes but when I compare the map with the legend I would say that the turning angle is merely between -25 and -40 degrees to the left; I can hardly see any values around (just) -20 degrees.
L256 / Fig. 3: Also here I would be inclined to see mostly larger values than 20 degrees. Table 3 actually confirms my view - also the one noted in L247.
L256: "with generally thinner sea ice" --> I am wondering whether the overall lower SIC and with that better match between the free-drift assumption and the actual sea ice conditions doesn't play also a role here - perhaps even more than the thinner sea ice?
Figures 2 and 3:
- If possible I would have these figures to extend across the entire text width such that one does not need to zoom 200% or more to see what is in the figures in detail.
- Are these figures showing an individual year or are we looking at a July mean for 2002-2020?
- You might want to explain the white disc in the center of the maps shown in Figure 2.
- You might want to explain the white fringe around the coastlines.
- Please add units for the turning angle and the under-ice ocean current; I note in this context that you could harmonize the name between the title underneath the panel and the caption.L271/272: "we always compute two ... of the month" --> please try to give more details here. There are many ways how to interpret your writing:
1) You only compute two sea-ice motion fields at the very end / beginning of the month, i.e. June 30 vs. July 1, July 31 vs. Aug. 1
2) You compute two fields for every day of the summer months and then interpolate linearly between maps of June 1 and July 1, June 2 and July 2 and so forth.
3) Only within a certain period of time you blend the two motion fields, e.g. June 26 with July 1, June 27 with July 2, ..., June 30 with July 5.L273: "sea-ice mask" --> could you remind the reader where you take the sea ice mask from?
L280: "gapfill whole winter days ..." --> While I can understand that you blend shoulder month ice motions and solely use the wind-driven product during summer I have my difficulties to understand why you gapfill the satellite product with these model data during winter, a time when the free-drift assumption often does not hold. This seems to degrade the quality of the CDR during winter. Yes, you do provide a flag for these grid cells but I would assume that 90% (at least) of the users see a gapfilled product and don't care what the source is and whether they should potentially exclude these grid cells because these are not based on the satellite observations.
L297: "drift vector" --> just because it strikes me in this moment: I am not sure the reader fully understands why sometimes "drift" and sometime "motion" is used. I am wondering whether, for the sake of clarity, you at some point in the introduction specify what you mean by motion and drift, and that these two terms can be used interchangably. Ideally, though, you switch to "displacement" where you refer to a distance traveled by the sea ice (as is actually the variable in the product) and to "velocity" where you refer to the speed with which the sea ice displacement has taken place (as is the output of the wind-driven model). I could imagine that this could avoid confusion reading the paper. At least I needed to re-assure myself whether in a particular passage you were writing about the displacement or velocity when using drift or motion.
L300/301: "adjusted to ... Sect. 3.5.)" --> I did not find a sufficient description about how this adjustment is carried out; Section 3.5 is rather short as well.
L314 / Section 3.4.3: What I am missing in this section is how the wind-driven model ice motion vectors = velocities will be transferred to displacement vectors so that these can be merged with the satellite product.
L319-322: "In the spring month, ... nominal at the end." --> I am wondering whether it would make sense to share typical nominal values of the uncertainties with the reader here. It would be good to learn whether this ramping begins at 0.5 km, 5 km or even closer to the 10 km stated. I also note that in case of the wind-driven product the status - at this point of writing - is that these are sea ice velocities and hence a standard deviation of 10 km does not apply properly.
L326: "The wind-derived motion field ..." --> interesting to see the effort you carry out to have a smooth transition across the shoulder months from winter to summer and back to winter while here there seems to be no further effort to establish a smooth transition - at least not from your writing; perhaps this is in the ATBD?
L333/334: "the grid spacing between vectors is 75 km" --> After the abstract this is the first time the grid spacing of the product is mentioned. This oversight should be corrected at an appropriate place in the methods section.
L349/350: "that increase ... to 12 UTC" --> this seems to be the part you are refering to from L300/301 but I don't understand what you are doing here. The method is not clear quantitatively and it is also not clear what you mean by "where the drift period of the single-sensor product is far from 12 UTC to 12 UTC". Clarification required.
L362: Why this step? A buoy that reports no displacement over a certain time period seems to be stuck with the sea ice it sits on somewhere. Removing those records between t_1 and t_2 with t_1 = begin of being-stuck-period and t_2 = end of being-stuck-period complicates to generate a product with certain temporal resolution, doesn't it? It is like removing SIC values in a SIC maps where the values to not change from 100% (or 0%).
What happens if one wants to get the ice drift information for that particular buoy for a day that lies between t_1 and t_2? I assume that date might not be found then.L363/364: Does this work for buoys that have very variable drift speeds, e.g. being set out on moderately fast drifting sea ice in the Beaufort Sea end of summer, then being incorporated into perennial sea ice for 2 years with very sloooooooooow movement and then entering the transpolar drift stream being exported through Fram Strait? Would particularly the observations in the latter region mostly being discarded? Showing examples might help.
At the side: How do you adequately compute the standard deviation of the discplacement when you, as described in the previous step, remove positions where the buoy (safely) did not move?L386: Is this "40 km" triggered by the grid spacing of the product of 75 km? Presumably you want to have reference and product vector to begin in the same grid cell and 40 km is then your approximation of half the grid-cell width of 37.5 km parallel to the x- or y-direction, right?
Figure 4: I suggest to add in the caption that the start and stop times shown in the two left columns are given relative to 12 UTC? Otherwise I don't understand what the negative time denotes.
L448/449: I am suggesting that - in a future release of this CDR - you switch to 2-sigma uncertainty values to be in line with the GCOS requirements.
Figure 6:
- I note that the x-axis notation is showing "validation data" while earlier in the text when describing the validation you used the term "reference data". I suggest to stay consistent throughout the manuscript.
- Is there any pressing reason why the logarithmic scale shown changes with respect to the total range shown between the different panels? If this was on purose you could note in the caption that the ranges differ. If this was not on purpose you could conider harmonizing the ranges.
- There is this small notion "All Flags" in every panel. Would you mind to state in the caption and/or the text what you are refering to here?
- You could mention in the caption that these are full-mission results.
Note that these comments apply to the following figures of the similar kind.L483: "10-15 km resolution" --> Is it really the native resolution of the satellite imagery which counts here? Isn't it rather the 75 km grid spacing that is used?
L525/526: "One exception seems to be ..." --> What does this mean and/or what do you want to state with this sentence? One could ask the question why this is not confirmed by dY and/or what went wrong with dX here?
Figure 9: Consider enlarging the panels in this figure. It is almost impossible to see that MULTI-OI summer is identical to ERA5; you could used dashed lines for MULTI-OI so that ERA5 "shines" through. Where are the buoys?
L554: "the better of the SMMR period" --> What is this?
L569: "we compute drift vectors every six image pixels" --> you could emphasize that this applies to both x- and y-direction.
- Stupid question: Did you try to derive the same ice motion fields using a different set of center (?) 12.5 km grid cells, i.e. moved by 2 grid cells in x and 3 grid cells in y-direction?
- The (?) I put behind center was to remind me that with 75 KM grid spacing there is no real center pixel because of the even number of 12.5 km grid cells per 75 km grid cell. A problem?L616: "our wind-derived ... in the northern hemisphere" --> I am not that much convinced about this partitioning into two distinct periods. Actually 4 of the 5 largest (by magnitude) biases fall into the AMSRX period. Also, while during the first decade positive biases are almost missing they occurred more often during the AMSRX period with values up to 0.3 km. I am therefore not convinced that the discussion as written and illustrated.
L691/692: Again let me state that I am not that much convinced about emphasizing this first half / second half thing. Actually it is 11 years vs. 19 years, so the tuning is actually not just from one half of the 30 year CDR. I agree there are different biases but I don'T find the message is particularly clear. I would rather state the bias is quite variable and I am not sure whether all eventualities that might have caused this bias are adequately discussed. What do we know about potential trends in the ERA5 winds in the Arctic / Antarctic and/or how well (and with which data) has this parameter been evaluated in the polar regions?
Another suggestion I have with respect to future plans is whether a two step validation process wouldn't perhaps be more promising. I am thinking of using the buoy derived ice displacement to evaluate SAR-based ice displacement vectors to have some spatial distribution of the reference data to compare the CDR with in a second step.Typos / editoral comments:
L46: "mission" behind "AMSR-E" can be deleted.
L62: It is correct that buoy data enter the product of Tschudi et al. However, this does only apply to the Arctic, not the Antarctic. You could consider adding this to your text.
L78/79: Perhaps write a bit more about this data set? Are this gridded data? What is the temporal information?
L88-90: Again it would be helpful to know how this data is provided (as swaths or as daily gridded data) and also information about the time sould be given.
L100: "full-resolution" means what?
L103-106: "In addition, ... Derocher 2020)." --> Would it make sense to the reader to put this information right behind the sentence dealing with the Arctic buoys ending in L101? All additional data sources given here are from the Arctic and none are from the Antarctic - unless I am mistaken.
L111: You could consider adding a short notion why the Fram Strait is excluded from the main validation and/or point to the respective later section wherein you deal with this issue.
L121: "Theoterical" --> "Theoretical"
L214: "increase" --> "increased"?
L226: By "surface wind" you mean the 10-m wind?
L247/248: "older and thicker sea ice" --> In L258 you rightly connect thicker sea ice with "a larger impact of neglected internal stresses". I believe it would be a good idea to mention this here as well.
L262: Please check the Greec letter for the turning angle. Also, there are two sentences beginnign with "Table 3 ..." which could possibly be merged?
Table 3: Just a minor editoral remark: Please check how you want to (should) write the respective hemisphere ... Northern Hemisphere or northern hemisphere ... I guess there are rules but I am not aware of these at the moment.
L285: Consider again adding the information that the NSIDC product uses buoys in the Arctic only.
L292/293: "The mask over ..." --> It might make sense to move this sentence to behind the one ending in L290 with "86N)"?
L325: "sometimes to used" --> "sometimes to be used"
L335: "would never contains" --> "would never contain"
L389-391: Here you use two times the expression "validation", in form of "validation vector" and in form of "validation data". The reader would possibly appreciate to have this new term explained or, alternatively, replaced by what applies: "product" or "reference".
L402: "variables the" --> "variables of the"
L404: "product" --> "products"
L409: "he" --> "the"
L410: "We do to not report" --> please check.
L487: "that that" --> please check.
L497/498: "The wind-driven ..." --> Please check this sentence for plural "s": "products ... seems ... it extends ..."
Figure 7: What does the "(NONE)" in the first line of the text in every panel mean?
L598: "does ... results" --> "does ... result"
L653: "th" --> "the"
Citation: https://doi.org/10.5194/essd-2023-40-RC2 -
EC1: 'Comment on essd-2023-40', Ken Mankoff, 03 Jun 2023
Dear Authors,
Two reviewers both find benefits to this data product, but also substantial issues. I invite you to continue to the next round. At ESSD, this is responding to review comments without updating the manuscript. If responses are deemed reasonable, then revisions.
I note that CF compliance is mostly met but there are still two issues according to my compliance checker, and there are several missing "Highly Recommended" and "Recommended" fields for ACDD compliance. Please fix these.
Please change "1991 to December 2020" to "1991 through December 2020" (and similar phrasing elsewhere, e.g., "1979 *through* 2016" on L100) if the data includes December 2020. If it does not, then "1991 through November 2020".
I would also like to see the processing software workflow released that generated these products. When I download your software from Zenodo and try to run it, I get an error:
OSError: [Errno -90] NetCDF: file not found: b'https://thredds.met.no/thredds/dodsC/metusers/thomasl/SIDrift_CDR_v1pre/auxiliary_files/inv_params_osi455_nh_200301-202012_1day.nc'
Which is OK! I'm looking for *open* science, not *reproducible* science. That being said, the software only seems to be code for generating figures. Please share your processing software. The actual work. This would let anyone who has any methods questions not answered by your manuscript find out the answer for themselves (for example, how map projection errors are handled).
All figures: Bigger fonts!
Figure 6: Not necessary but I'm curious if you did both X and Y axes on +- log could the color scale then be linear? Would this presentation show anything different? Useful? Matplotlib has a "symlog" function for this type of display.
Have you considered and propagated projection errors from your EASE2 grid?
I don't think a recommended citation format is appropriate. Please remove. That's not your decision, that's the decision of the place where the citation is used.
Beyond these issues I raise, please carefully consider comments from reviewers. In particular, I too am curious about the motion vs. displacement issue raised by R2. If you prefer displacement over motion for some reason, would it be possible to provide a 'derived' motion product? I am concerned about the complications and user-error issues raised by R2.
Citation: https://doi.org/10.5194/essd-2023-40-EC1 -
AC1: 'Comment on essd-2023-40', Thomas Lavergne, 28 Jun 2023
We thank the two reviewers and the editor for their comments and suggestions.
Please find attached our answers to RC1, RC2, and EC.
-
EC2: 'Reply on AC1', Ken Mankoff, 08 Jul 2023
Dear Authors,
In general I appreciate your response to reviews, except your response to RC1 Comment 4 where you decline to validate your product against existing products. We discuss this already via email. I thought I made it clear that this is expected. Your reference to non-ESSD papers that do not provide a validation is precisely the reason ESSD exists - so that this validation is done when data is released.
I appreciate your concern that you may be biased to favor your product. That's always a concern, but I explicitly advised you against this already, and that is why your validation would be peer-reviewed.
Other comments:
I now better understand your uncertainty and flags based on your response to R2 (top of p. 9 of your response; also p. 11). From this I wonder about your uncert_dX_and_dY value. Is this variable is space and time, considering higher uncertainties when extrapolation occurs, vs. interpolation, vs. dense observations?
Regarding CF compliance, there is documentation for you to generate names that may not exist in the standard vocabulary: http://cfconventions.org/Data/cf-standard-names/docs/guidelines.html I note that if I drag-and-drop your product into QGIS it appears to work well, but there are minor issues: It reports "Unknown CRS". I recognize you don't want to update metadata but there are some things that can be improved. "Conventions does not contain 'ACDD-1.3'" can be fixed with, I believe, a semi-colon between the "CF" and "ACDD" strings in that field. For 'coverage_content_type' I believe one of "image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate" might be imperfect but more useful than an empty field. Are you sure that "uncert_dX_and_dY" and "qualityInformation" does not fit? If not, then what exactly is "uncert_dX_and_dY"? While you're at it, it should be easy to improve the other recommended issues.
Regarding my comment about propagating projection errors - this may not be an issue if all your inputs and outputs are on the same grid. I was referring to the fact that, for example, in Greenland EPSG:3413 has 8 % errors with respect to the real world, so if you take 1 m in EPSG:3413 and use that value on another projection, it may no longer be 1 m.
Please amend your response to include validation plans against existing products. I recognize this may be a significant effort. I believe it will be appreciated by the reviewers and the community.
Regards,
Ken Mankoff
Citation: https://doi.org/10.5194/essd-2023-40-EC2
-
EC2: 'Reply on AC1', Ken Mankoff, 08 Jul 2023