It seems we have to interpolate the solar and viewing (azimuth) angles from the metadata grid (5000m resolution) to get the proper values of a given pixel, isn’t it?
Is there any simple way to do so?
I think the simplest way is to resample the product to the desired resolution (Raster -> Geometric Operations -> Resampling). This way the band grids and the angles grids will have the same width and height.
Thanks a lot, it is exactly what I wanted in using the bilinear interpolation option in the Resampling module.
Actually, azimuth angles are still not satisfactory (both viewing and solar). You may notice in the attachment that azimuth exhibits kind of square shapes whereas reflectance image (here in B8a) shows a demarcation following a straight line.
What do you think? Should the interpolation (resampling) be performed on a per-granule (tile) basis?
all the best,
You should not see this effect for the solar angles (zenith and azimuth) since they do not depend on the detector id.
The actual issue behind this is that the S2 products, in their current format, do not provide the necessary information to affect a correct viewing azimuth to each pixel, because there is no way to know, for a given pixel, from which detector data it has been resampled.
The only data we have at hand are the detector footprints masks, in vector format, but those are not what we need. They represent the individual detector swaths, and they overlap, with no clear way to know what happens in the overlap area (due to the orthorectification process, the overlap area is not a simple rectangle).
Up to now, this is more or less the best we can provide in SNAP w.r.t the current S2 product format.
I do hope this will change with future PDGS updates.
Do you know the criteria used to determine which detector is used in the overlap area. I currently make the assumption its in the center of the overlap. But visual inspection shows this is easily a few hundred meters off. If this is indeed due to orthorectification, would orthorectifying the detector footprints improve this?
If it was not for the ovelap of the detector footprint (the DETFOO files), we would have really what is necessary to get the viewing angles for each pixel, even if it needs a few lines of code. It is a bug I emailed to ESA more than a year ago, but it is not given top priority as it seems.
So up to now, we use the same strategy as Rutger, we cut in the middle of the overlap region. For the atmospheric correction over land, an accuracy of one degree is enough, so for each detector, we compute the average of azimuth and zenith viewing angles (taking care of the special cases when zenith is close to zero).
But I guess Tristan wants to compute sun glint contribution which probably needs more accuracy.
Over land you can see the effect of switching detector especially in band 1. Here’s an example, where the blue lines are the original detector footprints and the red line is the center between them. If the difference is this big, you can almost use some image analysis to detect it from the jump in values itself. But for most bands the difference is a lot smaller.
I would say that accurate geometry data are a key point to analyze (correct for or get info from) sun specular reflection on sea or lake surfaces with numerous applications such as oil spill monitoring, wind assessment, ocean color…
Below an example of a simple two band difference where we can readily see the consequence of the detector change. Info on a per pixel-basis would permit to correct for the geometrical changes between bands hopefully or at at least to flag the impacted zone of the image.