Nie można znaleźć lokalizacji NATO UTM w Sentinel-2

Uwzględnij współrzędne 31.96212, -103.004715

Konwertery UTM podają, że są to współrzędne UTM 13/R/FR.

Przykład konwertera znajduje się tutaj: http://www.rcn.montana.edu/resources/converter.aspx

Ale jest ich wiele i dają one podobne odpowiedzi dla tych współrzędnych.

Jednocześnie w zestawie danych Sentinel-2 tutaj http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

Nie mogę znaleźć FRpodkatalogu.

W Google ta lokalizacja jest tutaj:

I znajdując to samo miejsce w przeglądarce obrazów Sentinel , widzę, że ten kafelek jest inny

co oznacza13/S/FR np. to samo UTMi kwadratowe, ale inne pasmo.

Jak to jest możliwe?

AKTUALIZACJA

KML z kafelkami Sentinel-2 zgłasza także Skafelki w danej lokalizacji

AKTUALIZACJA 2

Według tego zdjęcia

wzięty stąd The FRSquare znajduje się w połowie SUTM strefy, a połowa w Rstrefie. Oczywiście większość automatycznych konwerterów przypisuje ten kwadrat do Rstrefy, podczas gdy Sentinel-2 rozlicza go dla Sstrefy.

Czy jest tu jakaś prawda?

AKTUALIZACJA 3

Prosty kod Pythona, pobrany stąd 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)

również powraca 13R.

Czy ten błąd występuje w danych Sentinel-2?

W odpowiedzi na pytanie w komentarzu „jak symulować ten algorytm”:

Jest to dość brutalne rozwiązanie, ale łatwe do wdrożenia i powinno dawać dobrą wydajność:

1. Użyj dowolnego konwertera UTM, który działa „zgodnie z oczekiwaniami”, umieszczając współrzędne w 13R.

2. Następnie sprawdź, czy folder istnieje w strukturze danych Sentinel 2. Jeśli tak, to koniec.

3. Jeśli nie, sprawdź sąsiednie siatki UTM i sprawdź, czy istnieje w nich kafelek / folder „FR”. Biorąc pod uwagę, że wszędzie występują nakładki, należy sprawdzić wszystkie otaczające 8 siatek.
   Najbardziej prawdopodobne zamówienie to 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
   Cztery ostatnie mogą być istotne, jeśli współrzędne znajdują się w rogach strefy UTM, ale są bardzo mało prawdopodobne.

Biorąc pod uwagę sposób, w jaki Sentinel2 określa płytki, tylko jeden z sąsiadów powinien mieć taki folder, gwarantujący uzyskanie poprawnego pliku.

Każde inne, bardziej „poprawne” geograficznie rozwiązanie wiązałoby się z dużo większym obciążeniem obliczeniowym, niż uważam za uzasadnione.

Zdecydowanie z pewnością zgłoś to zespołowi ESA, jak sugeruje Kersten w komentarzach. Naprawdę nie rozumiem, dlaczego wybrali tak niepotrzebnie zawiły system organizacyjny.

Powiązany post tutaj

Pracowałem dla mnie za pomocą S2 KML dostarczonego przez ESA do obliczenia wszystkich kafelków, które przecinają się z moim AOI, a następnie wyszukiwania tych kafelków w AWS.

Ten KML wydaje się działać jako definicja wszystkich możliwych identyfikatorów kafelków generowanych przez S2, eliminując wiele nakładających się opcji.

Patrząc na KML (tylko kontrola wizualna, nie w 100% pewna) wydaje mi się, że w najgorszym przypadku będziesz musiał poszukać 4 kafelków.

Byłoby miło mieć algorytm używany przez ESA do zdefiniowania KML, aby uczynić go bardziej wydajnym.