Subswath and frame SENTINEL 1

Hi all
We are working with temporal series analysis in Izmit Bay-Türkiye from 2018 to 2023. In the Descending mode we were using the PATH 36 FRAME 464 in 2018-2019-2020-2021 but in 2022 it changed and our area is localised now in the PATH 36 FRAMES 462 and 467… my question is why is the reason to this change, somebody has idea? after, from November 2023 the images dont has the subswath IW3, and its size change to + 7 GB, why?

check the orbit track of S-1

Hi,

The Sentinel-1 data are acquired as long “data takes” on the same acquisition mode and polarisation (here on IW mode with dual polarisation DV).
The data are split on ground into slices of same size (expect for the last one of the data take) to ensure a seamless continuity from one slice to another.
For TOPS SLC products, one burst is present into one single slice (not on two successive slices).
For TOPS GRD products, the images are continuous.

It is likely that there was a change of acquisition plan in 2022 (), leading to different location of the start of the data take and then changing the location of the slice cut. However the bursts are unchanged. One given burst acquired on a specific cycle will be available at the same location on other cycles (assuming there was in fact an acquisition). However the product in which this slice will be available may have a different coverage as the initial product.
(
) more specifically after the failure of Sentinel-1B in decembre 2021, the mission acquisition plan was updated to partially compensate for the operation using only Sentinel-1A

The theoretical location of the bursts can be found in the Burst ID map available here:
https://sar-mpc.eu/test-data-sets/

For what concerns the sub swath IW3, I do believe this is an issue with SNAP, maybe not recognizing the files corresponding to IW3 sub swath within the zip file.
At least the Copernicus Data Space Ecosystems shows that the measurement files for subs wath 3 are available.

I suggest your to check the format of the zip. Maybe uncompressing and recompressing it ?

Hi,

Regarding the file size increase, the Copernicus Data Space Ecosystem (CDSE) uses the zip format as a way to distribute multiple files (the content of the SAFE) as a single archive but they do not apply any compression, whereas the zip files previously distributed on scihub.copernicus.eu had compression enabled. The switch between scihub.copernicus.eu and the CDSE happened in November 2023, so that would explain the size difference.

The problem has been reported by several users on the CDSE forum, for example: https://helpcenter.dataspace.copernicus.eu/hc/en-gb/community/posts/14515808649757-Changes-in-Sentinel-1-SLC-product-zip-file

In that thread CDSE support says that compression would be enabled by the end of February 2024, but it does not seem to be the case yet. If download bandwidth is the issue you will have to wait until CDSE implements compression unfortunately. If local storage is the problem, then uncompressing and recompressing the zip as suggested by @ghajduch should reduce the size of the file significantly.

As for the IW3 sub-swath, other users have been facing the same issue and the workaround for now is to uncompress the files manually before opening them in SNAP, according to the following discussions:

2 Likes