We have a bunch of zipped Sentinel-3 OLCI legacy files with filenames ending “.zip” and not “.SEN3.zip”.
If I’m not mistaken those files could be directly opened (drag&drop) in older versions of SNAP. The current Linux version 14.0.0 and also v13 do not correctly geolocate those files.
The reader seems to need either the extension “.SEN3.zip” in the filename or the xfdumanifest.xml from the unpacked archive has to be used to read the file.
We get data through the eumdac python library. the zip files differ to the ones downloaded from dataspace.copernicus.eu. The eumdac downloads include a quicklook and two more xml files alongside the SEN3 folder.
When “.SEN3” is removed from the filename of a download from the copernicus browser, SNAP cannot even find an appropriate reader anymore.
I just didnt expect that SNAP relies on the SEN3 extension in the zipfile name to be able to read a product. Maybe this can be added (again)?
sorry to hear that. The official naming convention for OLCI data can be found here:
and this is what SNAP follows. It clearly states that .SEN3 is an integral part of the product name.
Despite the naming issue, you also mentioned that the data could not be geolocated, which I find strange. Can you please make one of these files available to us? I’d like to further investigate on that.
okay, thanks. I thought this was referring to the .SEN3 folder name inside the zip file and not the zip file itself, which isnt explicitly mentioned in the product description. Anyway, we’ll deal with that.
Regarding the geolocation issue. This is connected to “.SEN3” missing from the zip file name of products downloaded via eumdac. However, its a self made bug on our side as we modify the filename to match our older archived data. Everything works with zip files ending “.SEN3.zip”
We are checking the file naming pattern (amongst other things) to identify the ProductReader to be used for the data the user requests. And for OLCI this is compares against the pattern defined by ESA. We could adapt this to cover your naming convention, but this is a sensible step as we have hundreds of formats supported and things quickly interfere and lead to odd decisions. Plus, this detection has to be accomplished in milliseconds to give a pleasant user experience.