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

Abstract

We describe an efficient and cost-effective data access mechanism for Sentinel-1 Terrain Observation with Progressive Scans (TOPS) mode bursts. Our data access mechanism enables burst-based data access and processing, thereby eliminating the European Space Agency’s (ESA’s) Sentinel-1 Single Look Complex (SLC) data packaging conventions as a bottleneck to large scale processing. The pipeline throughput is now determined by the available computation resources and the efficiency of the analysis algorithms. For targeted infrastructure monitoring studies, we are able to generate coregistered, geocoded stacks of SLCs for any area of interest (AOI) in the world, in a few minutes. In addition, we describe our global scale radar backscatter and interferometric products, and associated pipeline design decisions that ensure geolocation consistency across the suite of derived products from Sentinel-1 data. Finally, we discuss the benefits and limitations of working with geocoded SLC data.

1. Introduction

Until a few years ago, the transformation of Synthetic Aperture Radar (SAR) data to higher level products was considered a specialty of niche academic and engineering groups, largely due to the limited availability of this type of data and the associated restricted use licenses. The Sentinel-1 SAR constellation [1], part of Europe’s Copernicus Earth Observation programme, has significantly changed this situation. Data acquired by this constellation have been freely available for end users since October 2014, enabling local- and global scale application users to reliably access and analyze SAR imagery over their AOIs. A number of wide-area applications have already been built on top of Sentinel-1’s data archive, e.g., [2,3,4,5].

While Sentinel-1 data are open and freely accessible, there are still challenges in efficiently using this dataset. The first is that the data are available via large-zip files that do not offer sufficiently fine-grained access. The second is that, once accessed, the data are presented in a non-Geographic Information System (GIS)-compatible coordinate system that is not easily converted to more conventional coordinate systems. SAR processing tool suites, e.g., GMTSAR [6], perform most operations in this non-GIS coordinate system, and re-project results to a GIS coordinate system as a final step.

In our organization, Descartes Labs, we often build and deploy analytic models that use multiple sources of remote sensing data, and where GIS compatible coordinate systems provide a lingua franca. Products derived from SAR backscatter and interferometric SAR (InSAR) often play a crucial role in these models. Providing fine-grained access to SAR data in a GIS-compatible coordinate system makes it easier to build and deploy these models—essentially reducing SAR and InSAR data to “just another” data source.

To address this need for fine-grained access to SAR and InSAR data in a GIS compatible coordinate system, we have developed a fast data access mechanism for the Sentinel-1 SLC datasets. This data access mechanism is efficient, and operates in a granular fashion similar to the way in which Cloud Optimized Geotiff’s (COGs) are used for optical imagery. Additionally, we have built a geocoding mechanism to faithfully represent SLC data on a GIS coordinate system. Powered by the data access and geocoding mechanisms, we have developed rapid global scale radar backscatter and interferometric processing pipelines. In this manuscript, we describe our data access mechanism, geocoder, and the salient features of our processing pipelines.

This manuscript is organized as follows. Section 2 describes our fast Sentinel-1 SLC data access mechanism. Section 3 describes our geocoding approach, and also discusses the benefits and limitations of using such a processing approach. Section 4 describes our global scale products and associated pipeline design decisions. In Section 5, we discuss the relevance to other SAR missions of the methods presented here.

2. Sentinel-1 Data Access

The Sentinel-1 mission images most land masses in the Interferometric Wide swath (IW) TOPS imaging mode [1]. While the mission does use conventional stripmap (SM) and wave (WV) imaging modes over land, SM and WV collections represent a tiny fraction of the total data volume acquired. In this manuscript, we only focus on the data acquired in the most frequently used IW imaging mode. The concepts presented here for IW mode are also relevant for the less frequently used Extended Wide (EW) swath imaging mode imagery. Sentinel-1 IW mode Level-1 imagery is released in two flavors by the European Space Agency (ESA) [7]—SLC granules and Ground Range Detected (GRD) granules.

