Next Article in Journal
Analysis of Transformation Methods of Hydroacoustic and Optoelectronic Data Based on the Tombolo Measurement Campaign in Sopot
Previous Article in Journal
Characteristics and Mechanisms of Marine Heatwaves in the East Asian Marginal Seas: Regional and Seasonal Differences
 
 
Technical Note
Peer-Review Record

An Efficient Global Scale Sentinel-1 Radar Backscatter and Interferometric Processing System

Remote Sens. 2022, 14(15), 3524; https://doi.org/10.3390/rs14153524
by Piyush S. Agram *, Michael S. Warren, Matthew T. Calef and Scott A. Arko
Reviewer 1: Anonymous
Reviewer 3:
Remote Sens. 2022, 14(15), 3524; https://doi.org/10.3390/rs14153524
Submission received: 16 June 2022 / Revised: 12 July 2022 / Accepted: 20 July 2022 / Published: 22 July 2022
(This article belongs to the Section Engineering Remote Sensing)

Round 1

Reviewer 1 Report

This technical note deals with large-scale Sentinel-1 radar backscatter and interferometry. The authors propose an efficient strategy including quick SLC data access and geocoding to provide SAR and initial InSAR datasets in a more widely acceptable way that can be in conjunction with other geospatial data. This contribution is of interest to the remote sensing community especially to InSAR scientists and engineers. I recommend publication after addressing the following concerns which can be easily fixed during revision.

 

In both of the abstract and the main text, please explain the abbreviations when they first appeared, e.g., ESA, SLC, AOI, SAR, etc.

Figure 1: ……. In response to Sentinel-1B outage in Dec 2021. (not 2022)

Figure 2: in the Y-axis, consider use x103, instead of ‘in 1000s’

Figure 4: use larger font size of the latitude and longitude labels

Line 253-254: do the authors modulate phase value of a geocoded SLC data? how do you modulate the phase?

Line 311: also explain

Line 341, what do you mean by ‘required additional mode-specific preprocessing and design of nested regular grids to handle heterogeneity in imaging resolution’? Heterogeneity in imaging resolution can also be fixed even for interferometric processing?

Line 348: what does an arbitrary phase addition? A constant value or a phase ramp (trend)?

Line 360-361: can the proposed coregistration method work for (high-resolution) L-band data? Is the ionospheric delay affects a lot the coregistration?

The authors emphasized in this paper that the proposed strategy is efficient and is for global scale. I would suggest if they could put extra paragraph to briefly quantify how the processing efficiency has been improved (e.g., the time required for getting the SAR/InSAR products) compared with the existing methods/pipelines. In addition, this paper seems to publish an (online) platform/system, the authors might wish to put 1-2 figures showing the interface (if any), example of the processing flow, etc., of the proposed system.

In many of the steps, oversampling is used, does this affect the processing efficiency and/or the data storage capacity? as the system is designed for global scale applications.

Overall, I would suggest the author to include a flowchart of the proposed strategy, making the presentation of methodologies clearer.

 

Please carefully check and improve the English, below list some of corrections.

Line 98: as long -> as long as

Line 103: zup -> zip

Line 120: to to -> to

Line 181: range range -> range

Line 182: delete ‘manuscript’

Line 240 10s of cm -> tens of cm

Line 340: required -> require

Author Response

Please find our responses inline with the original comments (in italics) by the reviewer below.

This technical note deals with large-scale Sentinel-1 radar backscatter and interferometry. The authors propose an efficient strategy including quick SLC data access and geocoding to provide SAR and initial InSAR datasets in a more widely acceptable way that can be in conjunction with other geospatial data. This contribution is of interest to the remote sensing community especially to InSAR scientists and engineers. I recommend publication after addressing the following concerns which can be easily fixed during revision.

  • We would like to thank the reviewer for going through the manuscript in detail and providing useful suggestions that clearly improve the quality and readability of the document. We have tried to address each of the comments as detailed below.

 

In both of the abstract and the main text, please explain the abbreviations when they first appeared, e.g., ESA, SLC, AOI, SAR, etc.

  • We have updated the abstract with expansions of the abbreviations.

Figure 1: ……. In response to Sentinel-1B outage in Dec 2021. (not 2022)

  • Thank you for pointing out this error. We have now updated the text as suggested. This Figure is now Figure 2 of the revised version

Figure 2: in the Y-axis, consider use x103, instead of ‘in 1000s’

  • We have now updated the figure as suggested. This Figure is now Figure 3 of the revised version.

Figure 4: use larger font size of the latitude and longitude labels

  • We have now updated the figure as suggested. This Figure is now Figure 5 of the revised version.

Line 253-254: do the authors modulate phase value of a geocoded SLC data? how do you modulate the phase?

  • Line 253 already clearly mentions that the phase of the geocoded data is modulated with the slant range. To avoid any confusion on part of the readers, we have modified this sentence to read :

