API request count for different dates

Statistical API (FIS) is basically a wrapper, which first checks, which dates are available and then executes WCS request for each individual date. FIS requests over long time period therefore count as multiple requests.
In the case you have described, it is certainly better to only query the dates, which you actually need.
See also this FAQ item about “requests”.

Thanks again for a quick reply. I hope that other users will also find our discussion useful. Just a note: It would be very helpful having a more detailed description about the API request counting. Maybe even with examples.

But for now, Let me give you an exact example of my task:
Based on band 10 I want to locate images without dense cloud coverage over a given field for entire season. My approach was to do a FIS request, some tresholding on the B10 based on which I select dates of interest. Afterwards, download/display only images for these dates.
Based on your words, I am no longer sure if this safes the computational time and the Number of requests necessary.
thanks ahead,
 

I believe this discussion is useful for others as well and I appreciate you choosing the forum for this topic.

For your case specifically it seems that you actually have to analyze all available data so that you get best date selection. For this FIS is probably the best option (and we recommend it generally to users). When thinking about “costs” it is probably important to count also the costs on your side. E.g. if you would download all the scenes and then do a selection on your side, you would need to compute/store this. So all in all I believe the way how you are doing it now, is the best possible option.

One thing you can perhaps do is to run FIS on lower resolution. E.g. cloud statistics are comparable on 60m (if you are using B10, you should obviously not use 10m) as well as on 120m or even lower resolution. This will improve performance of the requests and “spent” less “requests”.

One important point to make here is that the whole “accounting” part is quite a bit tricky and we are still exploring best options, based on the patterns of use and underlying costs. This is why we are not too strict with our users about it. We do monitor it regularly and if we see that there are significant higher volumes than subscribed for, we analyze it and discuss with each user individually how best to approach and address it.

Perfect answer, thanks again.