I just realized that some ESA-generated L2 products for 2018 (eg, S2B_MSIL2A_20180815T102019_N0208_R065_T32TLS_20180815T172127) have the SCL band with type UInt16, while 2019 products (eg, S2B_MSIL2A_20190111T231819_N0211_R058_T52CDS_20190112T002953) have SCL with type Byte.
This breaks computations involving the SCL band in Earth Engine. Does anyone know more about this discrepancy?
I can confirm you observation with th data types.
I had a look at several S2A products and they all use unit8 as data type. E.g. S2A_MSIL2A_20170424T101031_N0204_R022_T33UUV_20170424T101120
For S2B I found a product which has unit8 too (S2B_MSIL2A_20180421T100029_N0207_R122_T33UVR_20180421T120642).
So it seems that S2A always had unit8 and S2B had inbetween int16.
As the value range is only 0 to 11 uint8 should be the right data type. I think you can safely downcast the data in your code.
Thanks! I will need to do this before ingestion.
I note this Copernicus News item from last September:
"Users are informed that a minor update on Sentinel-2 L2A products is going to be implemented to optimise the encoding of the quality bands (SCL, CLD, SNW, PVI, TCI) over 8 bits instead of 16 bits, in line with the Sentinel-2 L1C products.
All L2A products generated as of 19 September 2018 will feature this small change which is compliant to the SNAP software tool. "
S2MPC Operations Manager