@jmendrok
The problem with the L2A data in the sentinel hub is, that not all of the L1C are corrected. There is a pre-selection by ESA/Copernicus (?!). Unfortunately I didn’t get an answer how they select which image is worth to correct and which image is not. But a huge amount of L1C data are not corrected.
Hi guys
it is good to watch your conversation, it is already 2019 now, I wonder if there is an answer about the SR product in GEE, anything new? also, if we can’t use SR product lunch by GEE, is there an alternative option for us to generate our own SR product on GEE?
The ingested assets are already available in EE, we just have not yet added a catalog entry or ingested everything that we downloaded. It’ll take a few weeks to catch up. A copy on Cloud Storage is also available, it’s just not documented yet.
I found a little mistake in the GEE documentation. Where the bands are described it is said that the value range is 1 to 11 for the SCL band. But actually it is 0 to 11. 0 is no-data.
Marco - this is actually intentional. I used the value of 0 as the fill value to mask out such pixels in the SCL band. Do you think this would cause issues?
Probably not directly issues, but maybe confusion. As it caused for me.
So you have masked these pixels already. But I’m not sure if I understand this correctly. What does it mean in this case you have masked them out? What happens if one wants to get the value for such a pixel? Which value will he get? Or is it not possible to access such pixels?
I can add a note in the docs that 0 is masked out.
Each EE pixel retrieval operation returns a tuple (pixel_value, mask_value). If the pixel is fully present, mask=1. If the pixel is fully masked out, mask=0. If the pixel is partially masked out (which happens in pyramided layers that combine fully present and fully masked-out pixels at lower levels), 0 < mask < 1.
No one knows with which version of sen2cor the data has been processed. It is almost impossible to figure it out from the metadata shipped with the L2A products.
The latest internal sen2cor version is 2.8, as far as I know. The release of it was planned one month ago. But obviously, there is a delay for some reason.
Thank you Marco,
I know it is supper difficult to get this information from ESA but I remember last year i eventually managed to find this piece of information on the ESA website. At that time, the processor used for L2A data was very outdated and I ended up processing L1C to L2A myself. I am not sure whether ESA recalculated the archives since.
I find it interesting though that the internal sen2cor version is 2.8 whereas the one featured on the website now is 2.5.5 [http://step.esa.int/main/third-party-plugins-2/sen2cor/].
lets stay tuned
Grega: I was optimistic and set the start date to be the same as S2 L1 start date in the hope that eventually L1 for older assets will be generated as well. But if this is not going to happen in the next few months, yes, I will need to adjust the start date.
This will certainly not happen in the next few months as there is currently no plan set to do it at all. There are just a lot of wishes Based on past experience this means that in 2019 there will almost certainly not be anything else.