The view and sun geometry angles provided with an Earth observation scene are important for numerous applications. Like atmospheric correction, surface reflectance normalisation and others.
Unfortunately, this information is not directly accessible for Sentinel-2 data. The angles are stored on a 23x23 grid with a ground resolution of 5000m. Also, in case of the view angles, the detector footprints need to be considered when these angle values are resampled to the resolution of the corresponding band.
Let's start with detector footprints.
The image above shows the detector footprints of the seven different detectors used for taking the image of band B5.
The view zenith and azimuth angles, which are provided for each detector at the low-resolution grid, need to be resampled only within the bounds of the detector.
After resampling the angles within the detector footprints and combining them into one raster the actual view azimuth looks like this:
Unfortunately, not all services and applications consider the band detector footprints when providing view angles to the data user. According to the SentinelHub documentation, the grids are just resampled using nearest neighbour, which leads to view azimuth raster like the following.
In Google Earth Engine it is even worth. There only a single average value is provided per band.
This means you get a constant value of, e.g., 106.925, even the angles range from 91.762 and 136.102. This is a significant difference.
So, you need to be careful when using the geometry angles of Sentinel-2. Check how they are provided to you.
This special up-scaling of the geometry angles is now implemented in the EOMasters Toolbox Pro for ESA SNAP. This means that the viewing angles can now be correctly scaled up for each band without having to resample the product to a common resolution.
Also, the process of scaling the geometries and resampling the data afterwards should be faster compared to the SNAP integrated S2Resampling operation. Unfortunately, this benefit does not get effective due to issues in SNAP's Graph Processing Framework.
When using GPF for writing the processing is slowed down. I've reported this in the STEP forum.
When using a simple main which calls the operators and other means to write the data, the performance difference is significant.
I've also provided some code changes to the development team, which might be included in the next release and hopefully improve the overall performance of SNAP.
However, I provide a simple to use workaround. On GitHub I've implemented a template project which can be used for defining the processing chain and letting the process run from the command line. It is not faster for all types of processing, but it is worth to try it for your processing. You can gain a six times faster performance.
This implementation supports the standard Sentinel-2 L1C and L2A data provided by ESA/Copernicus. Theoretically this can also support L2A data from Theia in the Muscate format. Unfortunately, this data does not provide correct detector footprints for the surface reflectance bands. This issue has already been reported.
The S2 L2A product provides the B1 reflectance data at an up-sampled resolution of 20m and the specific masks, like detector footprints, still at the native resolution of 60m. Due to this incompatibility and the reason that SNAP is not correcting this, the view geometry information of B1 is not usable. You might want to read the discussions I had about this issue.
More general information about this release can be found in the other blog:
The EOMasters Toolbox Pro is available in the EOMasters Shop. You can activate a trial version when installing the plugin in SNAP. Simply request the trial key and decide after the trial period if you want to purchase it.
Tschüss & Goodbye
Marco
Comments