Displacements Monitoring over Czechia by IT4S1 System for Automatised Interferometric Measurements Using Sentinel-1 Data

Round 1

Reviewer 1 Report

The authors present a nice overview of the system development to monitor surface deformation using InSAR on a national scale over Czechia. The details are well presented. I have three minor comments:

1. This is only a comment. The authors have highly specialized the implementation for an on-prem HPC system. A comment on the transferability of the system to a cloud-based system would be relevant to the user community.  
2. This is only an observation. The use of open-source tools for generation of SLC-C's are commendable. This demonstrates that the community based tools are getting more mature. However, it is unfortunate to see the use of matlab-based (commercial software) for some of the later processing steps. This may impact the transferability of the implemented approach to other less fortunate communities or on to more scalable cloud-based systems. If the authors did succeed in avoiding matlab and used open source alternatives like octave, that would be a big positive and should also be emphasized in the manuscript.
3. This is the only comment authors really have to address. The authors reference the use of a pair-wise workflow from ISCE but do not point to the stack processor that is also available in ISCE and is well documented - Fattahi, H., Agram, P. and Simons, M., 2016. A network-based enhanced spectral diversity approach for TOPS time-series analysis. IEEE Transactions on Geoscience and Remote Sensing, 55(2), pp.777-786. The authors may have modified the implementation to suit the infrastructure - but the approach is the same, has been publicly available for a couple of years and should be referenced. The manuscript above is the essential reference to way ESD / range coregistration is implemented in topsApp.py.

I would recommend the manuscript be accepted for publication once the reference to the Fattahi et al (2016) manuscript is included. 

Author Response

Dear reviewer,

thank you for useful opinions.
We have updated the text, following your remarks.

- cloud transfer:
The solution is ready for an HPC. We do not plan to deploy it on cloud. We include a brief comment in Conclusions on it:
"The IT4S1 system is designed to use a PBS job scheduler (qsub command). The job running commands can be modified prior to deployment to a system using another scheduler or e.g. a cloud environment."

- matlab2octave:
We have indeed tested possibility of use of octave. We use octave for several steps of STAMPS, but we have never managed to perform the full STAMPS processing in octave.
We have updated the text in several parts of the article and we hope it can inspire further researchers to finalise the transfer of STAMPS codes to octave.
we provide in text:
"We have experienced an increase of processing time when the MATLAB scripts of STAMPS were run through the open-source Octave environment."
"We report possibility of a direct use of Octave to run the STAMPS scripts for the steps 1–4."
"A working MATLAB software is a prerequisite for IT4S1 as only a part of STAMPS scripts can be run through Octave directly."

- NESD:
We are aware of the NESD approach that has been published months after our implementation of the core procedure. However these approaches differ (NESD should be more stable in the long run, indeed).
We have included this reference and provide in text:
"The SLCC data are very similar to the “resampled slave bursts” introduced in ISCE TOPS stacking approach []; our approach is its simplified version, as we use only one coherent InSAR combination instead of a multitemporal inversion of the ESD estimate as in []."
"It is recommended to follow the original TOPS stacking approach []."
"It demonstrates a great advantage of ARD data generated in this form [] for multitemporal analyses."

We hope our changes will satisfy your comments.

Reviewer 2 Report

In general: Interesting work. It gives an overview of the computational resources required to process data from Sentinel-1 on local and nation-wide scale. Moreover, it presents a few interesting cases over the area of Czechia. A great advantage is the published source code.
To increase value of the article, please consider the following remarks.
1. The more profound state-of-the-art would be useful, especially to emphasize what is innovative in the proposed solution (w.r.t. your previous works) and what contributes to the processing of the Sentinel data.
2. The method of data processing is described in detail (Section 2), but some kind of graphics or flowchart is missing. It should cover the entire process described in Section 2. Perhaps the missing Figure 2 will be sufficient.
3. Please write about the possibility of using the proposed solution for the data other than Sentinel.

Details (according to lines in the "for peer review" manuscript):
24-25: The sentence should be rather splitted into two sentences or modified somehow.
50: developed -> have been developed (?)
53: 1 mm/year - a reference recommended
73: over Czechia - Is it possible to cover wider area with SLCc data?
101/106/112: Why some of the maps are indicated as (semi-)annual and other are not?
124-125: Currently, this computer is in the fifth hundred of the TOP500 list. I propose to provide the actual data or omit them, because the parameters of the computer (given below) are more important.
134: czech -> Czech
141: comma -> and (?)
147: Czechia -> The area of Czechia
160: Should not the 22/1 swath be included in Table 1?
172: figure not displayed
194: phase signature sources - please explain
259: What is the size of the overlap? What minimum overlap is required?
288: STAMPS steps - I think it would be helpful not only to refer to STAMPS Manual, but also to recall the processing steps.
363: ssssssssssssand (?)
420: Is this a value of levelling error (mm/km) or height error (mm)?
424-425: This is the error of double height difference, i.e. the displacement error, rather than "kilometric error", isn't it?
443: How long period of time was taken to calculate the LOS velocity in graph c?
443: The graph d indicates that the LOS velocity (mm/year) from PS-U and SB-U is not constant. What moment of time do the values in graphs a and b correspond to?

Author Response

Dear reviewer,

thank you for useful opinions and comments.
We have updated the text, following your remarks.

In general: Interesting work. It gives an overview of the computational resources required to process data from Sentinel-1 on local and nation-wide scale. Moreover, it presents a few interesting cases over the area of Czechia. A great advantage is the published source code.
To increase value of the article, please consider the following remarks.

