10 m/px resolution for all Sentinel-2 bands : how?

EO Products / Scripts
1

Hi everyone,

I used EO Brower to download Sentinel-2 data, all bands, for analytical purposes. While downloading, I chose the options “Image resolution: high” and “Coordinate system: EPSG:3857”. It resulted to promise a projected resolution of 10m/px, in the downloading popup of EO Browser.
However, I was surprised to get 10 m/px for all bands -when for example, B01 is supposed to have a resolution of 60 m/px, or B06 a resolution of 20 m/px. I checked the reflectance values on my GIS program and pixels of 10 m/px are indeed different inside of a 60 m square (i.e., a big pixel was not simply cut into smaller squares).
Can someone explain why all Sentinel-2 bands are 10 m/px resolution and how it was achieved ? I could not find any piece of information on that.

Thank you,
Léa

2

Original data is in UTM coordinate system, so when we reproject for you to EPSG:3857, there come the differences.

3

Hey Léa,

in addition to that there is some documentation about how the upsampling/(or downsampling) is actually done. You can find it here.

As you can read there, the default used is a “nearest-neighbor interpolation” but you also have the possibility of changing the method in the advanced options (image).

effects
dthiex

4

Hi,
It’s all clearer now ! Thank you for your answers and the documentation.

5

Hi everyone,
I’m bringing this topic back as I have a new related question -please let me know if I should rather open a new topic !
I downloaded some images from EO Browser, using both the web app and the eo learn package. I used KML files as inputs, which defined my ROIs. I noticed that the pixel grid of the output TIFF aligns exactly with the KML shape for all my plots -and there are twelve of them. It seems very unlikely that all of my KML are perfectly aligned with the Sentinel 2 10m pixel grid.
I tested this hypothesis by downloading a tile from the ESA hub and compared the pixel grids: indeed, the grid from my EO Browser TIFFs did not align with the ESA file grid.
Can someone tell me how the output is produced in terms of pixel grid ? Is there any resampling involved ? It is linked to the downscaling / upscaling discussed in my previous topic ?
How can I get a TIFF using the Sentinel 2 grid and not the grid that fits my KML ?
Once again, I tried looking this up in the documentation but was unsuccessful.
Thank you for you attention,
Léa

6

Hi @leatresch

The service applies interpolation to the coordinates you provide. To achieve your goal, your input KML geometry in the UTM coordinate system should have coordinates multiple of 10, e.g. 35670 instead of 35668.984.

Let us know if this works.

7

Hi @devis.peressutti,
Thank you for your quick answer !

To be sure, let me rephrase: based on the KML, eo-learn / EO Browser interpolates the data using the bounding box of the KML, ‘creating’ a 10m resolution pixel grid based on the top-left corner of the KML ?
If the KML shape is not a multiple of 10 m, then is the resolution automatically shrinked in order to fit the KML size ? I seem to observe that but I wanted to make sure.
Also, is that referenced anywhere ?

I’ll try the method you gave me and update the topic based on my results.
Thank you !

8

Yes, you are correct, I should have phrased as you did.

There are some details here, but I will check with the team for more details.

9

Update:

I tried using a KML defined with multiples of 10 for coordinates, based on a UTM EPSG.
I made a CSV file using WKT with the following poly:
POLYGON((367910 807180, 367970 807180, 367970 807110, 367910 807110, 367910 807180))
SCR EPSG:20137 - Adindan / UTM zone 37N
Then, I made a KML using QGIS and used the KML file as input for EO Browser. I chose the option Popular Web Mercator (EPSG:3857) (Projected resolution: 10 m/px).

Here are some outputs of the EO Browser band file:
Pixel size 10.11425629987691899, -10.17298819407421639
Extend in EPSG:20137, to compare to the polygon coordinates listed above
north 807180.1593
east 367970.1857
south 807109.8410
west 367909.8144

So as you can see, the area of the WKT and of the output TIFF is not exactly the same -I know it’s quite similar (i.e. at a 10^-1 level) and I guess it’s coming from the reprojection from WKT to KML (which is automatically ESPG:4326), however I was wondering: what is the level of precision of EO Browser regarding KML input / area delimitations?
Thus, because the area is not exactly the same, the pixel size is not exactly at 10m either, which is one of the main issues in my case.
Does anyone have any idea how to make a better job than this ?
I exported a GEOJSON of the WKT using QGIS (in the same CRS, i.e. EPSG:20137 - Adindan / UTM 37N) but when I uploaded it in EO Browser, the area displayed was totally wrong. See at the end of the post if you’re interested in the file itself.

But what’s more critical is that the output TIFF is not aligned with the Sentinel-2 grid.
I tried with another projection, so I did once again a WKT with the following arguments:
POLYGON((4208350 815070, 4208350 815140, 4208400 815140, 4208400 815070, 4208350 815070))
CRS EPSG:3857 - WGS 84 / Pseudo-Mercator (I took the same as the outputs from EO Browser, even thought it’s not UTM and thus spherical -I suspected it would not work but tried anyways).
And yes, once again, the output file is not aligned with Sentinel2 grid either.
I finally tried with the EPSG:32637 WGS 84 / UTM Zone 37N using multiples of 10 to define the extend, but the output is still not aligned with the Sentinel2 grid.

