WCS request Landsat 8: whole return is only value 1' for NDVI'

Hello,

I have the following problem when doing a WCS request using Landsat 8 as data source:

the response I get for an request of NDVI only returns the value 1 (I also tried querying other layers).

The result looks like this:

NDVI response

[array([[1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1.],

[1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1.],

[1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1.],

[1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1.],

[1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.,

1., 1., 1., 1., 1., 1.],

…etc.

This happens for different time periods I’m querying.

Here an example query:

NDVI query

‘https://services-uswest2.sentinel-hub.com/ogc/wcs/INSTANCE_ID?SERVICE=wcs&MAXCC=100.0&BBOX=52.296387%2C10.768324%2C52.298786%2C10.776756&FORMAT=image%2Ftiff%3Bdepth%3D32f&CRS=EPSG%3A4326&TIME=2016-04-03T10%3A08%3A46%2F2016-04-03T10%3A08%3A46&RESX=15m&RESY=15m&COVERAGE=L8-L1C-EVI&REQUEST=GetCoverage&VERSION=1.1.2’

Do you know what’s going on?

Page 1 / 1

I believe the reason is in too short time interval. You have it set to:

TIME=2016-04-03T10:08:46/2016-04-03T10:08:46

But the time of specific scene is “10:08:46.823”.

This is then rounded up to 47 and you do not get any data…

Add a second to your query and it should work.

TIME=2016-04-03T10:08:46/2016-04-03T10:08:47

The example I gave was only one example query I got when calling the get_url_list() function on the data request.

The orginal data request was formulated as follows:

data_request = sentinelhub.data_request.WcsRequest(resx="15m",

                                                  resy = "15m", 

                                                  data_source = sentinelhub.constants.DataSource.LANDSAT8,

                                                  bbox = ss_bbox,

                                                  time=('2016-04-01', '2016-05-10'),

                                                  layer='L8-L1C-NDVI',

                                                  image_format=sentinelhub.constants.MimeType.TIFF_d32f,

                                                  instance_id=instance_id,

                                                  data_folder='./test')

And for every time step, the returned array only contains the value 1, like in the example NDVI response provided above.

I am not closely familiar with sentinelhub-py API (@maleksandrov might be able to help) so I do not know, whether it uses only date or date/time parameters in the call. Can you perhaps adjust the code to only use DATE? This should be perfectly sufficient for Landsat data. Or add also milliseconds to the call.

I am not sure if sentinelhub-py were tested actively with Landsat data.

@gmilcinski Thank you for your reply.

The thing is, the Landsat queries worked fine using this form of query until the beginning of this month.

On July 5th, I first started noticing that something weird with Landsat 8 was going on (see WCS request Landsat 8 error: Server response: "TYPENAME=DSS6 not found!"). At that time, not even a response was returned.

With this current problem, answers in form of only the values “1” are returned and images can also be downloaded but they are all containing the value “1” as well (as should be expected).

Maybe something in the background was changed which is handling the Landsat data?

I extended the checking of data queries and the same query for the date range (‘2019-04-01’, ‘2019-05-10’) only returns “1” as well.

The same query (using (‘2019-04-01’, ‘2019-05-10’)) works fine when replacing the data_source, layer and instance_id parameters for doing a query for Sentinel-2 L1C data.

If I change the time range to (‘2016-04-01’, ‘2016-05-10’) for Sentinel-2 data, the response suddenly also only contains “1”. After further investigation, it seems that data since 31.10.2016 backwards is corrupted. A Sentinel-2 query in in November 2016 works fine, but from end of October 2016 on backwards, the response only contains “1”.

In contrast a query for Landsat 8 data in 2019 is also returing “1”, so is not working properly.

Maybe that helps you.

It’s complicated…

For Landsat - we have indeed deployed a more strict rule related to the interpretation of TIME parameter on 1st of July (your observation on when this changed was most useful to identify the cause), requiring the user to take into account also milliseconds.

So for scene taken on “2019-04-19T10:14:44.91” one should either use

TIME = 2019-04-19T10:14:44.91/2019-04-19T10:14:44.91 or

TIME = 2019-04-19T10:14:44/2019-04-19T10:14:45

This does seem logical and correct. It did however break the sentinelhub-py workflow, which ignores information about milliseconds… It is never good to break something…

We are now looking into putting back the rule that if user sets:

TIME = 2019-04-19T10:14:44/2019-04-19T10:14:44 this would be interpreted as

TIME = 2019-04-19T10:14:44.000/2019-04-19T10:14:44.999

For Sentinel the problem is actually on your side.

When running WFS query (e.g. to get available dates at AOI) you do this on Sentinel-2 L1C datasource. However, when you go and fetch the actual data, you have the layer set-up for Sentinel-2 L2A. L2A data are available in Europe since cca September 2016 and global since December 2018. Outside of this range you get no value at all, resulting in NDVI=1 (see below).

And as a general comment - the reason, why you get only “1” is probably in division with 0 in NDVI formula. It would make sense to introduce a check in your script along the lines of
if (B04==0) return 0;

(or some other value that you interpret as an error in your code)

At least for Sentinel-2 a general rule applies that band values are 0 only when there is no value at all. I am not sure this is the case for Landsat-8 as well, but quite a decent chance it is.

Hi @schorcht, do note that the improvement is now deployed to production.

@gmilcinski Thank you very much for the fast fix and thorough explanation!

Everything is working again