Hello,
what kind of data is Landsat8 Thermal dataset in Sentinel-hub? I find that it might by B10 in configutration utility script. Is it correct? This means that values are DN that can be transformed to temperature (e.g. described here: https://www.esri.com/arcgis-blog/products/product/analytics/deriving-temperature-from-landsat-8-thermal-bands-tirs/ )
Or is this Level 2 Science product (https://landsat.usgs.gov/landsat-surface-temperature)?
Any idea?
Hello Roman,
Landsat 8 Thermal is indeed based on B10 band. It’s not DN, but it’s already transformed to temperature in Kelvins based on the formula you provided on your link. If you use product THERMAL.INDEX you can get temperature directly into TIF file.
Great to know, thanks for answer!
However, I strugle to download Index values. I use configurator and when I use “INDEX” script, it is empty. Grayscale visualisation works normally. Do you have idea where the problem is?
Thanks!
I have the same issue, when using the Thermal Index script all pixels have the same value 147
Can you provide one such example call, so that we look into it?
Do mask the instance ID when providing the answer.
I am using the sentinel-hub python api. with the polygon that is a the end of this text and the landsat thermal index default configuration and querying for this date 2015-02-01. the request is a WcsRequest with alpha layer and clipping to polygon… When a one date request is performed and there are overlapping images the WcsRequest returns only one instead of two, the returned image has all its thermal pixels set to 147. If one performs a search for a range including the date of interest (±1 day) the WcsRequest returns two images one with the faulty pixels and another with correct values. Same happens if a quality layer “return [decodeLs8Qa(BQA).cloudConfidence*0.33];” if queried.
I am guessing that the faulty images come for the tile where the polygon is at the limit of the tile where some landsat bands do not overlap perfectly
Is it there any possible solution?
Kind regards!
{
“type”: “Polygon”,
“coordinates”: [
[
[ -64.34896908689133, -33.826251918035908 ],
[ -64.339746933410339, -33.826199618488758 ],
[ -64.339642334316039, -33.835090541504464 ],
[ -64.349248017809472, -33.835195140598763 ],
[ -64.349143418715173, -33.834741877856786 ],
[ -64.34896908689133, -33.826251918035908 ]
]
]
}
We would need an actual Sentinel Hub request to dive into this.
E.g. something like
https://services.sentinel-hub.com/ogc/wcs/6121c5eb-3b26-MASKED?coverage=TRUE-COLOR-S2-L1C&request=GetCoverage&crs=EPSG%3A32736&bbox=241797.55233011098%2C10008521.64536119%2C251721.8032413172%2C10018416.847597253&format=image/png&maxcc=100&resy=10m&version=1.1.2&resx=10m&transparent=False&showlogo=False&service=wcs&time=2018-09-30/2018-09-30
If you are not able to get an example, you can try the following:
Here is the wcs request
The “THERMAL” layer / coverage is the default configuration for Landsat-8 thermal index. In this case as the request is different form the one I do at the python api, all values are 65535 instead of 147
Thank you. Looking briefly it seems there might be a bug on our side. We will check and come back.
Just a few additional comments (not impacting this issue, but in general):
Thanks for the reply, I just saw that the date was not the one I meant (2015-02-01), but nice you could work it out anyway. Thanks for the 10m advice, the url was from another request and I just modified some important parameters.
Do you have any resolution time for that bug?
Kind regards!
Not for the moment as the bug needs to be analyzed. It (probably) is a bug and bugs usually have high priority in our workflow. However, it seems to be a very specific bug, affecting extremely small part of our users…
I will inform you, once we have more information.
You can avoid this issue by using 32-bit format ( FORMAT=image/tiff;depth=32f) for now.
We will update this thread once it is fixed for others as well.
Hello @gmilcinski, that request solves the problem with the wcs request in the browser, but it does not in the sentinelhub-py wcs request.
Is it any workaround for that?
The request I do using sentinelhub-py has this parameters, if you check the values of the first image returned on the list (corresponding to day 2015-01-16) you will see that all returned values within the polygon are 147.51712.
wfs_iterator:{
base_url:‘https://services.sentinel-hub.com/ogc/’
}
layer:THERMAL
bbox:-64.275065,-33.005537,-64.260992,-32.995863
time:(‘2015-01-07’, ‘2015-04-17’)
data_source:DataSource.LANDSAT8
maxcc:0.7
image_format: MimeType.TIFF_d32f
service_type: ServiceType.WCS
size_x: 30m
size_y: 30m
custom_url_params :{
<CustomUrlParam.GEOMETRY: ‘Geometry’>: shapely polygon**,
<CustomUrlParam.TRANSPARENT: ‘Transparent’>: True
}
**shapely polygon wkt is POLYGON ((-64.275065 -33.002974, -64.27294999999999 -32.995863, -64.260992 -32.998138, -64.26277 -33.005537, -64.275065 -33.002974))
Hi @misael and@Roman ,
we have finally found time to analyze this (sorry for a delay, but lots of other critical things).
This issue is related to the way how OGC services try to stretch values:
https://www.sentinel-hub.com/faq/how-are-values-calculated-within-sentinel-hub-and-how-are-they-returned-output
In case of thermal band val is a temperature in K, so around 300. As this is more than 1, all the values in the returned index will be 1.
You therefore have to divide the value before passing it to the output, e.g. with 400 or so to be certain it is below 1.
Even better, we suggest you use our latest version of the API, which does not do these auto-stretching anymore.
https://docs.sentinel-hub.com/api/latest/
Hello,
I see that this discussion is quite old but I did not find another one related to my question…
Actually I would like to write a custom script which used B10 and B11 from Landsat8 images but my script dos not return what it is supposed to do.
Ideally I would need a 8-bits value (or a 16-bits one) but it seems that it is not the case for B10 and B11 as it is for the other 9 bands. Could you confirm it please ? And let me know what is the value contained in B10 and B11 or how to convert it ?
Thank you very much for your help
Hi Ingrid,
Hopefully I can try and help you but I’m not exactly sure what you want to extract? Are you willing to share the custom script or explain in a little more detail what you wish to do in the script?
In the meantime, we recently added some examples for Landsat 8 in the documentation that can be found here:
You can parse these examples into the Request Builder site and then adjust the custom script in there to your requirements.
Also, a new feature if you toggle on the Data Product option in the custom script box you can find some other examples of thermal visualizations that maybe useful to you 
Hope this all helps, and if you have anymore questions, I’ll be happy to help
Will
Thank you William for you reply,
Actually I see here (https://docs.sentinel-hub.com/api/latest/data/landsat-8/) that values for B10 and B11 are in Kelvin. Can you confirm it ?
If it’s true, can you tell me how to convert B10 and B11 values into 16bits reflectance values please? Indeed, since my script is the result of a machine learning model that has been trained on 16-bits reflectance values, for all Landsat8 bands, I need to apply it on this type of value to get the good prediction.
Thank you very much again for your help
Ingrid
Hi Ingrid,
Yes I can confirm that the B10 and B11 values are in Kelvin.
Unfortunately, I don’t think it is possible within the platform to use reflectance values as we only provide the Kelvin value. To do this would require metadata coefficients that aren’t stored by us. I will try and confirm this with another member of the team but if I understand what you’re trying to do, I don’t think it is possible at the current time.
Best
William
Hi, Would you please confirm the equation used to convert from B10 to degrees C as is displayed in EO Browser?
I use the following equation (taken from https://www.usgs.gov/faqs/how-do-i-use-a-scale-factor-landsat-level-2-science-products):
Temperature in degrees celsius = B10 * 0.00341802 + 149.0 - 273.15
When I compute this myself on the image that EO Browser references (e.g., s3://usgs-landsat/collection02/level-2/standard/oli-tirs/2023/035/033/LC09_L2SP_035033_20230608_20230610_02_T1/
LC09_L2SP_035033_20230608_20230610_02_T1_ST_B10.TIF) my results are consistently 0.17 degrees C lower than the values extracted with the “Statistical Info” tool in EO Browser.
Are you using a different equation to convert from DN to temperature in degrees C?
Thank you!
Hi Tyler,
If you click on the small edit button of the layer in the EO Browser, you can see the Evalscript and thus the formula that is used for the Statistical tool (see the red circle in the figure below).
The conversion here is: B10 - 273, which explains the differences that you get with the formula you apply (the difference should be 0.15 not 0.17). If you want to apply your formula, you can edit the Evalscript (line 35) and hit the Refresh button.
