Cannot find NATO UTM location in Sentinel-2

Question

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:

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

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

How is this possible?

UPDATE

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

UPDATE 2

According to this picture

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?

UPDATE 3

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

bandVals = "CDEFGHJKLMNPQRSTUVWXX"

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'
else:
    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?

Answer 1

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.

Answer 2

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.