Hi,

Thanks for your question. This is quite a difficult concept to answer, but, to put it simply when you make a request, a bounding box of a geometry is requested and the pixels not in the geometry but within the bounding box are labelled no data. Therefore:

• 
  sampleCount = width * height (always the bounding box of the request, be it bbox or geometry that is being requested)


• 
  noDataCount = sampleCount - no. of pixels in the geometry
  

I hope this answers your question. Let me know if you need a more detailed explanation and I can run through an example of the concept for you.

Thank you, this helps.

For my use case, daily statistics from S2L2A data with custom noData mask derived from CLM and SLC, I’m interested also in the daily number of no-data pixel within the geometry.

Getting that value would be nice improvement to the API.

Is there currently any other way to get that information than to assume that in the time-series the date when noDataCount gets it’s minimum value is completely cloud free and derive the total number of pixels within the geometry accordingly?

• 
  no. of pixels outside the geometry = min(noDataCount)
  
  thus


• number of no-data-pixels in geometry = noDataCount - min(nodataCount)

I had the same issue. I’m fetching Sentinel-1 and Sentienl-2 stats for parcels. My current workaround is to use sampleCount and noDataCount from Sentinel-1 stats to determine the number of no-data pixels within the geometry to get Sentinel-2 cloud coverage within the parcel.

Is there a more robust way to determine the number of pixels that the geometry corresponds to?

Hi,

The inability to determine where the dataMask comes from is a known issue and we will upgrade the dataMask to provide the information indicating if the nodata comes from the lack of observations v. from the clipping of geometry.

However, we don’t have an ETA for the upgrade. Sorry for the inconvenience.

No worries! Thanks for the update