"The phase of geocoded data is also modulated with the slant range propagation delay term ($\frac{4 \pi r}{\lambda}$, where $r$ is the slant range and $\lambda$ is the wavelength) as inferred during geocoding [29] to make our geocoded data readily usable for interferometric applications."

Line 311: also explain

  • We understand the interest of the community in this topic, but we would need to include 5-6 pages of detailed discussion and simulations to explain the concept in a satisfactory manner. Since, this is the only sentence where Radiometric Terrain Correction is mentioned in the manuscript - we have now chosen to drop this sentence completely. This change will not impact the main message of this manuscript. As stated in the original submission, we will address this topic in detail in another manuscript. For the reviewer’s information, we have briefly described the motivation behind our approach in a presentation at ESA’s FRINGE 2021 conference: 

https://www.youtube.com/watch?v=WrXiqh1ykbY&t=2571s 

 

Line 341, what do you mean by ‘required additional mode-specific preprocessing and design of nested regular grids to handle heterogeneity in imaging resolution’? Heterogeneity in imaging resolution can also be fixed even for interferometric processing?

  • We understand the interest in this topic but this would again need very specific analysis on a mission-by-mission basis. A number of factors impact inter-mode interoperability like
    • If they share common center frequencies or if the center frequencies are offset
    • If the bandwidths are integer multiples of each other
    • If the images are acquired with same antenna beam configurations
    • Scan patterns associated with the modes etc

When the instrument modes are carefully designed, it is possible to use geocoded SLCs across modes. There may be other scenarios where pre-processing like common band-pass filtering prior to geocoding would make the geocoded SLCs interoperable. We think our statement in the manuscript reasonably conveys this complexity as the manuscript focuses on Sentinel-1 specifically. Elaborating on this issue would again require multiple pages of explanation and would diverge from the main message of the manuscript. We have now modified this sentence to

“For missions that acquire imagery in a large number of modes over the same AOI, using geocoded SLCs for interferometric applications might require designing of additional mode-specific preprocessing and nested regular grids to handle heterogeneity in imaging resolution while collectively considering the characteristics of all modes that need to inter-operate.”

 

Line 348: what does an arbitrary phase addition? A constant value or a phase ramp (trend)?

  • We have now modified the sentence for clarity. It now reads:

“Our geocoding method treats the TOPS phase ramp [22] as an instance of an arbitrary pixel-by-pixel phase screen.”

Here we speak about the implementation of our geocoding module. The implementation does not assume any specific functional form of the phase screen allowing us to reuse components efficiently. The TOPS ramp is one type of phase screen. The ramp for spotlight mode is just another such instance. In addition to these systematic terms, users can throw in additional phase correction terms as needed (e.g, ESD) into this phase screen without having to modify the core of the geocoding implementation.  We have clearly highlighted in text in Line 252 that TOPS phase ramp is accounted for while geocoding the data.

 

Line 360-361: can the proposed coregistration method work for (high-resolution) L-band data? Is the ionospheric delay affects a lot the coregistration?

  • We have now modified the text to read:

“In general, our approach works very well for X-band and C-band data, but not so well for L-band data without additional corrections, especially for the ionosphere delay,  as clearly demonstrated in Figures 7 and 20 of [38] “

 

The authors emphasized in this paper that the proposed strategy is efficient and is for global scale. I would suggest if they could put extra paragraph to briefly quantify how the processing efficiency has been improved (e.g., the time required for getting the SAR/InSAR products) compared with the existing methods/pipelines. In addition, this paper seems to publish an (online) platform/system, the authors might wish to put 1-2 figures showing the interface (if any), example of the processing flow, etc., of the proposed system.

In many of the steps, oversampling is used, does this affect the processing efficiency and/or the data storage capacity? as the system is designed for global scale applications.

  • Thank you for this suggestion. We have now added a paragraph to the discussion section to address this:

“Resource requirement of the presented workflow is substantially less than traditional approaches and the workflow itself is highly scalable at the burst level. We are able to geocode a single burst SLC on a single CPU core in less than 100 seconds end-to-end without any multi-threading while using 3-4 GB of memory, with further room for optimization. The additional expense of handling oversampled geocoded SLCs is more than compensated for by the overall reduction in memory footprint, number of intermediate products, coordinate transform operations and file input-output operations. We again emphasize that we do not archive the oversampled geocoded SLCs, as our tools allow us to regenerate them as needed. While we referred to accessing the datasets within the context of our platform in Section 4, we would like to point out that our global scale products are GIS-ready and any standard geospatial tool suite (e.g.,[16]) can be used for operating on these.  The volume of the final backscatter and InSAR products is the same as those compared to ones generated using the traditional approach, and hence do not incur additional costs.”

 

Overall, I would suggest the author to include a flowchart of the proposed strategy, making the presentation of methodologies clearer.

  • Thank you for this suggestion. Figure 1 now shows our end-to-end geocoding workflow.

 

Please carefully check and improve the English, below list some of corrections.

Line 98: as long -> as long as

Line 103: zup -> zip

Line 120: to to -> to

Line 181: range range -> range

Line 182: delete ‘manuscript’

Line 240 10s of cm -> tens of cm

Line 340: required -> require

  • Thank you for pointing out these errors. We have fixed these in the text and have to tried to go over the whole text to fix similar issues.

Reviewer 2 Report

General description

Data access instrumental approach for Sentinel-1 Terrain Observation with Progressive Scans (TOPS) mode bursts is presented in the present study. This approach enables burst-based data access and processing. It eliminates ESA’s Sentinel-1 SLC data packaging conventions, which is constrain to large scale processing.

In this case, the computation throughput is determined by available compute resources and efficiency of the analysis algorithms. Co-registered geocoded stacks of SLCs for any aria of interest on the globe in a few minutes are generated.  Global scale radar backscatter SAR images and interferometric products are generated. Geolocation consistency across the suite of derived products from Sentinel-1 data is ensured. The advantages and limitations of working with geocoded SAR SLC data are discussed.

 

Remarks:

The authors suggest a comprehensive study of a global scale processing system for generating SAR backscatter and interferometric products obtained by Sentinel-1 TOPS.

 

It is recommended:

Disclose the abbreviation TOPS (Terrain Observation with Progressive Scans) (row 3)

Disclose the abbreviation AIO (Aria of Interest) when mention first time (row 6)

Define Single Look Complex (SLC) only one time (row 35).

 

Author Response

Please find our responses inline with the original comments (in italics) by the reviewer below.

General description

Data access instrumental approach for Sentinel-1 Terrain Observation with Progressive Scans (TOPS) mode bursts is presented in the present study. This approach enables burst-based data access and processing. It eliminates ESA’s Sentinel-1 SLC data packaging conventions, which is constrain to large scale processing.

In this case, the computation throughput is determined by available compute resources and efficiency of the analysis algorithms. Co-registered geocoded stacks of SLCs for any aria of interest on the globe in a few minutes are generated.  Global scale radar backscatter SAR images and interferometric products are generated. Geolocation consistency across the suite of derived products from Sentinel-1 data is ensured. The advantages and limitations of working with geocoded SAR SLC data are discussed.

 

Remarks:

The authors suggest a comprehensive study of a global scale processing system for generating SAR backscatter and interferometric products obtained by Sentinel-1 TOPS.

 

It is recommended:

Disclose the abbreviation TOPS (Terrain Observation with Progressive Scans) (row 3)

Disclose the abbreviation AIO (Aria of Interest) when mention first time (row 6)

Define Single Look Complex (SLC) only one time (row 35).

 

  • We thank the reviewer for pointing out these missing expansions. We have now added them to the text and have also expanded other such abbreviations.

Reviewer 3 Report

global scale radar backscatter and interferometric products

1. It is recommended that the author provide for scientists and researchers some open ways to obtain data products from this system.

2. It is recommended to give examples of the total time consumption of the system to produce typical data products, as well as the time consumption of the main processing steps for typical data.

Author Response

Please find our responses inline with the original comments (in italics) by the reviewer below.

 

global scale radar backscatter and interferometric products

  1. It is recommended that the author provide for scientists and researchers some open ways to obtain data products from this system.
  • Unfortunately, this topic is beyond the scope of this manuscript. We have tried to describe our approach and its benefits in detail in the interest of transparency. We believe that researchers / experts in the SAR/InSAR community will be able to build a similar system on their own using open tools with the description provided.
  1. It is recommended to give examples of the total time consumption of the system to produce typical data products, as well as the time consumption of the main processing steps for typical data.
  • Thank you for this suggestion. We have now added an entire paragraph to the discussion section that addresses this.

“Resource requirement of the presented workflow is substantially less than traditional approaches and the workflow itself is highly scalable at the burst level. We are able to geocode a single burst SLC on a single CPU core in less than 100 seconds end-to-end without any multi-threading while using 3-4 GB of memory, with further room for optimization. The additional expense of handling oversampled geocoded SLCs is more than compensated for by the overall reduction in memory footprint, number of intermediate products,coordinate transform operations and file input-output operations. We again emphasize that we do not archive the oversampled geocoded SLCs, as our tools allow us to regenerate them as needed. While we referred to accessing the datasets within the context of our platform in Section 4, we would like to point out that our global scale products are GIS-ready and any standard geospatial tool suite (e.g.,[16]) can be used for operating on these.  The volume of the final backscatter and InSAR products is the same as those compared to ones generated using the traditional approach, and hence do not incur additional costs.”

Round 2

Reviewer 1 Report

This paper can be published as is

Back to TopTop