Google Earth Engine Open-Source Code for Land Surface Temperature Estimation from the Landsat Series

Round 1

Reviewer 1 Report

I found the manuscript is well written and useful of LST applications, but there is still some concerns need to be respond:

1. The single channel method used in high resolution LST retrieval should be fully presented in the Introduction part, such as Chinese HJ-1B satellite datasets.
2. The TCWV datasets might not enough for the high resolution LST retrieval, neither in temporal or spatial resolution.
3. Have the authors considered the terrain effect and near neighbor effect for the LST retrieval in high spatial resolution satellite dataset?
4. Although the authors have considered the Landsat calibration differences, it should be better for the users if the publicly code give the calibration suggestions such as the sensor shift and different calibration error among different sensors.
5. The authors liked to describe some coefficients using the references instead of display the equation sequence number and coefficients together. The readers might be confused by those things.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

This is an excellent and detailed paper that synthesizes multiple prior contributions to single-channel estimation of land surface temperature (LST). I have minor comments, below, that I hope you will address to the benefit of your readers.

Line 30: You write: "including mapping the extent and intensity of urban climate..." but what is the "extent...of urban climate?" I think perhaps you meant two different things: "including mapping urban extent and the intensity of urban micro-climates..."

Lines 50-52: These lines seem a little too detailed for the Introduction. Perhaps they could be moved to the end of the paper in a section dedicated to the technical implementation? Perhaps Section 2.2.3? Also, GEE has two (2) different application programming interfaces (APIs): one written in Javascript and another in Python; please distinguish between these two APIs when giving detailed instructions such as "users only need to add a 'require(...)' command." Is the module available for both languages or only one?

Lines 56-60: Please verify that you have appropriately cited all these datasets. U.S. Government sources sometimes only require an acknowledgement of the institution that created the dataset, but they do have very specific guidelines about the wording used. Other datasets may expect you to cite a peer-reviewed paper.

Lines 76: "...using the respective calibration coefficients." Please clarify that you mean (I think) that the TOA data are produced by converting the digital number data to at-sensor radiance.

Lines 77-78: Please remind readers that the USGS has done all of this processing for them already and the TOA data are available in GEE. Some readers might get the impression that these are processing steps *you* took or they might have to take in order to reproduce your work.

Lines 89-91: You write: "Here we choose to use the low-gain version which has lower radiometric resolution but higher dynamic range and, therefore, prevents saturation at high brightness temperatures." I think this needs a citation, even if this just comes from the ATBD for Landast 7 TIR.

Line 146: "FVC values for each Landsat are computed..." For each Landsat...band? Separately for each Landsat satellite/ platform?

Line 163: It's been awhile since these acronyms were used--perhaps you could help the reader out by writing "...developed by CM-SAF for the MFG and MSG satellites..."

Line 182: Please clarify that "LST-Tair" refers to the difference between LST and the air temperature (Tair).

Lines 184-187: The set of 257 profiles/ 17,990 cases spans the LST and TSWV classes? Or is it 257 profiles/ 17,990 cases for each unique pair of LST-TSWV classes? I'm trying to get a sense of the sample size for each regression. It's apparent that a different regression is performed for each LST-TCWV class described in Step 1 (Lines 174-175)? Is that correct? Please provide more detail. While a table would be helpful, if that increases the length of the paper too much or exceeds figure-table allotments, perhaps you could just specify a range of sample sizes from the smallest to largest and comment on whether there is a pattern with respect to LST and TSWV classes, e.g., are the lowest TCWV cases less common?

Lines 246-255: It's apparent that you are using both emissivity derived from ASTER and FVC derived from Landsat to validate a product that depends both on emissivity from ASTER (at least in some versions) and FVC derived from Landsat. Is the intent to control for the variability in these quantities (emissivity and vegetation cover)? Because it also suggests the correlation between the calculated in situ LST and your satellite-derived LST will be, in part, due to the use of the same driver data. I don't think this is a serious issue--I expect that satellite-derived emissivity and FVC are often used to derive LST from in situ sites--but please comment on the choices you made here and the implications for the independence of your validation. For instance, why not derive FVC using the same "high-resolution flight imagery available on GEE" (Lines 263-264) as used to derive LST at the KIT sites? You partially address this on Lines 435-436.

Line 282: Does the sample size refer to the number of pixels or the number of profiles?

Lines 299-204 and Figures 2 and 3: The axes of these figures are a bit small and hard to read. Please make the text larger.

Line 485-486: You write: "When comparing the three Landsats, we were not able to identify a clear pattern of one sensor outperforming the other." However, there are four, not three, Landsat platforms used in this study (Landsats 4, 5, 7, and 8). I think you dropped Landsat 4 here because "it was not possible to validate Landsat-4 LST retrievals since in situ data are unavailable for its period of operation" (Lines 492-493). But since this detail comes later, you might want to clarify this earlier--probabily around Line 351. Also, doesn't Figure 3 indicate that Landsats 4 through 7 have markedly higher biases than Landsat 8? Figure 3 does not use in situ data but the vertical axis is described as "LST error" nonetheless. Perhaps you are referring solely to the performance of your LST retrievals against in situ data.

**Minor typographical/ grammatical issues:**

Lines 22-23: "The code may be used freely by users for computing Landsat LST and then easily allow performing..." should probably be "The code may be used freely by users to compute Landsat LST as part of any analysis within GEE."

Line 75: This is the first use of the acronym "USGS" in this paper? It should probably be spelled out: U.S. Geological Survey or United States Geological Survey.

Line 76: "original raw orthorectified data" should probably be "original, raw, orthorectified data;" and maybe either "original" or "raw" should be removed because they mean the same thing here.

Line 108: "reanalyzes" should be "reanalyses" or, better yet, "reanalysis data," as "reanalyses" is uncommon.

Lines 194-196: I'm not sure if Remote Sensing requires the sections to be formatted this way, but it would be helpful to the reader if the trailing period was removed from the section number. For example, "2.2.1." should be "2.2.1" so that readers don't think it marks the end of a sentence.

Line 227: "United states" should be "United States"

Line 256: "and using" should probably be "using"

Line 260: "ground facing radiometer" should be "ground-facing radiometer"

Lines 261-262: "tree facing radiometers" should be "tree-facing radiometers"

Line 320: Starting a new paragraph here would help the reader.

Line 442: "Landsats' spatial scale" should probably be "Landsat's spatial scale;" same on Line 472. "Landsat" can refer to the series of platforms.

Line 484: There is a line break between paragraphs that is not needed.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf