How to access the orthorectified/surface reflectance processing level

We need to access the orthorectified/surface reflectance processing level. In addition, we want to avoid any tasks that may lead to data resampling, aside from atmospheric correction and orthorectification. Therefore, if possible, we would like to access data in the same structure of tilling and resolutions as their original data source (Landsat8-USGS & Copernicus .

Datasets/processing level/ bands/spatial resolution:

DATASET	BANDS	RESOLUTION (m)
landsat-ot-l2	B02, B03, B04, B05, B06, B07	30m
sentinel-2-l2a	B02, B03, B04, B05, B06, B07, B08, B08A, B1972, B12	10, 20m

Time range:

· From = 2017-01-01

· To = 2021-10-08

Temporal Resolution:

· We would like to access all the scenes within the predetermined time range, except those with 100% cloud coverage

Cloud coverage filter:

· Landsat 8 = ~ 80%

· Sentinel2 = ~ 60%

AOI - Area of interest:

· Sentinel2 tile: 23KKQ

· Landsat 8 tile: 220076

We are suggesting the AOI based on the original data source tilling, to avoid pixel resampling due mosaicking and/or cropping.

Does it make sense? If possible, to subset the scene without significant resampling we would like to use Sentinel2 tile 23KKG as AIO for Landsat 8 as well.

Page 1 / 1

The Sentinel-2 and LandSat-8 grids are rather different. As can be seen from the image below:

The pink (L-8 grid) deals with overlaps and different UTM zones differently than yellow-ish (S-2 grid), where overlap between tiles within one UTM zone are small, but then the zones itself overlap.

In your case of L8 220076 tile (purple) and 23KKQ (blue), the situation is like so:

The blue (S-2) tile is in fact from different UTM zone than the LandSat one. But there is quite an overlap with 22KHV tile (red), so to reduce the re-projection issues, it is preferable to use 22KHV (although the data on the zone overlaps is the same!)

That being said, there is another difference between L-8 and S-2 tiles: the S-2 tiles are “fixed in time”, meaning their bounding boxes are fixed to the grid, while the L-8 tiles “slightly move” in time, as can be seen from the image below (again purple for L-8 220076, red for S-2 22KHV and blue for S-2 23KKQ):

With CatalogAPI the concrete numbers can be seen from proj:bbox attribute in the STAC item:

bbox for 22KHV Sentinel-2 tiles in the image: :799980.0, 7390240.0, 909780.0, 7500040.0]

bbox for 23KKQ Sentinel-2 tiles in the image: :199980.0, 7390240.0, 309780.0, 7500040.0]

bbox for LandSat-8 tiles in the image:

l685200.0, 7322500.0, 918600.0, 7558600.0],

,685500.0, 7322500.0, 918900.0, 7558600.0],

,685800.0, 7322500.0, 919200.0, 7558600.0],

,686100.0, 7322500.0, 919500.0, 7558600.0],

,686400.0, 7322500.0, 919800.0, 7558600.0],

,687000.0, 7322500.0, 920400.0, 7558600.0], ...

This can become a problem when trying to use one grid for both, but luckily, all bbox-es seem to be rounded to nice numbers (multiple of 10 for Sentinel-2 everywhere, not sure for LandSat, but in your case, it is rounded to multiples of 100).

So in your case, I’d start with tile 22KHV and use its bounding box as an AOI. If you want to completely avoid resampling, then you should

use CatalogAPI to get bbox of the tile for a particular time

make a request for the bands aligned to that bbox (the top left pixel of each band regardless of band resolution starts in the same corner of the bounding box)

make requests separately for L-8/S-2 10m/S-2 20m bands

In most cases, though, some (small) re-projection is not a problem. In such cases perhaps using nearest neighbours interpolation is beneficial, as it doesn’t really do resampling of data. For instance, if using Batch, we (EO research team) mostly use 10 or 20 km grid based on Sentinel-2 UTM zones (grids with id 0 or 1). The fact that they are based on UTM zones would help even in case of LandSat-8 data, as for majority of tiles, the L-8 data would not have to be re-projected. At bands’ original resolutions we use nearest neighbours (default) interpolation.

I understand the answer is somewhat lacking in “instructions”, but it really depends on your use-case. Please don’t hesitate to ask any follow-up questions. Also, apologies for a really late reply.