1. The more profound state-of-the-art would be useful, especially to emphasize what is innovative in the proposed solution (w.r.t. your previous works) and what contributes to the processing of the Sentinel data.

Thank you for the remark. We have modifed several sentences in this direction and changed the Sections to start by the "earlier dates" results. We also include to "introduction":
"IT4S1 has been developed as a base environment for advanced SAR data analyses. This article provides an overview on the implemented InSAR processing approaches and experience from monitoring over selected areas over Czechia. We also present a nation-wide processing output using PS InSAR method, from data covering up to 10/2014-10/2017."

2. The method of data processing is described in detail (Section 2), but some kind of graphics or flowchart is missing. It should cover the entire process described in Section 2. Perhaps the missing Figure 2 will be sufficient.

We have updated the figure (for some reason, it was not generated in the PDF preview version) and moved it to the Section level.
We understand that a full set of flowcharts would be a valuable addition to the article but this would cause a significant effort that we believe is out of the scope of the revision.

3. Please write about the possibility of using the proposed solution for the data other than Sentinel.

The IT4S1 routines are optimised for S1 data. We have included only one sentence on this topic, to Discussions:
"Though IT4S1 is prepared specifically for a systematic processing of Sentinel-1 data, it can be further developed to ingest also data from other SAR satellites."

Details (according to lines in the "for peer review" manuscript):
24-25: The sentence should be rather splitted into two sentences or modified somehow.

thank you for remark, corrected

50: developed -> have been developed (?)

corrected

53: 1 mm/year - a reference recommended

included Ferretti et al., 2007

73: over Czechia - Is it possible to cover wider area with SLCc data?

we include "can be deployed in an HPC environment, given the pre-existing database of burst definitions [16] over region of interest." to Conclusions.
also, we have already mentioned two other regions of interest that were used within IT4S1. We add:
"This also demonstrates a possibility of the application of deployed IT4S1 system to areas outside of designated region of interest, though it is not the primary objective of the system (technical issues should be expected in case of extended areas covering the same relative orbit/swath configuration)."

101/106/112: Why some of the maps are indicated as (semi-)annual and other are not?

we have rewritten this part, keeping only 'annual' and providing explanation for this part as:
"The IT4S1 system has been established with a view of performing automatic or fast on-demand InSAR processing of Sentinel-1 data that would allow generating several types of moderate resolution products, valuable for a direct use by national or local structures:"

124-125: Currently, this computer is in the fifth hundred of the TOP500 list. I propose to provide the actual data or omit them, because the parameters of the computer (given below) are more important.

We have decided to keep the information, as it was considered relevant for the coauthors affiliation. We have updated the text:
"The current cluster “Barbora” has not been listed at the time of preparing this article. We have used the “Salomon” cluster (listed 423th in TOP500 in June 2020) for the IT4S1 processing.".

134: czech -> Czech

corrected

141: comma -> and (?)

corrected

147: Czechia -> The area of Czechia

corrected

160: Should not the 22/1 swath be included in Table 1?

Indeed, we had intentionally skipped mentioning the 22/1 data, as these were not processed within the system, by an accident. We have modified the table and the text (including the parts where we used 'all bursts over Czechia').

172: figure not displayed

I have noticed that this figure is not shown in the PDF preview (though originally exported ok). We have recreated the figure.

194: phase signature sources - please explain

we have instead rewritten the sentence to:
"The fine offset field grids contain estimated non-displacement phase due to a stereoscopic effect of topography observed from two slightly different satellite positions at both primary and secondary bursts."

259: What is the size of the overlap? What minimum overlap is required?

added: "(sub-sequent bursts overlap themselves within approx. 1.5 km along their common orbital track or between swaths)"

288: STAMPS steps - I think it would be helpful not only to refer to STAMPS Manual, but also to recall the processing steps.

we have updated the two paragraphs related to our STAMPS-based processing chain, providing some brief explanation of each step in a simple way.

363: ssssssssssssand (?)

corrected

420: Is this a value of levelling error (mm/km) or height error (mm)?
424-425: This is the error of double height difference, i.e. the displacement error, rather than "kilometric error", isn't it?

Thank you for spotting this inconsistency. We have corrected the text. It is now:

"The measurement instrument DNA 03 Leica has mean kilometre error of 0.3 mm/km. Mean kilometre errors of measured and corrected height from the precise levelling ranged between 0.6–1.6 mm/km. The accuracy of differences of the measurements was evaluated in the principle of the law of accumulation of errors. The mean error of the height differences within each levelling measurement ranges between 0.8–2.3 mm. For the double-difference using one of the levelling points as reference (depicted in Fig. 8) towards the levelling point of interest (POI), the mean levelling errors were calculated as 1.9–2.8 mm."

443: How long period of time was taken to calculate the LOS velocity in graph c?

Indeed we did not provide this information. Updated the text as:
"For this particular burst, we have used the current SLCC dataset of 220 SLCC images covering period of 02/2015–09/2019." and also updated the figure caption (also we have updated the whole figure for better visual interpretation).

443: The graph d indicates that the LOS velocity (mm/year) from PS-U and SB-U is not constant. What moment of time do the values in graphs a and b correspond to?

The velocity is an estimated value computed from the phase measurements within a time series. We do not plot velocity in graph d. We have updated the graph and provide 'lines' as 'rolling averages'.
We have updated the figure caption to provide information about time (it is a velocity in mm/year):
"Mean LOS velocity estimated from burst ID 175_2_8091 (220 SLCC images, 02/2015–09/2019)"

We hope our update will satisfy your comments.

Round 2

Reviewer 2 Report

All amendments meet the requirements of my review. Thank you.