Design of S1 CSLC in geocoded coordinates.

[vbrancat]

Some thoughts on the interface for geocoded S1-A/B CSLCs.

Problem we want to solve
Let' assume we have N frames (SAFE) for a static stack covering an Area of Interest (AoI). The SAS should geocode the burst with specified burst_id. All the bursts with same burst_id belonging to different dates should be geocoded on the same geogrid.

It is desirable that the SAS will handle invalid data in each burst (this will make stitching much easier). Therefore, the SAS should extract the valid data portion of each burst and geocode it on the assigned geogrid.

Interface with PCM/PGE
The SAS will accept as an input:

• One or more zip files for one date
• The orbit file covering the date in the input zip files
• The DEM for processing
• List of burst ID to process
• a processing section including operations to be performed (e.g. geocoding)

Functionalities we want to include in the processing section

1. A section geocode including all the parameters necessary to perform geocode.

   • output epsg
   • x and y postings
   • x and y top left coordinates
   • x and y bottom right coordinates
   • lines per block for block processing
   • dem margin
   • geo2rdr threshold
   • geo2rdr number of iterations
   • Boolean flag for flattening
     If the parameters necessary to create a geogrid are not assigned, as a deafult, we can use the burst polygon border to generate the geogrid with some default x and y spacings.

2. A section of split-spectrum. This functionality should be optional i.e., the user can decide to turn it on or off. If split-spectrum is activated, the SAS will extract the valid portion of each burst, split its spectrum, and generate a temporary output file containing 3 bands: the lower burst band, the main band, the high band. The SAS will then geocode all three bands.
   This section will include:

• enabled: a Boolean flag to enable/disable split-spectrum
• bandwidth fraction: how much we want to split the spectrum (e.g. 1/3)
• window_function: window to use to taper the spectrum.
• window_shape: parameter defining the window shape

Note that S1-A/B metadata have info on the window used during image formation. To taper the spectrum, we should use the same window as specified in the metadata. This will require to expose this functionality in the reader.

Anything else I am missing?

[hfattahi]

@vbrancat this looks good and seems to cover the basic configuration needed. Two extra design points that we discussed offline to some extent and could be documented here for more clarity are the following:

1- The geocoded bursts must be stackable
By this I mean that when we geocode multiple bursts (same ID) through time, we should be able to conveniently have access to the cube of the geocoded bursts without any need for extra interpolations of the rasters. In the following plots I have tried to show the different possible situations. On the left we have two geocoded bursts (same ID) at two different times. On the right there are three different situations for the two geocoded bursts.

• a) The first shows that the grid of the two geocoded bursts are not aligned, i.e., the grids are shifted by a fraction of the spacing and therefore not stackable. This situation should be avoided in our implementation.
• b) The second is the case where two grids are aligned and have the same spacing but they may have different start points and they may have different shapes, i.e., the difference of the start points of the two grids are always an integer multiple of the spacing. This situation can be achieved by setting a snap which ensures that the starting point of each grid is an integer multiple of the spacing. The higher level workflows can achieve a cube by simply subsetting the geocoded bursts without any need for extra interpolation.
• c) The third option shows a situation where the two geocoded bursts are aligned and have the same start points, spacing and shape. This is the most user-friendly option for downstream workflows but may impose extra complexity and can be only achieved with predefined geocoded grids including the predefined geocoded grid start, spacing and shape.

2- The geocoded bursts must be easy to mosaic without need for interpolation (resampling)

Mosaicking the geocoded bursts should not require extra interpolation. The following plot shows the two geocoded grids and two different possible situations.

• a) in the first case the grid of the two geocoded busrts are not aligned with the grid of the background mosaic. This is not a preferred situation and should be avoided in our implementation.
• b) the second is the case where the two geocoded bursts are aligned with the background mosaic's grid. This is the preferred situation which eliminates interpolations during mosaicking. This situation can be achieved if the difference of the start points of the two grids are multiple integers of the spacing. In practice this can be easily achieved by enforcing grid start points to be the multiple integer of the spacing

In summary I think by ensuring the top-left corners to be integer multiple of the spacing, 1-b and 2-b conditions above can be realized. The SAS design will anyways allow for 1-c by providing the configuration parameters of the geocoded grid. However, defining those parameters and populating them in the SAS run configuration by the data system needs to be further discussed.

tagging @gshiroma @yunjunz @LiangJYu in case if they have more thoughts.