2

According to this page on Google Earth Engine documentation bit 10 is 1 for dense clouds, and bit 11 is 1 for cirrus. The documentation doesn't say anything about all the other 14 bits that can be set, but sends us to this ESA page that explains how QA60 is calculated. On the ESA page, it says that the end result is 0 for clear, 1 for dense clouds and 2 for cirrus. Obviously ESA's output is stored differently than Google's data. From this I take it that Google thought it's a better idea to store QA60 as a bitmask. ESA's output assumes that one pixel cannot be dense cloud and cirrus at the same time, Google's format doesn't.

From my research QA60 is stored on Google Earth Engine on 16 bits. The question is what are the other 14 bits set to, beside 10, and 11, which are dense clouds and cirrus, accordingly. If the other bits are not used, who in their right mind stores 2 bits of data on 16 bits, and starts with bit 10? I could understand 1 byte and start using the first, or the last 2 bits, but why use 16 bits and start in the middle?

Can I safely assume that only 1024 and 2048 values are possible? Or 1536 could also be possible? Or maybe some other values are also possible, which and what do they mean?

2

You are correct: the QA60 bitmask has a value of 1024 for opaque clouds and a value of 2048 for cirrus clouds.

The sentinel 2 products are distributed with vector masks that we converted into raster QA bands, reserving the first 9 bits for 3 per-band QA masks for 3 bands. Unfortunately, the source products don't have enough information (yet) for us to populate those 9 bits. We hope that someday we will get enough information to populate the QA bands.

In the meantime, yes, the useful data starts at the 10th bit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.