I have been working on Interferometry. I download the datasets from Alaska asf API and perform the interferometry processing. Things were working very smoothly until a week ago.
I am not sure if something has changed at the backend of the API but I found that last datasets were of bigger size (~7.5G) than usual (~4G). I am a bit surprised why is it so. Is it because of any compression failure?
I have recently opened up the dataset in SNAP here also IW3 is missing.
My AOI subsets in IW3. You can see for 2023-09-21, we have IW3 but not for 2023-10-03.
I have discovered that this is happening with almost every dataset after 25th September 2023.
Having a look to the content detail in the Copernicus Data Space Ecosystem (CDSE) portal, it looks like the product acquired on 2023-09-20 has indeed a size of 6930 MB (not 3.97 GB as reported by @harshal306 ) and that all the measurement files are present (cropped in my screenshot), that is one for each subswath and polarisation : 3 x 2 = 6
Then it looks like the complete product is available on CDSE but that for some reason, only part of the measurements are provided in the zip when downloading (and the quicklook as well).
I just raise here an hypothesis:
When downloading a product, CDSE performs first a zipping of the product (adding an overhead on the download, but that is another topic), and the zipper forgets to add some files.
So, I think this is not a platform/sensor/processing anomaly, but a transient issue with the CDSE download mechanism. I suggest that you report directly the issue to the CDSE support here (https://helpcenter.dataspace.copernicus.eu/hc/en-gb on submit a request)
Actually the 3.97G, I was talking about using the Alaska API (ASF Data Search).
I do agree on the Copernicus facility, the size shown is unzipped that’s why it is 6930M
However, Alaska provides the product in compressed format, I believe historic data is also around ~4G.
But this unusual spike in the size using Alaska API made me think of some issues.
I understand there is no problem with the sentinel-1 captures, the problem only belongs to the compression segment. I support your hypothesis.
nevertheless, thanks for the explanation, I will submit my query to Dataspace Copernicus directly.
Sorry for bothering.
Also, note that zip is not exactly a simple spec. zip files can be created in a number of ways. We can count atleast 6-7 number of variants of zip used for Sentinel-1 over the history of the mission, including one where data is not compressed but just organized in a zip file without compression. All of these are legitimate zipfiles and work with most zip-based sofftware. I would not worry too much about the size of the zip file as these are implementation dependent. We would however hope that the underlying zip files archived at different locations/ distribution centers are exactly the same for granular access.
