Não é possível encontrar a localização NATO UTM no Sentinel-2

Considerar coordenadas 31.96212, -103.004715

Os conversores UTM fornecem coordenadas UTM 13/R/FR.

O conversor de exemplo está aqui: http://www.rcn.montana.edu/resources/converter.aspx

Mas há muitos deles e eles dão respostas semelhantes para essas coordenadas.

Simultaneamente, no conjunto de dados do Sentinel-2 aqui http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

Não consigo encontrar o FRsubdiretório.

No google, esta localização é aqui:

E encontrando o mesmo lugar no navegador de imagens do Sentinel , vejo que esse bloco é diferente

que significa,13/S/FR ou seja, o mesmo UTMe quadrado, mas banda diferente.

Como isso é possível?

ATUALIZAR

O KML com blocos do Sentinel-2 também relata o Sbloco em um determinado local

ATUALIZAÇÃO 2

De acordo com esta imagem

tirada daqui , a FRpraça está localizada metade na Szona UTM e metade na Rzona. Obviamente, a maioria dos conversores automáticos atribui esse quadrado à Rzona, enquanto o Sentinel-2 é responsável por Szona.

Existe alguma verdade aqui?

ATUALIZAÇÃO 3

O código Python simples, extraído daqui 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)

também retorna 13R.

Esse erro está nos dados do Sentinel-2 ou o quê?

Em resposta à sua pergunta de comentário "como simular esse algoritmo":

Esta é uma solução bastante bruta, mas fácil de implementar e deve oferecer bom desempenho:

1. Use qualquer um dos conversores UTM que funcionem "conforme o esperado", colocando as coordenadas em 13R.

2. Em seguida, verifique se a pasta existe na estrutura de dados do Sentinel 2. Se sim, você terminou, viva.

3. Caso contrário, verifique as grades UTM vizinhas e veja se o bloco / pasta "FR" existe nelas. Dado que há sobreposições em todos os lugares, você teria que verificar todas as 8 grades ao redor.
   A ordem mais provável de verificação seria 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
   Os quatro últimos podem ser relevantes se suas coordenadas estiverem nos cantos de uma zona UTM, mas são altamente improváveis.

Dada a maneira como o Sentinel2 rotula blocos, apenas um dos vizinhos deve ter essa pasta, garantindo que você obtenha o arquivo correto.

Qualquer outra solução geograficamente mais "correta" envolveria muito mais sobrecarga computacional do que eu acho que se justifica aqui.

E, definitivamente, definitivamente relate isso à equipe da ESA, conforme sugerido por Kersten nos comentários. Realmente não entendo por que eles escolheram um sistema organizacional tão desnecessariamente complicado.

Post relacionado aqui

O que tem funcionado para mim é usar o K2 S2 fornecido pela ESA para calcular todos os blocos ali que se cruzam com a minha AOI e, em seguida, procurar esses blocos na AWS.

Esse KML parece funcionar como uma definição de todos os IDs de bloco possíveis gerados pelo S2, eliminando muitas opções sobrepostas.

Observando o KML (somente inspeção visual, não 100% de certeza), parece-me que, na pior das hipóteses, você teria que procurar por quatro blocos.

Seria bom ter o algoritmo usado pela ESA para definir o KML para tornar isso mais eficiente.