Review of „Kinematic observations of the mountain cryosphere using in-situ GNSS instruments“

Author(s): Jan Beutel et al.

MS No.: essd-2021-176

MS type: Data description paper

Dear Authors, I have read your paper and looked also into your dataset. Your dataset is extremely valuable for a large group of scientists in Earth sciences, but also for geodesist (surveying engineers) to test new approaches and for the development of new tools for the deformation analysis. I recommend publishing the data, but only after revising the paper and possibly some of your data that you will provide through Pangea. I have read your preprint and made a number of comments directly in the pdf-document of the preprint, which will be provided to you.

General Comments:

I strongly recommend checking the document for correct spelling and wording. English is not my mother tongue, but I believe that I can read technical text that covers my field of expertise. Many passages in the text were characterized by extremely long sentences, some of them were not well-structured. I tried to make improvements (see the PDF-document), but at times I found the sentences not conclusive. I recommend shortening complicated sentences by splitting them in several parts. In the end, the final document should maybe be checked by a native speaker. That should improve the text significantly.

I would change the title of your paper since I have a different understanding concerning “kinematic observations”. From my point of view, kinematic GNSS observations are best described by a rover/platform that is moving. Therefore, you have to determine a new position for every epoch. Looking at your figure B1 it clearly indicates that you have used the tool “rtkpost” for processing the double difference observations in a “static” mode. That means you assume a stationary position during the observation period. The control points are stationary on a daily basis but move over the years. Therefore, reconsider the title of your paper.

As I stated in my introduction, I consider your datasets as very valuable and would recommend publishing it after revision.

Specific comments:

You are using the term “double differential GNSS processing” all over your paper. I am used to the terms “differential GPS [GNSS]” or "double difference processing". The typical observable processed in GNSS data analysis is the double difference. My background is geodesy, and we always talk about "double difference processing". Please consider changing the term “double differential processing”.

Often you use the term “raw observations”. This needs clarification in your document. I suppose that you mean with “raw GNSS observations” the availability of carrier phase data. The geodetic GNSS community considers raw observations as the data provided by the receiver. In your case, these are ubx-files. Those are converted to RINEX (Receiver INdependent EXchange format) to be processed with different software packages. Check your document for the use of “raw observations” and explain it. It is also very important that you mention the availability of the phase observation, which are required for precise relative positioning.

At one place you write about the RINEX-2 specific abbreviation for the code, phase, Doppler and signal-to-noise observations without explaining it: “These contain C1 and L1 as well as C1, L1, D1, S1, P2, L2, D2, and S2 observables of the L1 and L1/L2 GNSS.”. Please add the necessary information.

Please write a few more sentences concerning RTKLIB. It consists of a number of tools and from what I have seen you have used “convbin” and “rtkpost”. Describe these two programs and their purpose shortly. Did you test other tools as well? RTKLIB has so far only been maintained by one person and new versions have not been published very often recently. Therefore, RTKLIB´s future may be uncertain and one has to switch to other programs.

You are using the term SLURM without explaining it. What is the advantage or purpose of SLURM in this context? Did you analyse the data with a linux version of rtkpost?

