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하위 디렉토리를 찾을 수 없습니다 .

Google에서이 위치는 다음과 같습니다.

Sentinel 이미지 브라우저 에서 동일한 위치를 찾으면 타일이 다릅니다.

어떤 의미13/S/FR 즉, 같은 UTM과 광장,하지만 서로 다른 밴드.

이것이 어떻게 가능한지?

최신 정보

Sentinel-2 타일이있는 KML S은 지정된 위치의 타일도보고합니다.

업데이트 2

이 사진에 따르면

여기 에서 가져온 FR사각형은 SUTM 영역의 절반과 R영역의 절반에 있습니다. 분명히 대부분의 자동 변환기는이 사각형을 R영역에 할당 하는 반면 Sentinel-2는 S영역 을 설명 합니다.

여기에 진실이 있습니까?

업데이트 3

여기에서 가져온 간단한 파이썬 코드 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. 좌표가 13R에 배치되어 "예상대로"작동하는 UTM 변환기를 사용하십시오.

2. 그런 다음 폴더가 Sentinel 2 데이터 구조에 존재하는지 확인하십시오. 그렇다면 hooray입니다.

3. 그렇지 않은 경우, 인접한 UTM 그리드를 확인하고 타일 / 폴더 "FR"이 있는지 확인하십시오. 모든 곳에 겹치는 부분이 있으므로 주변 8 그리드를 모두 확인해야합니다.
   가장 가능성이 높은 순서는 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q입니다.
   좌표가 UTM 영역의 모서리에 있지만 가능성이 거의없는 경우 마지막 4 개가 관련 될 수 있습니다.

Sentinel2가 타일에 레이블을 지정하는 방식을 고려할 때, 이웃 중 하나만 이러한 폴더를 가져야 올바른 파일을 얻을 수 있습니다.

지리적으로 더 정확한 다른 "올바른"솔루션은 여기에서 정당화되는 것보다 훨씬 더 많은 계산 오버 헤드가 필요합니다.

그리고 Kersten의 의견에 따라 ESA 팀에이를 분명히보고하십시오. 나는 그들이 왜 그렇게 불필요하게 복잡한 조직 시스템을 선택했는지 이해하지 못합니다.

여기 관련 게시물

나를 위해 일한 것은 ESA에서 제공 한 S2 KML을 사용하여 AOI와 교차하는 모든 타일을 계산 한 다음 AWS에서 이러한 타일을 검색하는 것입니다.

이 KML은 S2에서 생성 된 가능한 모든 타일 ID의 정의로 작동하여 많은 중복 옵션을 제거합니다.

KML (시각적 검사 만, 100 % 확실하지 않음)을 보면 최악의 경우 4 개의 타일을 검색해야 할 것 같습니다.

ESA에서 KML을보다 효율적으로 만들기 위해 정의한 알고리즘을 사용하는 것이 좋을 것입니다.