The Sentinel-2 tiles, how they work ?

=> 

The Sentinel-2 Level 1C products will be split into tiles. and I have searched a little how the naming convention of Sentinel-2 tiles works. I have found some interesting resources in Sentinel-2 website :

  • A User Handbook for Sentinel-2 products (which does not explain the naming convention of the tiles)
  • A kml file that provides the footprint of all the tiles, and their name.

 

 

 

Here is  what I have guessed :

  • The first 2 numbers of a tile name (such as 31TCJ) correspond to the UTM zone. The world is divided in 60 UTM zones of 8 degrees width in longitude, with numbers increasing towards the East. Zone 1 is over the Pacific Ocean.
  • Each zone is divided in latitude, by chunks of 6 degrees. This is represented by a letter, which increases from South to North.
  • And finally, each chunk is divided in 110 km tiles, with a 10 km overlap, from West to East, 4th Letter, and South to North, 5th Letter. What is not easy to guess is the fact that the forth and fifth letters are not reset for each chunk, but continue to increase when changing zone and chunk, but are reset to A when the counter exceeds Z.

 

For instance :

  • the tile in Toulouse, id 31TCJ. 31 is the UTM zone, T is the latitudinal chunk. C denotes the West-East tile position within the chunk and J the South-North position.
  • If you want to see the tile in the East of Toulouse, which includes Castres, it will be 31TDJ.
  • If you want to see the tile in the North East of Toulouse, which includes Aurillac, it will be 31TDK.
  • If you want to see the tile at the West of Toulouse, which includes the Armagnac region, it will be... 30TYP. 30T because it is a different UTM zone, and YP ... because this numbering is not practical  ?
  • The tile at the South of that one, for which we processed our first Level 2A products is  30TYN (because the O letter is excluded, to avoid confusion with 0)

 

Sorry for that, I would like to have a formula which guesses the tile name as a function of the longitude and latitude, but I am not able to figure out one. Has any of you heard of one ?

 

What I am happy with is the fact that tiles overlap by 10km. This ovelap means an increase of 21 % of the data volume, which is already large, but enables to process Level 2A products independently. It is very difficult to detect a cloud shadow when you do not see the corresponding cloud. And on the edge of the tiles, you will have shadows on clouds you do not see. But thanks to the overlap, the shadows will be well detected on the other overlapping tile.

 

A colleague of mine told me this grid was born in the brain of an American solldier (yes, soldiers have brains ). Here is a description, which sadly does not tell how the two last letters were defined.

 

 

 

 

 

Posted under: Comment ça marche /how it works, In English, Sentinel-2

4 comments

  • Sébastien on 12/01/2016 at 16:51 said:

    Merci pour ces infos et pour l'ensemble de ce blog qui est une mine d'or !

    Ce petit lien pour mentionner que:
    1) Il y avait une erreur dans la numérotation des tuiles utilisée, qui affecte tous les produits antérieur à la baseline 02.01. Certaines tuiles dans l'hémisphère Sud ont donc changé de nom... Attention pour les séries temporelles donc !
    2) Le nouveau fichier KML avec la numérotation des tuiles se trouve ici:
    https://sentinel.esa.int/documents/247904/1955685/S2A_OPER_GIP_TILPAR_20150622T000000_21000101T000000_ZZ_0007.kml

    • Olivier Hagolle on 12/01/2016 at 16:54 said:

      Merci Sebastien pour le commentaire et la correction. Je mets à jour l'article.
      Olivier

  • Eva on 07/03/2017 at 14:09 said:

    the links are broken now. but really thank you for sheding some light over this tiling scheme. Still not able to figure out how to search from engines the tiles for a specific geogrpaphic area
    any new links to tiles? and for S1 products?
    thankssss
    merciiiii

  • Tomas Artes on 06/06/2017 at 13:29 said:

    I didn't try to find any formula. It looks not obvious and could change for every source.

    I solved the problem of tiles fetching creating a RTree from the kml. This will allow you to know the tile quickly and you can change the tiling system for every different sources. In addition, you will obtain multiple tiles, those that intersect with the point or polygon that you use in the RTree. You can create a virtual raster in memory joining the tiles and read save only AOI you need. Create an object with the RTree, serialize it and save it in a file. You wont need to create the RTree every time.

    At the end you could have something like a function fetch():
    fetch(RTree object,geometry object)-->tiles

    I know it is a late answer. I guess you found another solution. Anyway, I hope it helps a bit!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>