Italy area returning always transparent NDVI map

I’ve developed a call to Sentinel-2 L2A to obtain NDVI map of areas defined by their GeoJSON.

It works perfectly in 99% of my 200 areas but in 4/5 cases the same procedure returns NO ERROR but the all images returned (from 1 year past to 15 05 2024) on the availability dates are ALWAYS transparent.

This is one of the GeoJSON area returning transparent NDVI map.


Any idea on new possible cause?

The NDVI script is the one available on Sentinel-Hub documentation (LINK)

Hi Davide,

Please can you provide some specific examples, with replicable code if possible. It is not clear if this is a certain date or certain area of interest.

Dear William, thanls a lot for your attention.

This is my C# code:

 using (var httpClient = new HttpClient())
     using (var request = new HttpRequestMessage(new HttpMethod("POST"), _config.ProcessServiceURL))
         request.Headers.TryAddWithoutValidation("Authorization", "Bearer " + token);

         var multipartContent = new MultipartFormDataContent();
         var queryStr = JsonConvert.SerializeObject(req);
         multipartContent.Add(new StringContent(queryStr), "request");                        
         multipartContent.Add(new StringContent("//VERSION=3\n\nfunction setup() {\n   return {\n       input: [\"B04\", \"B08\", \"dataMask\"],\n       output: {bands: 4}\n     };\n}\n\nfunction evaluatePixel(sample) {\n   let ndvi = index(sample.B08, sample.B04);\n   let imgVals = null;\n \n   if (ndvi < -0.5) imgVals = [0.047, 0.047, 0.047];\n   else if (ndvi < .1) imgVals = [0.92, 0.92, 0.92];\n   else if (ndvi < 0.2) imgVals = [1, 0, 0];\n   else if (ndvi < 0.3) imgVals = [1, 0.18, 0];\n   else if (ndvi < 0.4) imgVals = [1, 0.55, 0];\n   else if (ndvi < 0.5) imgVals = [1, 0.65, 0];\n   else if (ndvi < 0.6) imgVals = [1,1,0];\n   else imgVals = [0, 0.27, 0];  \n   \n   imgVals.push(sample.dataMask)\n\n   return imgVals\n}"), "evalscript");
         request.Content = multipartContent;

         var response = await httpClient.SendAsync(request);
         string contentStr = await response.Content.ReadAsStringAsync();
         if (response.IsSuccessStatusCode)
             var responseBody = await response.Content.ReadAsByteArrayAsync();
             bytes = responseBody;
             message = contentStr;


In the particular case of the GeoJson area returning a void NDVI,


As I stated initially, this same code returns significative NDVI image in the 95% of the cases, only on some areas, indipendently from the period asked, always “transparent” values are returned-

Hello Davide,

Sentinel 2 has a revisit time of around 5 days. In the time frame you are requesting, there is simply no Sentinel 2 acquisition for the area. This is why the request returns a transparent image: because there is no data which could be returned.

Try extending your time of interest and you should get an image.

Dear Jonas,
the range date is obtained by a previous catalogue availability dates call on Sentinel2 on each particular area.
So, in my example the range date was 2024-05-10 | 2024-05-13 since BEFORE the Catalogue has indicated that there was a Sentinel2 acquisition on 2024-05-12.
So, I’m sure that on that range there 1 and only 1 image.

When I try to do a catalog request, I only get acquisitions on 8th and 13th of May. Could you double check your catalog request?

Dear Jonas,
currently my Catalogue request on Sentinel2 constellation on that area from one moth ago to today is giving me the following acquistion dates:
{17/05/2024 07:55:04}
{12/05/2024 07:55:10}
{07/05/2024 07:55:07}
{02/05/2024 07:55:09}
{27/04/2024 07:55:06}
{22/04/2024 07:55:10}

To be more specific, my area is defined in the http query as follows:


Please, could you clarify how did you obtain the dates of 8th and 13th May?
Thanks a lot,

PS: Please see the attached Catalogue response sample

Hello Davide,

in the request you have shared, the x and y coordinates for the polygon are switched. The Polygon is placed in the red sea and so you get the wrong S2 acquisitions


You can easily double check your requests using the Requests Builder

You’re right!
For some reason, the long and lat coordinates are inverted in this case…
The correct coordinates are [

but, transformed in my query, became