Because GRD data can be derived from SLC data, and because we must support both coherent and amplitude-based analyses, we prefer using SLC data over GRD data. The rest of the discussion will therefore focus on SLC data.

2.1. Global Burst Footprint Map

One of the important features of the Sentinel-1 SLC data is that the footprints corresponding to the SLC granules are not fixed over time. However, the footprints of the contained bursts are stationary, thanks to the burst synchronization feature of the mission [1]. These burst footprints repeat almost exactly, and can be used as a basis to organize temporal stacks of Sentinel-1 imagery [8]. This is similar to Landsat’s Path-Row or Sentinel-2’s tiling scheme.

We built our own first version of Sentinel-1’s global burst footprint map in August 2020, using the radar metadata in annotation files from all Sentinel-1 SLC imagery from September 2014 to July 2020. Subsequently, we adopted a naming convention (See

Table 1. Naming convention for Sentinel-1 burst footprints and individual bursts.

Product	Convention
Burst Footprint	TTT-AAAA-IIW-PP-VU
Individual Burst SLC	YYYY-MM-DD-SSS-TTT-AAAA-IIW-PP-VU-HASH
Field	Description
YYYY-MM-DD	Acquisition date
SSS	Mission name (e.g., S1A)
TTT	Track number (001–175)
AAAA	Function of time since ascending node
II	Imaging mode (e.g., IW)
W	Swath number (1–5)
PP	Polarization. Always VV for footprint
V	Looks side (R for right, L for left)
U	Pass direction (A for asc, D for desc)
HASH	4-char hash of the source SAFE granule

) for individual burst footprints and for individual burst SLCs. Here, we refer to a burst footprint as an entry in our map corresponding to the geometric extent of an imaged area, and a burst SLC as an entry corresponding to a particular SLC image for that burst. Note that the unique identifiers of individual burst SLCs include the identifier of the corresponding footprint. Each of our Level-1 burst footprints have also been mapped to the European Space Agency (ESA) burst polygons that were released in June 2022 [8]. This database of burst SLCs connects burst-level metadata, geometric extents for the burst, and the ESA SLC granule from which the burst can be accessed.

The choice of the function of the ascending node time in our naming convention (see Table 1) needs only to be consistent for all labeling operations. Our burst databases are dynamic products that are updated automatically with new footprints and burst SLCs as imagery from the ESA is ingested by our system. Once we had the initial footprint data, we ingested all historical SLC data, and we currently keep up with incoming data from the ESA. Our burst database can be searched with our identifiers as well as ESA identifers, and we will continue labeling data using our mechanism, even though the ESA has updated its baseline processor [8,9] to include unique burst IDs in the metadata since IPF 3.5.x, as this acts as an additional quality control (QC) check in our ingest pipelines.

2.2. Rapid Access to a Single Burst

Labeling all the global Sentinel-1 SLC data provides an indexing structure for our databases. While it let us organize our workflows, it did not speed up processing, as we still needed to extract bursts from within TIFF files contained in Standard Archive Format for Europe (SAFE) zip archives. To address this, we adopted techniques used in the neuroimaging community to build tools to enable random access within large zip archives (e.g., [10]). Note that this approach requires that we scan the entire zip file once. We store the state of the zip decoder at various locations corresponding to individual bursts along with the radar metadata, as part of our data ingest pipeline. With this setup, we are able to access radar metadata for any burst (in any polarization) without having to access large SAFE archives, and are able to decompress fragments of SAFE zip files client-side, and quickly extract the associated imagery. This lookup mechanism can be used with any store of Sentinel-1 SLCs, as long as the original zip files from the ESA have not been modified. We are able to pull any burst (∼80 MB compressed) from SLC SAFE zip files residing in our cloud storage buckets in 2–3 s, and pull the same data from SLC SAFE zip files residing in NASA’s Alaska Satellite Facility (ASF) archive in 6–7 s. This rapid data access mechanism lets us process backscatter and InSAR products on the live stream of SLC SAFE zip files from the ESA very efficiently. This capability also allows us to rapidly test new analysis methods—especially interferometric and polarimetric methods, at scale over large regions or time spans.

