Sentinel-2'de NATO UTM konumu bulunamıyor

Saygı koordinatları 31.96212, -103.004715

UTM dönüştürücüler UTM koordinatlarını verir 13/R/FR.

Örnek dönüştürücü burada: http://www.rcn.montana.edu/resources/converter.aspx

Fakat birçoğu var ve bu koordinatlar için benzer cevaplar veriyorlar.

Eşzamanlı olarak, Sentinel-2 veri kümesinde http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

FRAlt dizin bulamıyorum .

Google'da bu konum burada:

Ve Sentinel görüntü tarayıcısında aynı yeri bulduğumda, bu kutucuk farklı

hangi açılımı13/S/FR yani aynı UTMve kare, ancak farklı grup.

Bu nasıl mümkün olabilir?

GÜNCELLEME

Sentinel-2 döşemeli KML ayrıca Sverilen konumdaki döşemeyi de bildirir

GÜNCELLEME 2

Bu resme göre

Buradan alındığında , FRkare yarısı SUTM bölgesinde, yarısı da Rbölgede bulunur. Açıkçası, çoğu otomatik dönüştürücü bu kareyi Rbölgeye atarken Sentinel-2 bunu Sbölgeye göre hesaplıyor.

Burada herhangi bir gerçek var mı?

GÜNCELLEME 3

Buradan alınan basit Python kodu 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)

Ayrıca geri döner 13R.

Bu hata Sentinel-2 verilerinde mi yoksa ne?

— kararır
kaynak

Değil mi? sentinel-s2-l1c.s3.amazonaws.com/tiles/13/S/FR/2017/5/6/0/… farklı bantlar sentinel-s2-l1c.s3-website.eu-central-1.amazonaws .com / # fayans / 13 /…

— Mapperz

Öyle S/FRUTM dönüştürücüler verirken, R/FR. UTM dönüştürücüler yanlış çalışırsa konum nasıl hesaplanır?

— Dims

Enlem değeri 32 derecenin hemen altında. Bu onu R enlemi "bandına" koyar. Sentinel-2, bunun yerine "S" bandında olabilen döşemenin merkez noktasını kullanarak döşenmiş olabilir.

— mkennedy

@mkennedy koordinatlardan başlayarak bu algoritmayı nasıl simüle edebilirim?

— Dims

Bunu gerçekten eosupport@copernicus.esa.int'e bildirmeyi de düşünebilirsiniz, çünkü gerçekten beklenmedik bir davranışa benziyor.

— Kersten

Yanıtlar:

"Bu algoritmanın nasıl simüle edileceği" yorum sorunuza yanıt olarak:

Bu oldukça kaba bir çözümdür, ancak uygulanması kolaydır ve iyi performans vermelidir:

13R'ye koordinatları yerleştirerek "beklendiği gibi" çalışan UTM dönüştürücülerden herhangi birini kullanın.
Ardından, klasörün Sentinel 2 veri yapısında olup olmadığını kontrol edin. Evet ise, işiniz bitti, yaşasın.
Değilse, komşu UTM ızgaralarını kontrol edin ve içinde "FR" döşemesinin / klasörünün olup olmadığını kontrol edin. Her yerde çakışmalar olduğu için, çevreleyen 8 ızgarayı kontrol etmeniz gerekir.
Kontrol edilmesi en muhtemel sipariş 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q olacaktır.
Son dördü, koordinatlarınız bir UTM bölgesinin köşelerinde bulunuyorsa, ancak pek olası değilse, ilgili olabilir.

Sentinel2'nin karoları etiketleme şekli göz önüne alındığında, komşulardan sadece birinin böyle bir klasörü olması gerekir, bu da doğru dosyayı almanızı garanti eder.

Coğrafi olarak daha "doğru" herhangi başka bir çözüm, burada haklı olduğunu düşündüğümden çok daha fazla hesaplama yükü gerektirecektir.

Ve kesinlikle, kesinlikle Kersten tarafından yorumlarda önerildiği gibi ESA ekibine bildirin. Neden bu kadar gereksiz kıvrık bir örgütsel sistemi seçtiklerini gerçekten anlamıyorum.

— senshi
kaynak

İlgili yayın burada

Benim için çalışan, ESO tarafından sağlanan S2 KML'yi kullanarak AOI ile kesişen tüm karoları hesaplamak ve daha sonra bu karoları AWS'de aramak.

Bu KML, birçok örtüşen seçeneği ortadan kaldırarak S2 tarafından üretilen tüm olası döşeme kimliklerinin bir tanımı olarak çalışıyor gibi görünüyor.

KML'ye bakarak (sadece görsel inceleme,% 100 emin değilim) bana göre en kötü durumda 4 karo aramak zorunda kalacaksınız.

ESA'nın bunu daha verimli hale getirmek için KML'yi tanımlamak için kullandığı algoritmaya sahip olmak güzel olurdu.

— Fred Liporace
kaynak