# Cannot find NATO UTM location in Sentinel-2

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?

• 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
• 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.