Rapid SLC data access has been identified as a bottleneck by various SAR user groups, including the Copernicus Land Monitoring Service (See Appendix F of [11]), and we believe the mechanism presented here is a scalable solution to address this. Some common use cases and benefits of our data access mechanism are listed here:

• Processing tasks do not require nodes that can read an entire SLC SAFE file. This enables finer-grained workers and increased parallelism.
• This rapid access allows us to run near-realtime pipelines that generate backscatter and InSAR products globally, with a latency of under a day.
• For wide area analysis, this eliminates expensive and time-consuming data replication into shared file systems or large scratch disks, and enables access to SLC data as part of the processing workflow without delay.
• This enables access to co-pol imagery without having to transfer associated cross-pol imagery as well. This cuts down data transfer by half, compared to approaches staging entire SAFE archives for interferometric applications.
• This allows us to predetermine burst footprints that do not contain land, and completely avoid transferring that data for certain applications, further cutting down on data transfer by almost 30%.

Note that this data access mechanism will speed up any processing pipeline, irrespective of the manner in which the SLC data are used, as it enables granular access in parallel to individual bursts.

3. Geocoded Bursts

In the geospatial community, SAR datasets are notorious for their relatively complicated data distribution formats and need for custom processing tools to transform them into analysis-ready products. In this section, we describe in detail our geocoding process, which enables us to bring SAR and InSAR datasets into standard geospatial frameworks. We also provide analogies in terms of well known GIS concepts, in hope that this will assist in demystifying SAR data to users who are not familiar with this type of data, and for future adopters of this technology.

3.1. Projection System of a SAR Image

Sentinel-1 Level-1 SLC images are organized as a collection of bursts (Section 2). Each SLC burst, though not very obvious to users familiar with working on other types of geospatial datasets, has a well defined projection system. The primary challenge for GIS software in working with SAR data is that this projection cannot be represented using a standard EPSG code [12] or a simple PROJ string [13]. Hypothetically, if we were to write a PROJ string [13] representation for a burst SLC, it would look something like:

$$\begin{array}{c}+\mathrm{proj}=\mathrm{zerodoppler}\hfill \\ +\mathrm{side}=\mathrm{right}\hfill \\ +\mathrm{range}=\mathrm{slant}\hfill \\ +\mathrm{orbit}=\mathrm{t}1,\mathrm{x}1,\mathrm{y}1,\mathrm{z}1,\mathrm{v}\mathrm{x}1,\mathrm{v}\mathrm{y}1,\mathrm{v}\mathrm{z}1;\mathrm{t}2,\mathrm{x}2,\mathrm{y}2,\mathrm{z}2,\mathrm{v}\mathrm{x}2,\mathrm{v}\mathrm{y}2,\mathrm{v}\mathrm{z}2,\dots \hfill \end{array}$$

The zero Doppler system indicates that pixels are arranged in an orthogonal grid with an axis that is tangential to the satellite’s orbit—this is the system used by Sentinel-1 [7,9]. The most commonly used SAR datasets, such as those collected by Sentinel-1, the TerraSAR-X constellation, the COSMO-SkyMed constellation, ICEYE, Capella, RISAT etc., all use the zero Doppler system [14]. The side argument indicates if the platform is looking left or right. The range argument indicates that the data are on a uniform slant range grid. Note that, while coordinates in a radar image are represented by two unique indices—row and column, the projection system is a 3D Coordinate Reference System (CRS), i.e., coordinate transformation depends on the altitude of the point. In most cases, a reference height is assumed for the pixels in the radar image. Another reason that our hypothetical projection system above cannot be treated as a standard system is because many points in physical 3D space (or standard CRS) map to the same radar pixel—when these points occur on the surface of the Earth, this effect is known as layover [15]. This can happen when, e.g., the SAR system is looking perpendicular to the side of a incline, and all points on the incline have the same range. However, any point in 3D physical space (or standard CRS) maps to a unique point in the SAR projection system. Note that the geolocation of points in the SAR image requires this orbit information, which we have included above as a semicolon-separated list of time-tagged Cartesian positions and velocities for simplicity. Often, this information is read in from external orbit files, or from metadata included with the radar imagery.

