Не вдалося знайти місцезнаходження НАТО в Sentinel-2

Розгляньте координати 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і квадратну, але різну смугу.

Як це можливо?

ОНОВЛЕННЯ

KML з плитками Sentinel-2 також повідомляє про Sплитку в заданому місці

ОНОВЛЕННЯ 2

Відповідно до цієї картини

взятий звідси , FRплоща розташована наполовину в Sзоні UTM і наполовину в 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 чи що?

— Димс
джерело

чи не так? sentinel-s2-l1c.s3.amazonaws.com/tiles/13/S/FR/2017/5/6/0/… різні діапазони відправляються sentinel-s2-l1c.s3-website.eu-central-1.amazonaws .com / # плитки / 13 /…

— Mapperz

Це S/FR, поки перетворювачі UTM дають R/FR. Як обчислити розташування, якщо перетворювачі UTM працюють неправильно?

— Дімс

Значення широти трохи нижче 32 градусів на північ. Це ставить його прямо в "широти" смуги R. Sentinel-2, можливо, обшивали плиткою, використовуючи центральну точку плитки, яка могла бути замість смуги "S".

— mkennedy

@mkennedy як моделювати цей алгоритм, починаючи з координат?

— Дімс

Ви можете також розглянути можливість повідомляти про це на eosupport@copernicus.esa.int, оскільки це дійсно виглядає як несподівана поведінка.

— Керстен

Відповіді:

У відповідь на ваш коментар питання "як імітувати цей алгоритм":

Це досить жорстоке рішення, але просте у виконанні і повинно дати хороші показники:

Використовуйте будь-який з перетворювачів UTM, які працюють "як очікувалося", розміщуючи координати в 13R.
Потім перевірте, чи папка існує в структурі даних Sentinel 2. Якщо так, ви закінчили, ура.
Якщо ні, перевірте сусідні сітки UTM та перевірте, чи є в них плитка / папка "FR". Враховуючи, що скрізь є перекриття, вам доведеться перевірити всі навколишні сітки.
Найімовірнішим замовленням для перевірки було б 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
Останні чотири можуть бути актуальними, якщо ваші координати лежать у кутах зони UTM, але є малоймовірними.

З огляду на те, як плитка міток Sentinel2 мітить, тільки один із сусідів повинен коли-небудь мати таку папку, що гарантує отримання правильного файлу.

Будь-яке інше, географічно більш "правильне" рішення передбачало б набагато більше обчислювальних витрат, ніж я вважаю, виправдане тут.

І, безумовно, обов'язково повідомте про це команді ESA, як запропонував Керстен у коментарях. Я дійсно не розумію, чому вони обрали таку зайво згорнуту організаційну систему.

— Сенші
джерело

Тут пов’язана відповідна публікація

Що для мене працює - це використовувати S2 KML, наданий ESA, для обчислення всіх плиток там, що перетинаються з моїм AOI, а потім пошук цих плиток у AWS.

Цей KML, здається, працює як визначення всіх можливих ідентифікаторів плитки, генерованих S2, усуваючи безліч варіантів, що перекриваються.

Переглядаючи KML (лише візуальний огляд, не впевнений на 100%), мені здається, що в гіршому випадку вам доведеться шукати 4 плитки.

Було б непогано мати алгоритм, який ESA використовував для визначення KML, щоб зробити це більш ефективним.

— Фред Ліпорас
джерело