Regard coordinates 31.96212, -103.004715

UTM converters give it's UTM coordinates are 13/R/FR.

Example converter is here: http://www.rcn.montana.edu/resources/converter.aspx

But there are many of them and they give similar answers for these coordinates.

Simultaneously, in Sentinel-2 dataset here http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

I can't find FR subdirectory.

In google this location is here:

enter image description here

And finding the same place in Sentinel image browser I see, that tile is different

enter image description here

which stands for 13/S/FR i.e. the same UTM and square, but different band.

How is this possible?


KML with Sentinel-2 tiles also reports S tile in given location

enter image description here


According to this picture

enter image description here

taken from here, the FR square is located half in S UTM zone and half in R zone. Obviously, most automatic converters assign this square to R zone, while Sentinel-2 accounts it for S zone.

Is there any truth here?


The simple Python code, taken from here https://gis.stackexchange.com/a/224994/32207


lon = 31.96212
lat = -103.004715

zone = int(lat + 186.0) / 6

if (lon >= 84.0):
    band = 'Y' if (lat < 0.0) else 'Z'
elif (lon <= -80.0):
    band = 'A' if (lat < 0.0) else 'B'
    band = bandVals[int(lon + 80.0) / 8]

print '{:02d}{:s}'.format(zone,band)

also returns 13R.

Is this error in Sentinel-2 data or what?

  • It is S/FR, while UTM converters give R/FR. How to calculate location if UTM converters work incorrectly? – Dims May 24 '17 at 20:33
  • The latitude value is just under 32 degrees North. That puts it squarely in the R latitude "band". Sentinel-2 may have tiled by using the center point of the tile which could be in the "S" band instead. – mkennedy May 25 '17 at 20:19
  • @mkennedy how to simulate this algorithm starting from coordinates? – Dims May 27 '17 at 10:59
  • 2
    You might also consider reporting this to eosupport@copernicus.esa.int, since it does indeed look like unexpected behaviour. – Kersten May 29 '17 at 12:53

In response to your comment question "how to simulate this algorithm":

This is a pretty brute solution, but easy to implement and should give good performance:

  1. Use any of the UTM converters that work "as expected", placing the coordinates in 13R.
  2. Then, check if the folder exists in the Sentinel 2 data structure. If yes, you're done, hooray.

  3. If not, check the neighboring UTM grids and see if the tile/folder "FR" exists in them. Given there are overlaps everywhere, you'd have to check all surrounding 8 grids.
    The most likely order to check would be 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
    The last four could be relevant if your coordinates lie in the corners of a UTM zone, but are highly unlikely.

Given the way Sentinel2 labels tiles, only one of the neighbors should ever have such a folder, guaranteeing you get the correct file.

Any other, geographically more "correct" solution would involve a whole lot more computational overhead than I feel is justified here.

And definitely, definitely report this to the ESA team as suggested by Kersten in the comments. I really don't understand why they chose such an unnecessarily convoluted organizational system.


Related post here

What has been working for me is to use the S2 KML provided by ESA to compute all the tiles there that intersect with my AOI, and then searching for these tiles in AWS.

This KML seems to work as a definition of the all possible tile ids generated by S2, eliminating lots of overlapping options.

By looking the KML (visual inspection only, not 100% sure) it seems to me that in the worst case you would have to search for 4 tiles.

It would be nice to have the algorithm that ESA used to define the KML to make this more efficient.

Your Answer