The key implication from this PROJ string analogy is that any change in the projection parameters, notably the orbit state vectors above, essentially represents a different coordinate system. A direct consequence of this is that every SAR image, even if acquired over the same AOI, inherently has a different projection system, since satellite orbits do not repeat perfectly. One of the core features of the SAR processing software is support for the transformation of points in standard CRS to the SAR projection system, and vice versa.

3.2. Geotransform of a SAR Image

An affine geotransform [16] is a standardized way of associating map coordinates with pixels of a raster image. Continuing our effort to describe SAR data sets in a GIS-compatible manner, we can write the geotransform for a SAR SLC image that uses the projection system above as:

$$\left[\begin{array}{c}\mathrm{slant} \mathrm{range} \mathrm{to} \mathrm{first} \mathrm{pixel} \mathrm{in} \mathrm{m}\hfill \\ \mathrm{slant} \mathrm{range} \mathrm{pixel} \mathrm{spacing} \mathrm{in} \mathrm{m}\hfill \\ 0\hfill \\ \mathrm{zero} \mathrm{doppler} \mathrm{time} \mathrm{of} \mathrm{first} \mathrm{line} \mathrm{in} \mathrm{UTC}\hfill \\ 0\hfill \\ \mathrm{azimuth} \mathrm{time} \mathrm{interval} \mathrm{in} \mathrm{s}\hfill \end{array}\right]$$

Many SAR constellations operate in near-polar orbits, and for such orbits, the along-track time is roughly equivalent to the Y-coordinate or latitude, and the slant range from the satellite’s orbit is roughly equivalent to the X-coordinate or longitude, if we were to compare this representation with geospatial datasets that are distributed in Universal Transverse Mercator (UTM) or geographic coordinate systems. In the case of GRD images, the ground range replaces the slant range in the notation above, and the interpretation presented here still applies.

3.3. Coregistration as Reprojection

As described above, each SAR image is essentially distributed in its own projection. Hence, coregistering one SAR image to another acquired over the same AOI is essentially, in GIS terminology, a reprojection operation. A minor complication in this reprojection is the nature of SAR imaging itself. A SAR image represents a 2D representation of a 3D world—and here, we are trying to coregister two different projections of the same underlying 3D world; this is akin to aligning photographs acquired from different perspectives. Consequently, precisely aligning these images requires a model of the 3D world, i.e., a digital elevation model (DEM) [17].

In traditional processing approaches, the projection system (also known as radar geometry) of one of the images from a stack of imagery (usually from the same cluster of imaging geometries) is used as the reference system onto which one projects the other images, e.g., [18,19]. This approach involves a fair amount of bookkeeping and managing pixel-by-pixel transformations via a known coordinate system of the underlying DEM, and is a core feature of SAR processing software.

In our approach, we use an UTM-based system as the common projection system for our Sentinel-1 products, and we project every burst SLC to this common system. This approach is computationally efficient, as we reduce the number of coordinate transforms and can use the DEM grid as our reference grid directly. This operation can be optimized to work efficiently on a single CPU core, and without heavy memory requirements [20]. Note also that the mapping from the UTM coordinate to a point in 3D space occurs by appending the elevation; as such, it is only as smooth as the DEM itself. However, the mapping from a point in 3D space onto the SAR images coordinate system is as smooth as the orbit, and supports accurate interpolation. Once this process is complete, we have geocoded imagery in a well known CRS, and we are able to use the same set of data manipulation tools that we have developed on optical and other geospatial datasets, and have tuned over the years, with our SAR datasets [21]. In other words, we have reduced SAR geocoding to an enhanced ‘warp‘ operation [16] with custom interpolators that have been designed to preserve phase and amplitude properties, while accounting for any carriers on the data [22]. Note, however, that any further interpolation of these data must respect the phase of the underlying data. These phases are nearly random, and most interpolation schemes beyond down-sampling are not safe.

