Visual representation of the tabular data set

Hi,

In principle Sentinel Hub is capable of providing data for the scenarios you mentioned.

To address your questions:

1. Based on the example geometry you provided, the optimal way would be to use Sentinel Hub Batch processing API as you rightly presumed. The median mosaic can be defined and calculated within an Evalscript, the mosaic will then be processed as tiles (of one of this sizes ) that cover your geometry and delivered directly to a specified object storage. The data can then be accessed directly from the object storage or as Sentinel Hub layers, depending on how the data is to be used. If you haven’t come across it yet, you can have a look at examples of cloudless mosaics evalscripts in this cloudless mosaic blog post.

Regarding the dynamic time -range case, by ‘‘cloudless pixels percentage’’ does this refer to the percentage of pixels based on the whole AOI (as in spatially) or per pixel (as in temporal wise) ? For the former case, one option is to use Sentinel Hub statistical API to determine the percentage of cloudy pixels within the AOI.

2. I imagine temporal imputation really depends on the availability of valid pixels. Within an evalscript this can be achieved by fetching valid pixels within a time range and performing a linear interpolation. In this blog post you can find an example of such an evalscript.

3. As mentioned above, Batch Processing output is always delivered in tiles to an S3 bucket which will overlap your geometry. See the screenshot below. If by stitching you mean merging the processed tiles into one image ? this can be easily done with tools like QGIS or with such an example script .

4. For this I would suggest using the statistical API, It takes input geometries and outputs band statistics (e.g mean value) which can be aggregated per day. At native resolution and for a single date, the mean value would simply be the actual pixel value. Assuming that the field samples are point coordinates, these can be converted to bounding boxes and defined in such a way that each bbox is within a Sentinel 2 pixel. The output is in json format, which is versatile to work with.

I would recommend that you first test your workflow with Processing API on a smaller AOI (for this your current trial subscription is sufficient), then you can scale up with Batch Processing API once you determine the results are as anticipated .

Hope that gives you a better insight, please do get back to us if you need further clarifications

All the best

Hi,

Thank you very much for your answer.

1. We read the cloudless mosaic blog post, and tested the eval scripts with Processing API on smaller AOIs. It works as expected.

Regarding dynamic time range, I refer to the spatial-wise percentage. So, I expect an example algorithm works as follows:

• Construct a 7-day mosaic.
• Check if the cloudless pixel percentage is greater than the pre-specified threshold. If it is, download the tiles into the S3 bucket.
• If the cloudless pixel percentage is less than the pre-specified threshold, wait for one more week.
• Construct a 14-day mosaic.

… and so on. We aim to maximize the frequency of mosaics for a given AOI to get time-series information as much as possible. If you have any suggestions regarding this, we are more than welcome.

2. Once we construct the mosaics with the algorithm above, I expect we will have valid pixels available in most cases. Therefore, I assumed that it is possible.

3. Exactly, I mean merging processed tiles into a single image. Thank you for the reference script. We agree that it can be done easily.

4. That is great! I have a follow-up question. Can we adjust the Statistical API workflow based on one of the scenarios mentioned above? The values written on the database have to be compatible with the downloaded images. Also, do you have a reference post about how the workflow looks like? Or, could you please elaborate more on how we ensure the integration with the PostgreSQL database on Amazon Web Services.

My colleague is already testing the Processing API on smaller AOIs. We are trying to figure out realistic parameters for the scenarios. Then, we can scale up for the batch process.

Thank you very much. Your answer really helps.

Looking forward to hearing from you,

Kind regards
 

Great that you are having a bit of success on this, it is always worth to start with small scale then scaling up. To answer your follow up question, yes, here are the possibilities:

• It is convenient that with Batch Processing, the output data stored in the bucket can be re-ingested back to Sentinel hub as private collections, with the create collection option. From these collections (mosaics) the band values can then be extracted on the fly with Statistical API


• Alternatively, especially from 1 &3 scenarios where the date range is fixed, you can extract the ‘median’ values (on the fly) without having to actually download the mosaic images or use the downloaded ones.You just need to specify the same script in Statistical request, as the one used for downloading the mosaics.


• Statistical API is mentioned (or used ) quite a lot in this Area Monitoring blog series , but also the examples provided here provides a typical workflow.


• I believe Python provides several integration possibilities, since the output JSON format can be easily read into any format, I believe PostgreSQL too. You will surely find more insights on this from Google Search.

Best regards

Hi,

Thank you very much for your answers.
Kind regards