在Sentinel-2中找不到北约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子目录。

在google中，此位置在这里：

在我看到的Sentinel图片浏览器中找到相同的位置，图块是不同的

其代表13/S/FR即相同的UTM和方形的，但不同的频段。

这怎么可能？

更新

具有Sentinel-2磁贴的KML还会报告S给定位置的磁贴

更新2

根据这张图片

采取从这里，该FR广场位于一半SUTM区和半R区。显然，大多数自动转换器将此正方形分配给R区域，而Sentinel-2则将其分配给S区域。

这里有什么真相吗？

更新3

简单的Python代码，从此处获取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)

也返回13R。

Sentinel-2数据中出现此错误还是什么？

回应您的评论问题“如何模拟此算法”：

这是一个非常简单的解决方案，但易于实现，并且应具有良好的性能：

1. 使用任何“按预期”工作的UTM转换器，将坐标置于13R中。

2. 然后，检查Sentinel 2数据结构中是否存在该文件夹。如果是，那么您已经完成了，万岁。

3. 如果不是，请检查相邻的UTM网格，并查看其中是否存在图块/文件夹“ FR”。由于到处都有重叠，因此您必须检查所有周围的8个网格。
   最可能检查的顺序是13S，13Q，12R，14R，12S，14S，12Q，14Q。
   如果您的坐标位于UTM区域的角落，则最后四个可能是相关的，但可能性很小。

考虑到Sentinel2标记瓷砖的方式，只有一个邻居应该有这样的文件夹，以确保您获得正确的文件。

任何其他在地理上更“正确”的解决方案所涉及的计算开销都比我在这里认为合理的多得多。

而且绝对可以按照Kersten在评论中的建议，向ESA小组报告。我真的不明白为什么他们选择了这种不必要的复杂组织系统。

相关文章在这里

对我有用的是使用ESA提供的S2 KML来计算在那里与我的AOI相交的所有切片，然后在AWS中搜索这些切片。

此KML似乎可以作为S2生成的所有可能的tile ID的定义，从而消除了许多重叠的选项。

通过查看KML（仅通过视觉检查，不能100％确定），在我看来，在最坏的情况下，您将必须搜索4个图块。

拥有ESA用来定义KML的算法以使其更高效将是非常不错的。