I don’t really know if I did anything wrong compared to what you suggested (except for the part where the EPSG was not UTM), but in conclusion of what I tried:

  • The EO Browser output file is not aligned with Sentinel2 grid in all cases
  • The pixel resolution is not 10 meter (10^-1 precision)
  • The resolution issue may be linked to the conversion to KML
  • As I can’t use GEOJSON as input in EO Browser, the last bullet point cannot be verified

I would say that the method is not working, so far -unless I did not understand what you meant. Do you have any suggestion to make better attempts?

Also, to respond to your last reply @devis.peressutti: I would gladly take in some more details about this matter, if possible !

Here is my GEOJSON file:
{
“type”: “FeatureCollection”,
“name”: “TUMMA_32637”,
“crs”: { “type”: “name”, “properties”: { “name”: “urn:ogc:def:crs:EPSG::32637” } },
“features”: [
{ “type”: “Feature”, “properties”: { “id”: 1 }, “geometry”: { “type”: “Polygon”, “coordinates”: [ [ [ 368000.0, 807380.0 ], [ 368060.0, 807380.0 ], [ 368060.0, 807310.0 ], [ 368000.0, 807310.0 ], [ 368000.0, 807380.0 ] ] ] } }
]
}

10

Hi leatresch,

quite some testing you did there.

First of all we should clarify: if you’d like to get the data from SH aligned with the original grid, you should use process API (or sentinelhub-py) . See this example of process API request (it is for S1 but the same principles apply for S2), relevant parameters are bbox, crs and width&height. Since EO Browser doesn’t support the export in WGS 84 / UTM crs, you can not get the data aligned with the original grid (as you correctly concluded yourself).

Now some comments to your experiments:

  • New GeoJSON format support only geographical coordinates refering to WGS 84 (https://tools.ietf.org/html/rfc7946#section-4). That is why EO Browser doesn’t read your GEOJSON files as you expected. I tried exporting GeoJSON from Qgis as you did and it indeed exports data in .geojson file with selected crs, which is, I believe, inline with the old GeoJSON format.

  • The EPSG:20137 - Adindan / UTM zone 37N coordinate reference system uses Adindan datum. When exporting to KML, the datum transformation to WGS 84 happens somehow behind the scenes but the accuracy of this transformation depends on the parametrs used and can vary a lot. When making requests to SH process API you will need to use one of the supported crs. In your case http://www.opengis.net/def/crs/EPSG/0/32637 seems the correct choice.

11

Hi @avrecko,
Thanks for your input !
I tried using sentinelhub-py and it worked -I have an output tiff with precisely 10m resolution that is aligned with Sentinel2 pixel grid when using UTM CRS! Victory!
However, it seems that there is still the constraint of inputting multiples of 10 for the shape of the bbox when using a UTM CRS. Sentinelhub-py does, as EO Browser / eo-learn do, a resampling inside of the given bbox coordinates and create a somewhat-10m pixel grid in the TIFF if the bbox extend is not a multiple of 10 in a UTM Zone.

I have a few more questions -sorry! A data processing pipeline was developped internally by our team, using eo-learn, but with this new knowledge on the output, we cannot use it as is.
We are currently searching in the code but thought you guys might know better about the topic, so here we are:
We’ve used S2L2AWCSInput, in the our code, which comes from eolearn.io.sentinelhub_service. It is a task for creating EOPatch and filling it with data using Sentinel Hub’s OGC request. In the inputs, it is possible to choose size_x and size_y: number of pixels in x/y or resolution in x /y (i.e. 512 or 10m ). However, as pointed above and in this whole topic, the inputted resolution was not respected (i.e. we chose 10m for size_y and size_x). Can someone explain how these parameters are processed? Why it did not ended up being a 10m resolution ? Is it because the KML extend has higher priority than the chosen resolution ?

Also, you said in your latest post that “Since EO Browser doesn’t support the export in WGS 84 / UTM crs” but can eo-learn output data in UTM CRS?

Thanks !
Léa

12

Hi,

I tried using sentinelhub-py and it worked -I have an output tiff with precisely 10m resolution that is aligned with Sentinel2 pixel grid when using UTM CRS! Victory!

:+1:

Can someone explain how these parameters are processed? Why it did not ended up being a 10m resolution ? Is it because the KML extend has higher priority than the chosen resolution ?

Correct. In other words, an output image covers the geographical extent requested by bbox (if geometry is requested we calcualte its bbox) and the size of an output image (i.e number of pixels in x and y) is calculated based on the requested resolution, e.g. width of bbox / resx and is rounded to the closest whole number.
As a consequence, you will get the output image with exactly the requested resolution only when the width and height of the requested bbox are multiples of the requested resolutions.

but can eo-learn output data in UTM CRS?
Yes, see: https://sentinelhub-py.readthedocs.io/en/latest/constants.html#sentinelhub.constants.CRS

13

Hi,
Thank you very much for all the explanations and also the quick answers. It’s all clear now.
Léa