the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Polar maps of C-band backscatter parameters from the Advanced Scatterometer
Jessica Cartwright
Alexander D. Fraser
Richard Porter-Smith
Download
- Final revised paper (published on 04 Feb 2022)
- Preprint (discussion started on 31 Mar 2021)
Interactive discussion
Status: closed
-
RC1: 'Comment on essd-2021-92', Anonymous Referee #1, 19 May 2021
The authors present a dataset that is a derivation of existing and freely available ASCAT remote sensing data. Its main purpose is to save others from having to go through extensive processing in order to extract parameters from the raw data, using published methods (by the authors). These parameters relate more directly to physical information and can thus be analysed directly. As the authors write themselves, other such derivates from the same raw ASCAT remote sensing data already exist, however with different focus and/or using different and less advanced/extensive methods.
The article has a good structure and flow. It provides a well-balanced introductionary part which covers sensors/physics/products/applications and thus provides useful background also for users new to such data. The description of the methods and in particular the dataset itself are rather short. Given that this is not the only ASCAT derivative that exists out there, this part of the data description would deserve more weight.General/major omments:
- Novelty: Given there are existing derived ASCAT products, the new dataset could be more clearly distinguished from existing ones (section 2.3).- Verification: The article should include data quality figures (statistics, error assessment) and a comparison of the three generated products. Comparing the three timescales using a concrete example/application would help the user to choose and know the limits of the product they chose compared to the other products. I am also missing some kind of a validation/comparison to comparable existing products that authors themselves mention in section 2.3.
- Verification/applications: The applications section is very shallow. Users who are not familiar with ASCAT data don't get any help here - I would have expected one or several case studies with results/maps for different uses, e.g. those you mention in section 2.1 - glacier surface mass balance, sea ice, ice bergs... Currently, applications are only mentioned in a theoretical way without any concrete examples. It would be much more useful for the reader to have an actual application result/example, and ideally a comparison of some of the mentioned "such studies" (P8,L217) with the parameters provided within the three new datasets.
- The temporal coverage of the dataset (various starting dates, until 2019 only) is not sufficiently described in the article, in particular it is not mentioned that the datasets are available through 2019 only. This is especially important because this means that the flagship 1-day-dataset only covers a few months in 2019. Would it be possible to include 2020?
- Projection information should be available in the dataset/metadata: an unambiguous CRS/EPSG string/code is not provided in the article, nor in the dataset DOI page or the NetCDF files themselves. Not all users will be familiar with the polar stereographic projection and unclear attribute names (both X/Y and latitude/longitude are used in the NetCDF files) and ambiguous projection information means users might struggle to read the data or use it together with their own data.
Minor/detailed comments, sections 1&2
----------------------------
P2,L42: double brackets in citation; also at P4,L111
P3,L64: typo, missing verb
P3,L74: complicated phrasing. Note that C-band penetration varies considerably and may be only a few meters or even more than 20m even for dry snow and clean glacier ice. Consider: For dry snow and glacial ice, C-band penetration depths can reach 20m or even more
P4,L103-104: wrong dash (use --- instead - also in P4,L122 and many other places)
Here also in the wrong place, disturbing the reading flow. Use commas/brackets for both examples of sensor types.
P5,L124: what are "simple anisotropy parametrisations" (why aren't these sufficient)?
P5,L129: The distinction of your dataset to a) and c) is obvious, but why b) is not good enough is not immediately clear and the distinction deserves more explanation. Also, the term "balance" isn't very clear in the light of a-c). The paragraph about your own dataset might fit better in the end of this section?
P5,L135f: Within the context, it is not entirely clear whether these datasets (CERSAT, NASA SCP) are somehow part of your product or a competing/complementary product. Rather call them "products" to clarify (maybe also refer to b) in the list above?)
P5,L143: it is a little unclear what you mean with this sentence. You mean that OSI SAF provides some of the same information as your dataset, but yours is better (in what sense?)
P5,L45: temporal or spatial resolution-enhanced? Best to be specific as both types of resolution are mentioned throughout the text.section 3
---------
P6, L157: misleading, as this sounds like full coverage of the entire polar areas every 50 minutes. Please clarify.
Table 1: The star * footnote is a little confusing (and it is questionable whether the table caption is the right place for it, given some of it are technical/processing choices you made). March or July 2007...? Also, the following explanation for MetOp-B doesn't fit here (would need another footnote). Suggestion: Add another column (or replace "Data Available") with "Data Used".
P6, L175: typo (it)
P6, L169: Figure order? Nr. 5 is first...? Would these figures be exactly the same (mirrored) for the Northern hemisphere, and MetOp-A and -C, respectively? Could be worthwile to add this to the caption.section 4
---------
P7, L184ff: It is unclear/misleading what you mean with "version 3" - table 3 on the website you refer to? Table 3 corresponds to the "Northern Hemisphere Projection Based on WGS 1984", defined by the EPSG code 3413. Rewrite, and please provide the (unique) EPSG codes - assuming you used the projection described in table 4 on the NSIDC page for the southern hemisphere? --- After analysing the datasets, I suggest adding here that the dataset also provides lat/lon values for each pixel.
P7, L189: It might be good to remind the reader here how your approach differs from (and is much better than?) the one of existing products (in section 2.3).
P7, L208: "observations" sounds like an independent dataset, do you mean your own raw data? Please clarify. In particular for users not so familiar with ASCAR data / anisotropy, the residual parameter ought to be explained more. "Residual" is commonly interpreted a quality measure, and in this context this also seems correspond with the occurence/percentage of invalid pixels - all of this is easy to confuse.
P7, L211: Consider changing to something like this: "In addition to the 9 parameters, latitude/longitude coordinates and a data quality flag parameter are provided for each grid location..." to clarify that the data flag is an additional layer, and different to the residual parameter. It would then be nice to see a plot of the quality flag mask as well.
P7,L211ff: some statistics would be nice here? What is the percentage of invalid pixels of the different products (e.g. per map/year, over land/sea, within the polar circle...)? How do the 3 timescale products differ, in particular for the years where you provide all products?
P7,L213: typo (use)
P7,L214: What about the northern hemisphere? Fig. 6 only covers the south. Some simple statistics like the nr of invalid pixels over land (Antarctica)sections 5&6
---------
This section is more a theoretical comparison of the new product with existing ones, plus some potential future developments. No actual applications...?
P8, L223: Please clarify: "These data" = your own pruducts or the NOAA/CERSAT? The description of other products would fit better in section 2.3.
P8,L226: Table 1 suggests 2006 to present (2021) = 15-16 years? Not 12 years as stated here.
P8, L227ff: This is an outlook rather than an application. Move to conclusions? Missing timeframe - currently, it seems that these satellites will be launched ca. 2024 (https://www.eumetsat.int/metop-sg)? As it is written now, the 2012 reference is misleading for readers who are not familiar with the upcoming MetOp-SG missions.
P8,L237: 2021 seems to be outdated (see link above)?Figures 1-4: A description of what can be seen in these datasets (applications) would be desirable, to help the reader see the potential. What about the data quality flag layer?
For comparison of the three different products, a side-by-side view of the same parameter and area might be more useful. In turn, in addition to a few such comparisons, it should be sufficient to show one complete set of parameters for one product rather than four full-size figures with little different information content.
References: please include DOIs to facilitate finding the references.datasets
--------
Access:- From the dataset doi page, it is possible to a) download the entire dataset, which requires providing an email address, or b) view the dataset contents - where parts of the dataset can be downloaded without providing an email address. Is this difference intentional?
- Clicking on "view dataset contents" leads to a folder structure containing subfolders. This is well organised, but a link/README file linking back to the doi page and/or how to cite the data might be useful to add to ensure correct referencing, especially given that the dataset DOI is not included in the attributes of the individual .nc files (consider changing this?).
- I experienced that downloading the data was extremely slow (several hours for 2-3 GB despite my very fast internet connection, several attempts). Was this a temporary problem of the data server, or is it always the case? Limited download capacity will prevent users from using this data.
Data content:- Attributes: I got confused by the mix of dimensions X/Y and the variables "latitude" and "longitude" in the NetCDF dataset. While not an expert on NetCDF standards, I found it rather misleading to use a polar stereographic grid, but not defining the X/Y dimensions (they are in km), yet link to that polar stereographic grid in the latitude/longitude variables (which are in degrees) description. To avoid confusion, it should be made clearer to the user that there are two coordinate systems in the same dataset, sort of. Also, note the typo in the description field of the latitude/longitude variables attributes (steTreographic).
- The definition of the projection (dataset attributes) is insufficient - the provided link to the NSIDC page describes several projections (see comment above) - better to provide the projection/EPSG code directly. (The NH/SH projections are not stated on the dataset DOI page, so no help to find there.) It seems best practice would be to define a grid mapping variable, as described on this paragraph on coordinate reference system (CRS) standards for NetCDF climate and forecast data: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#grid-mappings-and-projections
- There is a ASCAT2day_NH_2012.nc (and SH) dataset despite the article stating that 2-day-processing only started in 2013...? I checked some parameters and it seems the entire NH file only contains fill values (-999)?
Citation: https://doi.org/10.5194/essd-2021-92-RC1 -
AC1: 'Reply on RC1', Jessica Cartwright, 06 Oct 2021
Polar maps of C-band backscatter parameters from the Advanced Scatterometer
Jessica Cartwright, Alexander D. Fraser and Richard Porter-Smith
Response to Anonymous Referee #1
The authors would like to thank anonymous referee #1 for their comments on the submitted manuscript and believe that by addressing them as below, the study has been improved and is now suitable for publication in Earth System Science Data.
Our response consists of the reviewer’s comments in bold, our responses in regular print and additions or changes to the text in italics. Dueto the size of the figures, they could not be inserted into the interactive comments, and can be found in the full supplement attached.The authors present a dataset that is a derivation of existing and freely available ASCAT remote sensing data. Its main purpose is to save others from having to go through extensive processing in order to extract parameters from the raw data, using published methods (by the authors). These parameters relate more directly to physical information and can thus be analysed directly. As the authors write themselves, other such derivates from the same raw ASCAT remote sensing data already exist, however with different focus and/or using different and less advanced/extensive methods.
The article has a good structure and flow. It provides a well-balanced introductionary part which covers sensors/physics/products/applications and thus provides useful background also for users new to such data. The description of the methods and in particular the dataset itself are rather short. Given that this is not the only ASCAT derivative that exists out there, this part of the data description would deserve more weight.
General/major comments:
- Novelty: Given there are existing derived ASCAT products, the new dataset could be more clearly distinguished from existing ones (section 2.3).
A full investigation was undertaken into the differences between the dataset presented and the NASA SCP product. These cannot be added in their entirety into the paper in order to avoid loss of focus on the dataset at hand. An abridged version will be added, as detailed below. We provide a longer version here for the purpose of full response.
The comparisons represent a one-year average of data, in this case performed spatially over 2017 for the NASA SCP product from the Brigham Young University. Due to the limited parameterisation in the NASA product, this has been performed for A and B parameters only, with both datasets resampled to the same grid. The two difference maps can be seen to be negatively correlated, with positive differences in A occurring in negative difference regions of B. These patterns are not correlated with maps seen in Fraser et al. (2014), and so likely represent a complex mispartitioning of backscatter in the SCP product based on viewing geometry. In particular, we can see in the maps, the high diversity zone and discontinuity are clearly visible in the SCP product B parameterisation.
[Figure 1: Comparison of NASA SCP product produced by BYU Remote Sensing facility and the dataset presented in this paper. Datasets are an average of 2017. The top row corresponds to the product presented here, Cartwright et al., 2021, the bottom row shows the NASA SCP product and the middle row the difference between the two. The left and right column are the A and B parameters respectively.]
Figure 1 shows a direct comparison of the datasets averaged over the entirety of 2017, with both datasets gridded to the same spatial resolution. A and B parameter difference maps shown in Figure 1 c) and d), respectively, indicate that the two products partition backscatter differently between these two parameters, with regions of positive A parameter difference coinciding with negative B parameter difference, and vice versa. Figure 1 f) also shows the high to low azimuthal diversity zones clearly as a discontinuity in the B parameter in the SCP product, indicating that the more sophisticated parameterisation presented here handles this viewing geometry regime change more seamlessly.
- Verification: The article should include data quality figures (statistics, error assessment) and a comparison of the three generated products. Comparing the three timescales using a concrete example/application would help the user to choose and know the limits of the product they chose compared to the other products. I am also missing some kind of a validation/comparison to comparable existing products that authors themselves mention in section 2.3.
The three different products differ both in their temporal extent and the resolution per map. It can be seen as per the comparisons below that the shorter time steps are a little noisier in their appearance. This has an advantage in regions that change, allowing ice melt to be appropriately localised, temporally. As such some of the apparent noise in the signal may be signal, for example, in Figure 2 below at around DOY 215, where the 5day product has missed a peak in backscatter caught by the other two. The temporal extent of the product will also be a large factor in the choice of product, with the longer extent of the 5-day product necessary to see changes on decadal scales or full comparisons with longer products.
Addition, Section 5, line 226: The comparison of the three time steps seen in Figure 2 reveals that the longer averaging period of the 5-day product limits the sensitivity to shorter scale changes. The 5-day dataset therefore creates a less noisy dataset for point comparisons, and allows full use of the decadal timescale of the ASCAT instruments.
[Figure 2: Comparison of the three products in 2019 at a point on the Antarctic continent]
- Verification/applications: The applications section is very shallow. Users who are not familiar with ASCAT data don't get any help here - I would have expected one or several case studies with results/maps for different uses, e.g. those you mention in section 2.1 - glacier surface mass balance, sea ice, ice bergs... Currently, applications are only mentioned in a theoretical way without any concrete examples. It would be much more useful for the reader to have an actual application result/example, and ideally a comparison of some of the mentioned "such studies" (P8,L217) with the parameters provided within the three new datasets.
The below text and figures have been added to the application of these data for the same purposes as the comparable datasets, with more versatility and accuracy due to the more comprehensive parameterisation.
Figure 3 shows an application of this dataset in the form of an accurate ice edge product, comparable with that of OSI SAF (OSI SAF, 2019). The algorithm presented here emulates that of OSI SAF by assuming the sea ice azimuthal anisotropy is low in comparison to that of open water. Figure 3a) shows a two-dimensional histogram of parameter fit residual (y-axis) vs “maximum deviation” (x-axis). The maximum deviation metric is calculated as the maximum absolute deviation, in dB, of sigma0 as a function of azimuth, when using the 6 Fourier parameters presented in this dataset. Sea ice pixels have a low residual and low maximum deviation while ocean pixels have high residual and maximum deviation. Partitioning using one parameter alone cannot separate these classes, however combining these two parameters allows effective separation of the two surface types (here separated by the red line in Figure 3a). Figure 3b) shows the resulting ice edge (red line), as well as the OSI SAF ice edge (dotted orange line). Polynyas off Cape Darnley and the Ross Ice Shelf are visible along with a gap in the ice off Prydz bay, that is also visible in concentration data from the day (not shown). Further elucidation of this application is outside of the scope of this paper.
[Figure 3: Application of dataset to surface type (sea ice vs open water) delineation. date shown is DOY 271-275, 2019 (28th September– 2nd October 2019. a) simple thresholding algorithm uses low azimuthal anisotropy over sea ice in comparison to high azimuthal anisotropy of sea water to classify the two surfaces, through parameters in the dataset. b) ‘A’ parameter map overplotted with ice edge from this dataset (red, solid) and that of OSISAF ice edge product (orange, dotted).]
- The temporal coverage of the dataset (various starting dates, until 2019 only) is not sufficiently described in the article, in particular it is not mentioned that the datasets are available through 2019 only. This is especially important because this means that the flagship 1-day-dataset only covers a few months in 2019. Would it be possible to include 2020?
The authors are very pleased to include the 2020 data in the products for release, as they have now finished processing. The extended dataset will now include all three time steps through 2020. The first half of 2021 data has also been requested from EUMETSAT in order to commence the next step of the processing as well.
The temporal extent of the datasets has also been clarified in the caption of Table 1, with the addition of a Data Used column, as suggested by yourself.
Addition as below:
[Table1: Launch dates of MetOp-A, MetOp-B and MetOp-C and data availability from each]
- Projection information should be available in the dataset/metadata: an unambiguous CRS/EPSG string/code is not provided in the article, nor in the dataset DOI page or the NetCDF files themselves. Not all users will be familiar with the polar stereographic projection and unclear attribute names (both X/Y and latitude/longitude are used in the NetCDF files) and ambiguous projection information means users might struggle to read the data or use it together with their own data.
The decision to include the latitude and longitude grids in addition to the polar stereographic description was made originally to facilitate the use of the data by people who may be unfamiliar with the polar stereographic grid definition and may not find co-ordinates in metres so easy to compare to their own datasets. This is not uncommon in polar datasets.
The authors acknowledge that this is not strictly in line with conventions and have gladly added the dimensions of x and y, the definition of the regular grid along each access in metres. A grid mapping object has also been added to the attributes of the parameters, with full definition of the projection information and PROJ4 string:
New variables:
projection_x_coordinate– description including the EPSG of the grid and the link to the NSIDC website. Units and a grid mapping attribute containing details of the grid – straight vertical longitude from pole, latitude of projection origin, standard parallel, false easting, false northing and Projection definition.
projection_y_coordinate– description including the EPSG of the grid and the link to the NSIDC website. Units and a grid mapping attribute containing details of the grid – straight vertical longitude from pole, latitude of projection origin, standard parallel, false easting, false northing and Projection definition.
New attributes:
grid_mapping attributesadded to latitude and longitude variables
Minor/detailed comments, sections 1&2
----------------------------
P2,L42: double brackets in citation; also at P4,L111
This has been amended.
P3,L64: typo, missing verb
Addition of “is” on line 64
P3,L74: complicated phrasing. Note that C-band penetration varies considerably and may be only a few meters or even more than 20m even for dry snow and clean glacier ice. Consider: For dry snow and glacial ice, C-band penetration depths can reach 20m or even more
Yes this is a much better way of phrasing it, this has been corrected.
P4,L103-104: wrong dash (use --- instead - also in P4,L122 and many other places)
Dashes throughout the manuscript have been reviewed and replaced with en-dashes and em-dashes as appropriate.
Here also in the wrong place, disturbing the reading flow. Use commas/brackets for both examples of sensor types.
This dash has been replaced with a comma, such that the em dash separates the initial statement from the examples of the scatterometer types, and the sensor examples of the types of scatterometers are given with commas and brackets.
P5,L124: what are "simple anisotropy parametrisations" (why aren't these sufficient)?
Simple anisotropy parameterisations used by the products given here assume that the backscatter is linearly related to the incidence angle only, and use data from different azimuth angles without accounting for the azimuth anisotropy. This is not sufficient for the normalisation of the backscatter over many surfaces (e.g., those which display aligned structure, over inclined surfaces, etc), and results in a backscatter parameter (A) that is still affected by the azimuth angle of the individual measurements and therefore the roughness of the surface. The way in which the backscatter changes with viewing angle, when appropriately parameterised can also yield additional information on the characteristics on the surface/subsurface. These additional parameters we present in this dataset can be used in this way (i.e., for retrieval of additional surface/subsurface physical parameters).
P5,L129: The distinction of your dataset to a) and c) is obvious, but why b) is not good enough is not immediately clear and the distinction deserves more explanation. Also, the term "balance" isn't very clear in the light of a-c). The paragraph about your own dataset might fit better in the end of this section?
Differences between these datasets and those in b) are detailed above (Figure 1), and the addition of this to the manuscript should clarify this point.
P5,L135f: Within the context, it is not entirely clear whether these datasets (CERSAT, NASA SCP) are somehow part of your product or a competing/complementary product. Rather call them "products" to clarify (maybe also refer to b) in the list above?)
References to these have been adjusted to refer to them as “products” in order to clarify that these are effectively competing products, using different assumptions to calculate the same parameters.
P5,L143: it is a little unclear what you mean with this sentence. You mean that OSI SAF provides some of the same information as your dataset, but yours is better (in what sense?)
The comparison with the OSI SAF product shows that the parameters in the dataset are already widely used, with demonstrated applications in the detection and classification of ice surfaces. The provision of the lower-level parameters here enables the application of these same techniques for different surfaces and characteristics than those pre-classified by OSI SAF in the Level 2 products.
Added: Similar parameters to those used by OSI SAF for the creation of these Level 2 products may be extracted from the more comprehensive parameterisation presented here, demonstrating their use in the classification of ice surfaces and allowing these same techniques to be applied over a wider variety of applications in the cryosphere.
P5,L45: temporal or spatial resolution-enhanced? Best to be specific as both types of resolution are mentioned throughout the text.
Thanks for pointing this out - the ambiguity has been clarified.
section 3
---------
P6, L157: misleading, as this sounds like full coverage of the entire polar areas every 50 minutes. Please clarify.
Wording adjusted to: Thus, with this pair alone, the orbital period is effectively reduced to 50 minutes.
Table 1: The star * footnote is a little confusing (and it is questionable whether the table caption is the right place for it, given some of it are technical/processing choices you made). March or July 2007...? Also, the following explanation for MetOp-B doesn't fit here (would need another footnote). Suggestion: Add another column (or replace "Data Available") with "Data Used".
As above, this has been amended as suggested.
Addition as below:
Table2: Launch dates of MetOp-A, MetOp-B and MetOp-C and data availability from each
P6, L175: typo (it)
Thank you, this has been corrected.
P6, L169: Figure order? Nr. 5 is first...? Would these figures be exactly the same (mirrored) for the Northern hemisphere, and MetOp-A and -C, respectively? Could be worthwile to add this to the caption.
This has been altered so that figure references have been given in the correct order.
section 4
---------
P7, L184ff: It is unclear/misleading what you mean with "version 3" - table 3 on the website you refer to? Table 3 corresponds to the "Northern Hemisphere Projection Based on WGS 1984", defined by the EPSG code 3413. Rewrite, and please provide the (unique) EPSG codes - assuming you used the projection described in table 4 on the NSIDC page for the southern hemisphere? --- After analysing the datasets, I suggest adding here that the dataset also provides lat/lon values for each pixel.
You are correct – it looks like the NSIDC have recently changed their gridding and naming thereof. This oversight has been clarified within the text, with the addition of the below. The inclusion of the EPSG code and other such gridding information in the files themselves and the manuscript should hopefully add clarity to the projections used, such that external web pages need not be relied upon.
The ASCAT swath data are then resampled onto the NSIDC polar stereographic 12.5 km grid, EPSG 3411 and 3412 for Northern and Southern Hemisphere respectively.
P7, L189: It might be good to remind the reader here how your approach differs from (and is much better than?) the one of existing products (in section 2.3).
Thank you, good idea. Added as below:
This is in contrast to other products mentioned above, modelling backscatter solely as a function of incidence angle and presents the relationship…
P7, L208: "observations" sounds like an independent dataset, do you mean your own raw data? Please clarify. In particular for users not so familiar with ASCAR data / anisotropy, the residual parameter ought to be explained more. "Residual" is commonly interpreted a quality measure, and in this context this also seems correspond with the occurence/percentage of invalid pixels - all of this is easy to confuse.
The residual parameter here represents the difference between the per-pixel fit using the backscatter and geometry, and the backscatter received in the raw data. As our model is optimised for application over ice surfaces, a high residual can indicate properties of the surface and provide information on the appropriateness of the model for that particular pixel. For example, over ocean surfaces the residual will be high as the model does not capture the relationship between backscatter and geometry under those conditions.
P7, L211: Consider changing to something like this: "In addition to the 9 parameters, latitude/longitude coordinates and a data quality flag parameter are provided for each grid location..." to clarify that the data flag is an additional layer, and different to the residual parameter. It would then be nice to see a plot of the quality flag mask as well.
Thank you, this suggestion has been added.
P7,L211ff: some statistics would be nice here? What is the percentage of invalid pixels of the different products (e.g. per map/year, over land/sea, within the polar circle...)? How do the 3 timescale products differ, in particular for the years where you provide all products?
The table below table breaks down the average percentage of invalid pixels per map in the three time zones during their overlapping period in 2019.
[Table 3: Percentage of invalid pixels per map over both hemispheres and across all three time steps for overlapping period in 2019.]
Due to the drifting orbit of Metop-A, a more in-depth study is not warranted, as these numbers are expected to change.
P7,L213: typo (use)
Thank you, this has been amended.
P7,L214: What about the northern hemisphere? Fig. 6 only covers the south. Some simple statistics like the nr of invalid pixels over land (Antarctica)
Due to the geometry of the orbits, the rate of invalid pixels in the Southern hemisphere and Northern hemisphere is expected to be very similar, as demonstrated by figures below, showing the percentage of flagged pixels binned by latitude. A sentence has been added to acknowledge this similarity.
[Figure 4: Rate of invalid pixels binned by latitude in the a) Antarctic and b) Arctic.]
sections 5&6
---------
This section is more a theoretical comparison of the new product with existing ones, plus some potential future developments. No actual applications...?
As above, a section has been added showing the application of the parameters in the dataset to the purpose of sea ice edge detection.
P8, L223: Please clarify: "These data" = your own pruducts or the NOAA/CERSAT? The description of other products would fit better in section 2.3.
This has been clarified by referring directly to the incidence angle only parameterisations.
P8,L226: Table 1 suggests 2006 to present (2021) = 15-16 years? Not 12 years as stated here.
There is always a gap between launch and first data availability, as such there is no data available from Metop-A until 2007. The caption restates that the data before 2008 is not used from Metop-A due to poor calibration. The ASCAT data is available to present, however as it is presented in yearly files, the processed parameters are subject to yearly updates. Unfortunately at time of submission the 2020 data was still processing and as such, 2019 was the last year of prepared data (2008 2019 gives us the 12 years of data provided in this dataset). As the 2020 data has now been processed and will be added to the dataset, this will now be 13 years of data.
P8, L227ff: This is an outlook rather than an application. Move to conclusions? Missing timeframe - currently, it seems that these satellites will be launched ca. 2024 (https://www.eumetsat.int/metop-sg)? As it is written now, the 2012 reference is misleading for readers who are not familiar with the upcoming MetOp-SG missions.
The expected launch date has been added to clarify the timescale for these.
P8,L237: 2021 seems to be outdated (see link above)?
Thank you for spotting this, this has been changed in the manuscript.
Figures 1-4: A description of what can be seen in these datasets (applications) would be desirable, to help the reader see the potential. What about the data quality flag layer?
Addition of a line in section 5 pointing out the different changes seen across the different regions as below:
The data presented here are suitable for a wide array of cryosphere studies, including sea and glacial ice as is visible in Figure 1 and Figure 2, with changes seen across the sea ice pack and in the varying geographic and climatological zones of the polar regions. These uses are shown by previous applications of the ASCAT sigma0 data.
For comparison of the three different products, a side-by-side view of the same parameter and area might be more useful. In turn, in addition to a few such comparisons, it should be sufficient to show one complete set of parameters for one product rather than four full-size figures with little different information content.
The 5-day data have been removed, showing only the 2-day resolution parameterisations in each hemisphere as a mid-point for the reader to assess the temporal resolution necessary for their application.
References: please include DOIs to facilitate finding the references.
The reference format has been changed to include the DOI. Additionally the references have been reviewed to ensure all references have DOIs where possible.
datasets
--------
Access:
- From the dataset doi page, it is possible to a) download the entire dataset, which requires providing an email address, or b) view the dataset contents - where parts of the dataset can be downloaded without providing an email address. Is this difference intentional?
In order to satisfy the open data specifications of ESSD, the data must be free to download anonymously. The addition of the ability to download it without the entry of the email address is to facilitate this and is a compromise that was reached with the Data Centre.
- Clicking on "view dataset contents" leads to a folder structure containing subfolders. This is well organised, but a link/README file linking back to the doi page and/or how to cite the data might be useful to add to ensure correct referencing, especially given that the dataset DOI is not included in the attributes of the individual .nc files (consider changing this?).
Unfortunately it is not possible for the authors to make changes to the Data Centre website, however the suggestions are good ones and will be passed on to those with such capabilities.
- I experienced that downloading the data was extremely slow (several hours for 2-3 GB despite my very fast internet connection, several attempts). Was this a temporary problem of the data server, or is it always the case? Limited download capacity will prevent users from using this data.
We have asked the Data Centre to look into this to find out if we could diagnose the issue and received the following response:
“I setup an EC2 instance in the London region and downloaded a scatterometer based dataset via our S3 service using the MinIO client and was able to download the full 2.46GB within 13m20s at a rate of 3.15 MiB/s as seen below. While it isn’t as fast as we can send the data out from our services (we have a 1Gbps fibre connection at the AAD provided via AARNeT) it isn’t unreasonably slow for the other side of the world - I also tested via Paris and got a slightly slower speed at 2.85MiB/s and locally here in Hobart on 4/5G networks which were able to download within a couple of minutes etc.”
Unfortunately, therefore it is hard to diagnose the root of the problem in this case, however if it is a persistent issue then the authors would be happy to prompt further investigation.
Data content:
- Attributes: I got confused by the mix of dimensions X/Y and the variables "latitude" and "longitude" in the NetCDF dataset. While not an expert on NetCDF standards, I found it rather misleading to use a polar stereographic grid, but not defining the X/Y dimensions (they are in km), yet link to that polar stereographic grid in the latitude/longitude variables (which are in degrees) description. To avoid confusion, it should be made clearer to the user that there are two coordinate systems in the same dataset, sort of. Also, note the typo in the description field of the latitude/longitude variables attributes (steTreographic).
As noted above, this is a great suggestion and has been acted upon. The decision to include the latitude and longitude grids in addition to the polar stereographic description was made originally to facilitate the use of the data by people who may be unfamiliar with the polar stereographic grid definition and may not find co-ordinates in metres so easy to compare to their own datasets (likely in lat/lon). This is not uncommon in polar datasets, with many giving their data on lat/lon co-ordinates for polar stereographic-defined grids.
The authors have therefore gladly added the dimensions of x and y and the definition of the regular grid along each access in metres. A grid mapping object has also been added to the attributes of the parameters, with full definition of the projection information and PROJ4 string: The typo has been corrected.
New variables:
projection_x_coordinate– description including the EPSG of the grid and the link to the NSIDC website. Units and a grid mapping attribute containing details of the grid – straight vertical longitude from pole, latitude of projection origin, standard parallel, false easting, false northing and Projection definition.
projection_y_coordinate– description including the EPSG of the grid and the link to the NSIDC website. Units and a grid mapping attribute containing details of the grid – straight vertical longitude from pole, latitude of projection origin, standard parallel, false easting, false northing and Projection definition.
New attributes:
grid_mapping attributesadded to latitude and longitude variables
- The definition of the projection (dataset attributes) is insufficient - the provided link to the NSIDC page describes several projections (see comment above) - better to provide the projection/EPSG code directly. (The NH/SH projections are not stated on the dataset DOI page, so no help to find there.) It seems best practice would be to define a grid mapping variable, as described on this paragraph on coordinate reference system (CRS) standards for NetCDF climate and forecast data: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#grid-mappings-and-projections
As noted above:
You are correct – it looks like the NSIDC have recently changed their gridding and naming thereof. This oversight has been clarified within the text, with the addition of the below. The inclusion of the EPSG code and other such gridding information in the files themselves and the manuscript should hopefully add clarity to the projections used, such that external web pages need not be relied upon.
- There is a ASCAT2day_NH_2012.nc (and SH) dataset despite the article stating that 2-day-processing only started in 2013...? I checked some parameters and it seems the entire NH file only contains fill values (-999)?
Thank you for pointing this out, it looks like there were some wires crossed with the 2012 dataset. These will now be removed as the decision was taken not to include the 2day dataset for 2012 (with Metop-B commencing data production in December of that year). As such there would be very few timesteps in the 2day data files.
Fraser, A. D., Young, N. W., and Adams, N.: Comparison of Microwave Backscatter Anisotropy Parameterizations of the Antarctic Ice Sheet Using ASCAT, IEEE Transactions on Geoscience and Remote Sensing, 52, 1583-1595, 10.1109/tgrs.2013.2252621, 2014.
OSI SAF: Sea ice edge product of the EUMETSAT Ocean and Sea Ice Satellite Application Facility, 2019.
-
AC1: 'Reply on RC1', Jessica Cartwright, 06 Oct 2021
-
RC2: 'Comment on essd-2021-92', Anonymous Referee #2, 17 Aug 2021
This paper presents a new data set with the backscatter anisotropy parameter mapped with fine resolution for cryospheric studies. The uniqueness of the set relies on the use of multiple sources. The paper is technically sound and well written. I only have a couple of minor comments
1) Include a table summarizing relevant instrument parameters for the data sources.
2) Further discussion on Figure 6 and implications of increasing number of invalid pixels as samples move toward -40 deg would be welcomed.
Citation: https://doi.org/10.5194/essd-2021-92-RC2 -
AC2: 'Reply on RC2', Jessica Cartwright, 06 Oct 2021
Polar maps of C-band backscatter parameters from the Advanced Scatterometer
Jessica Cartwright, Alexander D. Fraser and Richard Porter-Smith
Response to Anonymous Referee #2
The authors would like to thank anonymous referee #2 for their comments on the submitted manuscript and believe that by addressing them as below, the study has been improved and is now suitable for publication in Earth System Science Data.
Our response consists of the reviewer’s comments in bold, our responses in regular print and additions or changes to the text in italics. Tables and Figures can be seen in full in the supplement.
This paper presents a new data set with the backscatter anisotropy parameter mapped with fine resolution for cryospheric studies. The uniqueness of the set relies on the use of multiple sources. The paper is technically sound and well written. I only have a couple of minor comments
1) Include a table summarizing relevant instrument parameters for the data sources.
The authors will add the below table to the paper to detail the instrument and satellite specifications.
[Table 1: Instrument and platform specifications]
2) Further discussion on Figure 6 and implications of increasing number of invalid pixels as samples move toward -40 deg would be welcomed.
Thank you, this has been added in as below:
Addition – line 214: These can be seen to increase with movement away from the poles due to the orbital geometry. As each satellite has a 5-day repeat time over the polar areas, the three combined require more than a day to ensure full coverage of the polar extremities. A compromise has been reached here, with the 1-day product covering the majority of the polar area and enabling a much product over many of the areas of interest. Recent drifting of Metop-A (in order to extend its lifetime) will lead to larger gaps in the 1-day product as the orbits become more similar between the satellites.
-
AC2: 'Reply on RC2', Jessica Cartwright, 06 Oct 2021