ไม่พบตำแหน่ง NATO UTM ใน Sentinel-2


10

คำนึงถึงพิกัด 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และสี่เหลี่ยม แต่วงดนตรีที่แตกต่างกัน

เป็นไปได้อย่างไร?

UPDATE

KML ที่มีไทล์ Sentinel-2 จะรายงาน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 หรืออะไร


ไม่ใช่เหรอ sentinel-s2-l1c.s3.amazonaws.com/tiles/13/S/FR/2017/5/6/0/…วงดนตรีที่แตกต่างกันคือsentinel-s2-l1c.s3-website.eu-central-1.amazonaws .com / # tiles / 13 / …
Mapperz

มันเป็นS/FRในขณะที่แปลง UTM R/FRให้ จะคำนวณตำแหน่งอย่างไรถ้าตัวแปลง UTM ทำงานผิดพลาด?
Dims

ค่าละติจูดต่ำกว่า 32 องศาเหนือ นั่นทำให้มันตรงใน "ละติจูด" วงดนตรีละติจูด Sentinel-2 อาจเรียงต่อกันโดยใช้จุดกึ่งกลางของแผ่นกระเบื้องซึ่งอาจอยู่ในแถบ "S" แทน
mkennedy

@mkennedy วิธีการจำลองอัลกอริทึมนี้เริ่มต้นจากพิกัดหรือไม่
Dims

2
คุณอาจลองรายงานเรื่องนี้กับ eosupport@copernicus.esa.int เพราะมันดูเหมือนจะมีพฤติกรรมที่ไม่คาดคิด
Kersten

คำตอบ:


1

ในการตอบคำถามความคิดเห็นของคุณ "วิธีจำลองอัลกอริทึมนี้":

นี่เป็นวิธีที่ดุร้าย แต่ใช้งานง่ายและควรให้ประสิทธิภาพที่ดี:

  1. ใช้ตัวแปลง UTM ใด ๆ ที่ทำงาน "ตามที่คาดไว้" โดยวางพิกัดใน 13R
  2. จากนั้นตรวจสอบว่ามีโฟลเดอร์อยู่ในโครงสร้างข้อมูล Sentinel 2 หรือไม่ ถ้าใช่คุณทำเสร็จแล้วไชโย

  3. ถ้าไม่ตรวจสอบกริด UTM ที่อยู่ใกล้เคียงและดูว่ามีไทล์ / โฟลเดอร์ "FR" อยู่หรือไม่ เนื่องจากมีการทับซ้อนกันทุกที่คุณต้องตรวจสอบทั้งหมด 8 กริดโดยรอบ
    คำสั่งที่น่าจะตรวจสอบมากที่สุดคือ 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q
    สี่ครั้งสุดท้ายอาจมีความเกี่ยวข้องหากพิกัดของคุณอยู่ในมุมของโซน UTM แต่ไม่น่าเป็นไปได้

เมื่อพิจารณาถึงวิธีการติดป้ายกำกับ Sentinel2 มีเพียงหนึ่งในประเทศเพื่อนบ้านเท่านั้นที่ควรมีโฟลเดอร์ดังกล่าวรับประกันว่าคุณจะได้รับไฟล์ที่ถูกต้อง

โซลูชันอื่น ๆ ที่ "ถูกต้อง" ทางภูมิศาสตร์มากกว่านั้นจะเกี่ยวข้องกับค่าใช้จ่ายในการคำนวณมากกว่าที่ฉันรู้สึกว่าถูกต้องที่นี่

และแน่นอนรายงานสิ่งนี้ต่อทีม ESA ตามที่ Kersten แนะนำในความคิดเห็น ฉันไม่เข้าใจจริงๆว่าทำไมพวกเขาเลือกระบบองค์กรที่ซับซ้อนเช่นนี้โดยไม่จำเป็น


0

โพสต์ที่เกี่ยวข้องที่นี่

สิ่งที่ได้ผลสำหรับฉันคือการใช้ S2 KML ที่ ESA จัดทำขึ้นเพื่อคำนวณกระเบื้องทั้งหมดที่มีที่ตัดกับ AOI ของฉันแล้วค้นหากระเบื้องเหล่านี้ใน AWS

KML นี้ดูเหมือนจะทำงานเป็นคำจำกัดความของรหัสกระเบื้องที่เป็นไปได้ทั้งหมดที่สร้างโดย S2 โดยขจัดตัวเลือกที่ทับซ้อนกันมากมาย

โดยการดู KML (การตรวจสอบด้วยภาพเท่านั้นไม่แน่ใจ 100%) สำหรับผมแล้วในกรณีที่แย่ที่สุดคุณต้องค้นหา 4 แผ่น

มันจะดีถ้ามีอัลกอริทึมที่ ESA ใช้เพื่อกำหนด KML เพื่อให้มีประสิทธิภาพมากขึ้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.