Impossibile trovare la posizione della NATO UTM in Sentinel-2

Riguarda le coordinate 31.96212, -103.004715

I convertitori UTM forniscono le sue coordinate UTM 13/R/FR.

Il convertitore di esempio è qui: http://www.rcn.montana.edu/resources/converter.aspx

Ma ce ne sono molti e danno risposte simili per queste coordinate.

Contemporaneamente, nel set di dati di Sentinel-2 qui http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

Non riesco a trovare la FRsottodirectory.

In google questa posizione è qui:

E trovando lo stesso posto nel browser di immagini Sentinel che vedo, quel riquadro è diverso

che significa13/S/FR cioè la stessa UTMbanda quadrata, ma diversa.

Com'è possibile?

AGGIORNARE

KML con i riquadri Sentinel-2 riporta anche i Sriquadri in una determinata posizione

AGGIORNAMENTO 2

Secondo questa immagine

preso da qui , il FRquadrato si trova metà nella Szona UTM e metà nella Rzona. Ovviamente, la maggior parte dei convertitori automatici assegna questo quadrato alla Rzona, mentre Sentinel-2 lo conta per Szona.

C'è qualche verità qui?

AGGIORNAMENTO 3

Il semplice codice Python, preso da qui 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)

ritorna anche 13R.

Questo errore è nei dati di Sentinel-2 o cosa?

In risposta alla tua domanda di commento "come simulare questo algoritmo":

Questa è una soluzione piuttosto brutale, ma facile da implementare e dovrebbe dare buone prestazioni:

1. Utilizzare uno dei convertitori UTM che funzionano "come previsto", posizionando le coordinate in 13R.

2. Quindi, controlla se la cartella esiste nella struttura di dati di Sentinel 2. Se sì, hai finito, evviva.

3. In caso contrario, controllare le griglie UTM vicine e vedere se esiste il riquadro / cartella "FR" in esse. Dato che ci sono sovrapposizioni ovunque, dovresti controllare tutte le 8 griglie circostanti.
   L'ordine più probabile da verificare sarebbe 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
   Gli ultimi quattro potrebbero essere rilevanti se le tue coordinate si trovano negli angoli di una zona UTM, ma sono altamente improbabili.

Dato il modo in cui Sentinel2 etichetta le tessere, solo uno dei vicini dovrebbe mai avere una tale cartella, garantendo di ottenere il file corretto.

Qualsiasi altra soluzione geograficamente più "corretta" comporterebbe molte più spese generali di calcolo di quanto ritenga giustificato qui.

E sicuramente, segnalalo sicuramente al team ESA come suggerito da Kersten nei commenti. Davvero non capisco perché abbiano scelto un sistema organizzativo così inutilmente contorto.

Post correlato qui

Quello che ha funzionato per me è usare il KML S2 fornito dall'ESA per calcolare tutte le tessere che si intersecano con il mio AOI e quindi cercare queste tessere in AWS.

Questo KML sembra funzionare come una definizione di tutti i possibili id ​​di tile generati da S2, eliminando molte opzioni sovrapposte.

Guardando il KML (solo ispezione visiva, non sicuro al 100%) mi sembra che nel caso peggiore dovresti cercare 4 tessere.

Sarebbe bello avere l'algoritmo utilizzato dall'ESA per definire il KML per renderlo più efficiente.