3.4. Preserving Signal Fidelity

In accordance with standard signal processing principles, we oversample when geocoding the data, to avoid artifacts due to aliasing, particularly during interferometric processing. We geocode Sentinel-1 bursts to an aligned grid with 10 m northing × 2.5 m easting grid spacing, even though the SLC data has a ground posting of ∼14 m ×∼5 m. Note that we oversample significantly more in easting (approximate slant range) to retain features in steep terrain, to mimic the natural anisotropy of the range-Doppler grid.

The possibility of considering a well known CRS as a common projection system for stacking SAR imagery has only been possible due to the massive improvements in SAR metadata quality and auxiliary datasets in the last decade. Notably:

• Our coordinate transforms rely on good DEMs, and a global scale high quality DEM was not broadly available until the Shuttle Radar Topography Mission (SRTM) [23] data became freely and publicly available less than 20 years ago.
• The quality of the satellite orbit data, which directly impact the projection system, has also significantly improved. With on-board Global Positioning System (GPS) receivers, these errors are on the order of a few centimeters for Sentinel-1 [24] and largely in the along-track direction. This is a massive improvement over the previous generation sensors where the errors were in the order of few meters. This is equivalent to having more accurate projection information for generic geospatial data.
• The accuracy of the geotransform in the metadata, especially in the along-track direction, has also significantly improved in the last decade, due to better clock synchronization. Working with previous generation sensors such as the European Remote Sensing (ERS) satellite and Envisat, users would often encounter shifts in the along-track/northing direction during geocoding.
• The accuracy of the slant range component of the geotransform depends on the two-way propagation delay through the atmosphere. The delay through the atmosphere exhibits a variance of a few tens of centimeters [25,26], which is an order of magnitude smaller than Sentinel-1’s range resolution, and has minimal impact on this dataset. For readers who are well versed with SAR processing, we would like to note that if standardized slant range delay estimates due to the troposphere and ionosphere [27], or along track timing corrections derived from Enhanced Spectral Diversity (ESD) [28] were to be made systematically available on a global scale, it would be straightforward to incorporate these during geocoding in our pipelines.

We also note that, in well known CRSs, an equivalent pixel-by-pixel geometric transformation can always be determined for computing additional useful parameters such as incidence angles, interferometric baselines, etc., without a loss of precision.

In our global scale pipelines, we first calibrate the amplitudes of burst SLCs to correspond to thermal-noise corrected ${\sigma }_{0,E}$, using lookup tables in the radar metadata before geocoding the imagery on an UTM grid, while carefully accounting for phase ramps in the data [22]. The phase of the 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. Our end-to-end geocoding workflow is shown in Figure 1.

3.5. Spatial Averaging

The presented approach also ensures consistent geocoding between suites of products derived from geocoded SLCs. SAR and InSAR workflows often involve a spatial averaging or a multi-looking step to help alleviate speckle effects. In traditional processing approaches, this spatial averaging is often performed in original radar coordinates (e.g., when generating GRDs from SLCs), and the data are then resampled onto a uniform grid. This often leads to the averaging of data from different segments on the ground, and the differences can be further exaggerated in heterogeneous terrain by the geocoding operation, which is avoided with our approach.

