Không thể tìm thấy vị trí UTM của NATO trong Sentinel-2

Phối hợp tọa độ 31.96212, -103.004715

Bộ chuyển đổi UTM cung cấp cho tọa độ UTM của nó 13/R/FR.

Trình chuyển đổi ví dụ có tại đây: http://www.rcn.montana.edu/resource/converter.aspx

Nhưng có rất nhiều trong số họ và họ đưa ra câu trả lời tương tự cho các tọa độ này.

Đồng thời, trong tập dữ liệu Sentinel-2 tại đây http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

Tôi không thể tìm thấy FRthư mục con.

Trong google vị trí này là ở đây:

Và tìm cùng một vị trí trong trình duyệt hình ảnh Sentinel mà tôi thấy, ô đó khác

đó là viết tắt của13/S/FR tức là cùng UTMban nhạc và hình vuông, nhưng khác nhau.

Sao có thể như thế được?

CẬP NHẬT

KML với các ô Sentinel-2 cũng báo cáo Sô ở vị trí đã cho

CẬP NHẬT 2

Theo hình này

Lấy từ đây , FRhình vuông nằm một nửa trong Skhu vực UTM và một nửa trong Rkhu vực. Rõ ràng, hầu hết các bộ chuyển đổi tự động gán hình vuông này cho Rvùng, trong khi Sentinel-2 chiếm nó cho Svùng.

Có sự thật nào ở đây không?

CẬP NHẬT 3

Mã Python đơn giản, được lấy từ đây /gis//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)

cũng trở về 13R.

Đây có phải là lỗi trong dữ liệu Sentinel-2 hay không?

Để trả lời cho câu hỏi bình luận của bạn "làm thế nào để mô phỏng thuật toán này":

Đây là một giải pháp khá đơn giản, nhưng dễ thực hiện và sẽ cho hiệu suất tốt:

1. Sử dụng bất kỳ bộ chuyển đổi UTM nào hoạt động "như mong đợi", đặt tọa độ trong 13R.

2. Sau đó, kiểm tra xem thư mục có tồn tại trong cấu trúc dữ liệu Sentinel 2 không. Nếu có, bạn đã hoàn thành, hoan hô.

3. Nếu không, hãy kiểm tra các lưới UTM lân cận và xem liệu gạch / thư mục "FR" có tồn tại trong chúng không. Do có sự chồng chéo ở khắp mọi nơi, bạn sẽ phải kiểm tra tất cả 8 lưới xung quanh.
   Thứ tự có khả năng kiểm tra nhất sẽ là 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
   Bốn cuối cùng có thể có liên quan nếu tọa độ của bạn nằm trong các góc của vùng UTM, nhưng rất khó xảy ra.

Theo cách xếp nhãn Sentinel2, chỉ một trong những hàng xóm nên có một thư mục như vậy, đảm bảo bạn có được tệp chính xác.

Bất kỳ giải pháp "chính xác" nào khác về mặt địa lý sẽ liên quan đến toàn bộ chi phí tính toán nhiều hơn tôi cảm thấy hợp lý ở đây.

Và chắc chắn, chắc chắn báo cáo điều này với nhóm ESA theo đề xuất của Kersten trong các bình luận. Tôi thực sự không hiểu tại sao họ lại chọn một hệ thống tổ chức phức tạp không cần thiết như vậy.

Bài viết liên quan ở đây

Điều đã và đang làm việc với tôi là sử dụng KML S2 do ESA cung cấp để tính toán tất cả các ô ở đó giao với AOI của tôi và sau đó tìm kiếm các ô này trong AWS.

KML này dường như hoạt động như một định nghĩa về tất cả các id gạch có thể được tạo bởi S2, loại bỏ rất nhiều tùy chọn chồng chéo.

Bằng cách xem KML (chỉ kiểm tra trực quan, không chắc chắn 100%) đối với tôi, trong trường hợp xấu nhất bạn sẽ phải tìm kiếm 4 ô.

Thật tuyệt khi có thuật toán mà ESA đã sử dụng để định nghĩa KML để làm cho việc này hiệu quả hơn.