Sentinel-2でNATO UTMの場所が見つかりません

座標について 31.96212, -103.004715

UTMコンバーターは、UTM座標がであることを示し13/R/FRます。

コンバーターの例はこちら：http : //www.rcn.montana.edu/resources/converter.aspx

しかし、それらの多くはあり、それらはこれらの座標に対して同様の答えを出します。

同時に、ここのSentinel-2データセットhttp://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

FRサブディレクトリが見つかりません。

グーグルでこの場所はここにあります：

そして、私が見るSentinel画像ブラウザで同じ場所を見つけると、そのタイルは異なります

これを意味し13/S/FR、すなわち同じUTMと四角が、異なるバンド。

これはどのようにして可能ですか？

更新

Sentinel-2タイルを使用したKMLはS、指定された場所のタイルも報告します

アップデート2

この写真によると

ここから取得すると、FR正方形はSUTMゾーンの半分とRゾーンの半分に配置されます。明らかに、ほとんどの自動コンバーターはこの四角をRゾーンに割り当てますが、Sentinel-2はそれをSゾーンに割り当てます。

ここに真実はありますか？

アップデート3

ここから取得した単純なPythonコード/gis//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)

も返します13R。

Sentinel-2データのこのエラーは何ですか？

「このアルゴリズムをシミュレートする方法」というコメントの質問への回答：

これはかなり野蛮なソリューションですが、実装が簡単で、優れたパフォーマンスを提供するはずです。

1. 「期待どおりに」機能するUTMコンバーターを使用して、座標を13Rに配置します。

2. 次に、フォルダがSentinel 2データ構造に存在するかどうかを確認します。はいの場合、完了です。

3. そうでない場合は、隣接するUTMグリッドをチェックして、タイル/フォルダー「FR」がグリッドに存在するかどうかを確認します。どこにでもオーバーラップがあることを考えると、周囲の8つのグリッドすべてをチェックする必要があります。
   チェックする可能性が最も高い順序は、13S、13Q、12R、14R、12S、14S、12Q、14Qです。
   座標がUTMゾーンの隅にある場合、最後の4つは関連する可能性がありますが、可能性はほとんどありません。

Sentinel2がタイルにラベルを付ける方法を考えると、近隣の1つだけがそのようなフォルダーを持っている必要があり、正しいファイルを確実に取得できます。

他の地理的に「正しい」ソリューションは、ここで正当化されると感じるよりもはるかに多くの計算オーバーヘッドを伴います。

そして間違いなく、カーステンがコメントで提案したように、間違いなくこれをESAチームに報告してください。彼らがなぜそのような不必要に複雑な組織システムを選んだのか、私には本当にわかりません。

関連記事はこちら

ESAが提供するS2 KMLを使用して、私のAOIと交差するすべてのタイルを計算し、AWSでこれらのタイルを検索しています。

このKMLは、S2によって生成される可能性のあるすべてのタイルIDの定義として機能し、重複するオプションの多くを排除しているようです。

KML（目視検査のみ、100％確実ではない）を見ると、最悪の場合、4タイルを検索する必要があるように思えます。

ESAがKMLを定義してこれをより効率的にするためのアルゴリズムがあると便利です。