This effect is understood within the InSAR community, and one of the commonly used methods to alleviate this effect is to group acquisitions according to satellite geometries, and to coregister every image in each group to a chosen reference image. This stacking approach significantly reduces phase closure artifacts in InSAR analysis, compared to using interferograms that were generated pair-by-pair with different reference images. Note that even in this case, the same issue resurfaces when comparing averaged results across satellite tracks/geometry groups. In our approach, we always geocode the SAR image to a oversampled high resolution regular grid (10 m northing × 2.5 m easting) first, and then average signals from the same segments on the ground, consistently, to the extent afforded by the accuracy of the DEM used. This essentially allows us to generate high quality global backscatter (10 m) and InSAR coherence (20 m) datasets that are very well coregistered on the live Sentinel-1 datastream from the ESA. We are currently unaware of any other complementary backscatter and InSAR dataset with similar coregistration properties.

4. Global Scale Sentinel-1 Products

In this section, we describe the various global scale products built on top of our fast Sentinel-1 data access (Section 2) and geocoding (Section 3) mechanisms. While we derive our global scale products from geocoded bursts, we do not archive these oversampled SLCs, as our tools allow us to regenerate this on-demand, as needed.

4.1. Global Burst Footprint Database

The global footprint database is a dynamic product that we update when new previously unimaged burst footprints are encountered during ingest (See Figure 2 for example). This global database also allows us to track common processing parameters such as EPSG codes, bounding boxes, nominal values for minimum and maximum altitude in the footprint, etc., to simplify the orchestration of processing jobs at scale.

4.2. Global Burst SLC Database

The global burst SLC database is a dynamic product that we update with every new incoming SLC image released by the ESA. In addition to nominal metadata such as source SAFE granule, swath number, and burst number, we also establish zip-decoder state and lookup tables, which enable us to access individual bursts independently, as described in Section 2. Each polarization is stored as an independent entry in this global database. Our geocoding pipelines use this database to process geocoded bursts and to generate backscatter and interferometric products on a global scale (see Figure 3).

4.3. Global Calibrated ${\sigma }_{0,E}$ Product

We process all V-transmit IW mode data acquired by Sentinel-1 to a 10 m calibrated, thermal-noise corrected ${\sigma }_{0,E}$ product in decibel scale, with 12-bit quantization and a dynamic range from −40 dB to 30 dB. Backscatter products are generated from the amplitude of the geocoded SLCs, using a Gaussian kernel of 10 m resolution [30] in easting, and decimated to an aligned grid of 10 m. The imagery is tagged with burst IDs and contain two bands—VV and VH. This product is accessible just like other satellite imagery datasets on our platform [21], and is used in a number of large scale change detection pipelines, e.g., [31,32,33,34,35]. We can also process H-transmit data (mostly over Greenland and Antarctica), as well as EW mode data (mostly over sea ice) on request, or for experiments using the same mechanisms. Since we start from SLCs instead of GRD products, this global backscatter product does not have artifacts such as noisy edges or missing lines, as valid data regions are better labeled in SLC products, and burst overlaps are preserved during processing.

4.4. Global Wrapped Interferogram Product

We process all VV-pol IW mode data acquired by Sentinel-1 over footprints over land to a 20 m wrapped interferogram product. All interferometric pairs with a temporal baseline of less than or equal to 24 days are automatically generated by our system. Interferograms generated via the complex cross multiplication of geocoded bursts, filtered using a Gaussian kernel of resolution 50 m [30] and decimated to an aligned grid of 20 m. We do not apply any ESD corrections [28], as this has very little impact on interferometric coherence, and the product should be considered equivalent to those generated with purely geometric coregistration strategies [36]. If desired, users can estimate the ESD offset using burst overlaps and apply a phase-only correction [37] as part of their post-processing workflows.

The imagery are tagged with the reference burst ID and temporal baseline, and contain two bands—coherence (see Figure 4) at 10-bit quantization and wrapped phase (see Figure 5) at 16-bit quantization. As with backscatter, this product is accessible, similar to other satellite imagery datasets on our platform, and is used in a number of large scale change detection pipelines, e.g., [33,34,35]. This global product has already been used to build quick-look deformation time-series tools, and will easily support a global scale volcano monitoring system. Note that users can always combine this interferometric product with the ${\sigma }_{0,E}$ product above to recreate the original interferogram, and apply more spatial looks if needed, for their application.