While looking at your RINEX data I noticed that many of them are provided in RINEX-3.04. In your paper you mention only RINEX-2. Please add information on RINEX-3. After uncompressing the data I was wondering that they are not compressed with the Hatanaka-compression. You are providing a very large amount of data. Using a zip-compression we are talking about 100 Gigabyte of RINEX data. In table 6 of your document you state that entire size of the RINEX data is 297 Gbyte. Therefore the zip-compression reduces the data to 30% of its original size. Using first Hatanaka-compression and then zip-compression would allow to reduce the data to nearly 10-15% of its original size, which is significantly smaller than the provided data. Scripts like RNX2CRZ or CRZ2RNX [Hatanaka, Y. (2008): A Compression Format and Tools for GNSS Observation Data, Bulletin of the Geographical Survey Institute, 55, 21-30, available at http://www.gsi.go.jp/ENGLISH/Bulletin55.html ] can easily compress and decompress the data. It is a standard used in the GNSS community. This will save resources at Pangea.

You are providing three files with meta-data for different areas. Within these files the information given for the GPS receivers is only “GPS Logger”, but not that it is a u-blox LEA-6T receiver. Also the antenna type is missing. The given coordinates of the sites are without information on the type, reference frame or projection. Please add these items.

You will find more specific comments in the provided PDF-file of your preview.

Technical comments:

While looking at your RINEX data I tested the Hatanaka compression and run into a problem. Obviously, the raw data translator “convbin” did not provide standard RINEX. In a next step I used “gfzrnx” (GFZRNX - RINEX GNSS Data Conversion and Manipulation Toolbox supplied by the GFZ) that was able to read the data and convert them into standard RINEX. Then it was possible to compress the RINEX by the tool “RNX2CRZ” applying the Hatanaka-compression and a zip-compression.

I also realized that the metadata are not provided in most of the RINEX headers. Information on the used receiver, antenna, approximated position and antenna height is missing. Please be aware that some software packages require this information. This information is not always mandatory, but some users applying different software tools to this GNSS observations may be forced to preprocess the data accordingly. It would be good style to add this missing information, because then it complies with the RINEX standard and also ensures the use of the data in the future. I realize that it is extra work. But I believe that with suitable scripts this is less effort than one might think at first.

You will find more technical comments in the attached PDF. Please consider most of my comments and attempts at improvement as suggestions. I do not insist on full implementation. As I myself do not speak English as a mother tongue, some corrections have to be handled with care.

I would like to mention again that these datasets are very valuable, and I support its publication.

The paper entitled ‘Kinematic observations of the mountain cryosphere using in-situ GNSS instruments’ by Beutel et al. introduced GNSS data and complementary in-situ measurements at 54 locations in the Swiss Alps. The observations are spanning ten years (2011 to 2021) and document the kinematics of various mountainous landforms at high altitude (primarily rock glaciers and unstable rock slopes). The dissemination of the dataset is relevant both for future research studies focusing on documenting the evolution of the periglacial environment in a changing climate and for operational purposes such as geohazard management.

This extensive dataset is surely valuable and appropriate for ESSD, but the current version of the manuscript is not ready for publication to my opinion. Important information regarding the documented sites, the technique limitations and data accuracy are missing. The paper is poorly structured, and the English writing definitively needs improvement. In the current version, it is hard to follow the workflow and understand the data/site properties.

In the following, I explain the major points. Many detailed comments have also been added in the attached pdf. Note that I am not a native English either, so my editorial corrections are clearly not exhaustive and in some cases need to be verified.

1. Documented landforms and general relevance:

The landforms that are instrumented must be clearly defined from the start and for each location, for the dataset to become useful for future users. The title is fuzzy: Mountain cryosphere is a very wide domain, it could theoretically include snow, glaciers, ice on lakes, etc. If you mean permafrost, just say it so. If many sites are not in permafrost zone (which is btw fuzzy in the paper): ‘periglacial landforms’ / ‘slope movements’ / ‘gravitational landforms’ could be used. A list of elements is provided at l.37-38 and l.59, but it lacks clarity: What is the difference between a rockfall site and a single unstable block? Or between a large rockfall site and a landslide? What do you mean by ‘fractures’ (l.59): it does not fit in a list of landform types I think. In general, I would suggest that you simplify by using ‘rock glaciers’ and ‘unstable rock slopes’ (all along the manuscript, also in Section 6). The terminology must also be briefly defined in the introduction to understand what we are speaking about. In tables 3 and 4, please add a column documenting the landform type / context. If not, potential future users will have a hard time to use the data in a meaningful way. Section 6 provides a rough number / landform types (except for landslides, l.452), but it is really hard to have an overview of what is documented and where. Maybe additional regional maps with sites categorized by landform types could help? The relevance description could also be improved. There are numerous vague statements regarding the link with climate (l.148-151, l.494-497) and mixing hazard assessment & risk mitigation (l.79, l.153-154) (see also comments in pdf).

2. Description of the technology, limitations and data accuracy:

GNSS and GPS terminology, as well as the references to the different generations of sensors are used in an inconsistent way all along, without actually explaining the differences (e.g. l.106, l.185, fig.6 caption, tables 3-4: L1/L2-GNSS vs L1-GPS). In general, it looks like the authors assume that the technology is an obvious background knowledge for all readers. As a result, some theoretical explanations are just spread in the manuscript without clear references and explanations (e.g. in 3.1, 3.4, 3.7). What we mean by data expressiveness (l.152, l.193) is not explained. Explanations regarding the sampling, the schedule, the granularity are really unclear (l.273-279) (probably party due to English). I think one solution would be to have a section early enough in the manuscript that briefly explains the main theoretical elements for nonexperts (as a method section in a traditional article structure). The expected/estimated accuracy of the GNSS data is never explained (n.a. in Table 2). Instead, there are very vague words/statements such as ‘very small displacements’ (l.78), ‘high accuracy’ (l.304), ‘highest fidelity’ (l.487), etc. The quality measure ‘ratio of fixed ambiguity’ is never explained (l.309, Table 5). Some limitations of the method are presented (for ex. Section 3.7) and solutions to mitigate them introduced (for ex. Section 5.2) but it is scattered in the paper. I would suggest adding a section on limitations/uncertainties that regroup all these elements.

3. Manuscript structure and figures:

The structure is not traditional, and it makes it hard to follow. There are also many subsections and I must admit I got a bit lost along the way. So here is a suggestion (there are surely other alternatives - it is just an example, a way to illustrate my thought):

• Introduction: The current intro is quite fuzzy. It could go directly to the point, explain the project background and relevance.
• Methodology/Technology: Technical knowledge on the sensors, explanations of the main terminology and the different generations of integrated system.
• Data/Products: 3.1. Site description (that should include information about which landform is documented), 3.2. Primary data, 3.3. Derived products.
• Limitations/Uncertainties: The problem of tilting / site challenges (current 3.7) could come here. It also should include an accuracy estimation and explanation of the quality measures.
• Applications: Here come the examples of previous exploitation as in the current Section 6, but maybe reorganized as 5.1 rock glaciers / 5.2. unstable rock slopes?

The figures could also benefit from some work to be more readable / useful. For example:

• Figure 2: hard to see what we are looking at without help (delineated landform, arrow to point out the described elements).
• Figure 5: the third plot is dominated by the extreme increase of LS05, such as we don’t see anything for the others. Two scales maybe?
• Figure 6: without explanation, this figure is not very informative to be honest...
• Figure 7: missing unit on y-axis and unclear legend of colors.
• Figure 10: a zoom on one local cluster would help to read it.
• Figure 14: it includes many elements that are never explained in the paper. I would suggest simplifying it (or explain it better in the text and/or in the figure caption).
• Figure 15: where is the blue line (raw data)?

More detailed comments in the attached pdf.