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

Abstract. Permafrost warming is coinciding with accelerated mass movements, talking place especially in steep, mountainous topography. While this observation is backed up by evidence and analysis of both remote sensing as well as repeat terrestrial surveys undertaken since decades much knowledge is to be gained about the specific details, the variability and the processes governing these mass movements in the mountain cryosphere. This dataset collates data of continuously acquired kinematic observations obtained through in-situ Global Navigation Satellite Systems (GNSS) instruments that have been designed and implemented in a large-scale multi field-site monitoring campaign across the whole Swiss Alps. The landforms covered include rock glaciers, high-alpine steep bedrock bedrock as well as landslide sites, most of which are situated in permafrost areas. The dataset was acquired at 54 different stations situated at locations from 2304 to 4003 m a.s.l and comprises 209’948 daily positions derived through double-differential GNSS post-processing. Apart from these, the dataset contains down-sampled and cleaned time series of weather station and inclinometer data as well as the full set of GNSS observables in RINEX format. Furthermore the dataset is accompanied by tools for processing and data management in order to facilitate reuse, open alternate usage opportunities and support the life-long living data process with updates. To date this dataset has seen numerous use cases in research as well as natural-hazard mitigation and adaptation due to climate change.


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 PDFdocument), 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 zipcompression reduces the data to 30% of its original size. Using first Hatanakacompression 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.