5. Discussion

The SLC data access mechanism described in this manuscript can be easily adopted for use with ScanSAR data from sensors such as Envisat and the second Advanced Land Observation Satellite (ALOS-2), and also with SM data, to enable quick access to sections of long strips. Access to any SAR data format in which imagery arrays are stored as contiguous chunks, e.g., Committee on Earth Observaton Satellites (CEOS), or TerraSAR-X’s Complex SAR (COSAR), can be sped up with this mechanism.

The consistency of its imaging modes, i.e., central frequency and bandwidth, is one of the key strengths of the Sentinel-1 mission observation plan, and allows us to use geocoded bursts efficiently. For missions that acquire imagery in a large number of modes over the same AOI, using geocoded SLCs for interferometric applications might require the design 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. As mentioned in Section 3, we start with lowest level calibrated SAR data-Level-1 SLCs in our pipelines, as opposed to raw data [29]. This is because every SAR instrument and associated calibration information (which is often not publicly shared) is unique and needs to be constantly monitored. Starting from the SLC data, assuming that the data providers have calibrated the data to the best of their ability—both geometrically and radiometrically, allows us to focus on the goal of building and maintaining large scale sensor-agnostic analytic pipelines. Our geocoding method treats the TOPS phase ramp [22] as an instance of an arbitrary pixel-by-pixel phase screen. This allows us to bring in targeted spotlight imagery from other SAR sensors such as TerraSAR-X, COSMO-SkyMed, ICEYE, and Capella, into our data system, without significant changes.

In Section 3, we noted that atmospheric propagation delay can result in a variation of a few tens of centimeters in slant range in a stack of SAR imagery. For very high resolution data (e.g., spotlight mode) the magnitude of variation is comparable to image resolution, often leading to decorrelation in interferometric applications. In such cases, we can perform the same sort of cross-correlation-based offset estimation to generate coregistered stacks, as in the traditional approach. In fact, these offsets can be estimated with the geocoded imagery and with simple geometric transformations translated back to offsets in radar coordinates before geocoding the data again with the necessary corrections. We have validated this approach with data from TerraSAR-X, COSMO-SkyMed, and ICEYE. 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 resource requirement of the presented workflow is substantially less than with 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 s 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 transformation 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 the ones generated using the traditional approach, and hence, they do not incur additional costs.

In geospatial analytics, different projection systems are better suited for different types of analysis and applications. For example, Equal Area or UTM CRSs are suited for data aggregation or field surveys, whereas geographic (LatLong) CRSs are better suited for others. The same holds true for SAR data as well. Native radar geometries (such as the zero Doppler system) are best suited for spectral sub-banding and calibration operations; whereas transforming the data to well known CRS early in the processing chain allows us to leverage scalable data systems and tools developed for managing large volumes of satellite imagery and efficiently operationalize established SAR applications such as backscatter and InSAR. We believe that using geocoded SLCs as a building block significantly lowers the entry barrier for remote sensing users to start using global scale SAR datasets and for use of SAR data in conjunction with other geospatial datasets in more widely used geospatial frameworks.

The global products that we have described in this manuscript should be considered as building blocks for wide area analytics, similar to [31,32,33,34,35], along with data from other satellite sensors such as Landsat, Sentinel-2, etc. In the near future, we hope to build on these products and build fast pipelines for global deformation and change detection products on a global scale.

6. Conclusions

In this manuscript, we have described the design principles and implementation details of a global scale processing system that we have developed for generating SAR backscatter and interferometric products. The presented approach is efficient, cost-effective, and highly scalable; and is suited for handling, in near-realtime, large volumes of SAR data that are expected to be acquired by missions such as Sentinel-1, NISAR, and other commercial providers in the near future.