प्रहरी -2 में NATO UTM स्थान नहीं पा सकते हैं

Question

निर्देशांक के संबंध में 31.96212, -103.004715

UTM कन्वर्टर्स दे यह UTM निर्देशांक हैं 13/R/FR।

उदाहरण कनवर्टर यहाँ है: http://www.rcn.montana.edu/resources/converter.aspx

लेकिन उनमें से कई हैं और वे इन निर्देशांक के लिए समान जवाब देते हैं।

इसके साथ ही, प्रहरी -2 डेटासेट में यहाँ http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/

मुझे FRउपनिर्देशिका नहीं मिल रही है ।

Google में यह स्थान यहां है:

और सेंटिनल इमेज ब्राउजर में मुझे वही जगह मिल रही है , वह टाइल अलग है

जो एक ही और वर्ग के लिए खड़ा है13/S/FRUTM , लेकिन अलग बैंड।

यह कैसे हो सकता है?

अपडेट करें

सेंटीनेल -2 टाइल्स के साथ केएमएल भी Sदिए गए स्थान में टाइल की रिपोर्ट करता है

अद्यतन २

इस चित्र के अनुसार

यहाँ से लिया गया , FRवर्ग SUTM ज़ोन में आधा और ज़ोन में आधा स्थित Rहै। जाहिर है, अधिकांश स्वचालित कन्वर्टर्स इस वर्ग को Rज़ोन में असाइन करते हैं, जबकि सेंटिनल -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।

प्रहरी -2 डेटा में यह त्रुटि है या क्या है?

Comments

क्या ऐसा नहीं है? sentinel-s2-l1c.s3.amazonaws.com/tiles/13/S/FR/2017/5/6/0/… विभिन्न बैंडों में संतरी- s2-l1c.s3-website.eu-central-1.amazonaws हैं .com / # टाइल्स / 13 / ...

— Mapperz

यह है S/FR, जबकि UTM कन्वर्टर्स देते हैं R/FR। यदि यूटीएम कन्वर्टर्स गलत तरीके से काम करते हैं तो स्थान की गणना कैसे करें?

— मंद

अक्षांश का मान केवल 32 डिग्री उत्तर में है। यह इसे आर अक्षांश "बैंड" में चौकोर रूप से रखता है। सेंटिनल -2 टाइल के केंद्र बिंदु का उपयोग करके टाइल किया जा सकता है जो इसके बजाय "एस" बैंड में हो सकता है।

— mkennedy

@mkennedy निर्देशांक से शुरू होने वाले इस एल्गोरिदम का अनुकरण कैसे करें?

— मंद

आप इसे [e-mail] पर रिपोर्ट करने पर भी विचार कर सकते हैं, क्योंकि यह वास्तव में अप्रत्याशित व्यवहार की तरह दिखता है।

— केर्स्टन

Answer 1

आपके टिप्पणी प्रश्न के जवाब में "इस एल्गोरिथ्म का अनुकरण कैसे करें":

यह एक बहुत ही शानदार समाधान है, लेकिन इसे लागू करना आसान है और इसे अच्छा प्रदर्शन देना चाहिए:

1. निर्देशांक को 13R में रखते हुए "अपेक्षित रूप से" काम करने वाले किसी भी UTM कन्वर्टर्स का उपयोग करें।

2. फिर, जांचें कि क्या सेंटीनेल 2 डेटा संरचना में फ़ोल्डर मौजूद है। यदि हाँ, तो आप कर रहे हैं, हुर्रे।

3. यदि नहीं, तो पड़ोसी UTM ग्रिड की जाँच करें और देखें कि क्या उनमें टाइल / फ़ोल्डर "FR" मौजूद है। यह देखते हुए कि हर जगह ओवरलैप्स हैं, आपको आसपास के सभी 8 ग्रिडों की जांच करनी होगी।
   जांच करने का सबसे संभावित आदेश 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q होगा।
   अंतिम चार प्रासंगिक हो सकते हैं यदि आपके निर्देशांक एक UTM क्षेत्र के कोनों में हैं, लेकिन अत्यधिक संभावना नहीं है।

सेंटिनल 2 लेबल टाइल्स के रास्ते को देखते हुए, पड़ोसियों में से किसी एक के पास कभी भी ऐसा फ़ोल्डर होना चाहिए, जिससे आपको सही फ़ाइल मिल सके।

किसी भी अन्य, भौगोलिक रूप से अधिक "सही" समाधान में पूरे बहुत अधिक कम्प्यूटेशनल ओवरहेड शामिल होंगे, जो मुझे लगता है कि यहां उचित है।

और निश्चित रूप से, टिप्पणी में केर्स्टन द्वारा सुझाए गए ईएसए टीम को निश्चित रूप से इसकी रिपोर्ट करें। मुझे वास्तव में समझ में नहीं आता है कि उन्होंने इस तरह के अनावश्यक रूप से जटिल संगठनात्मक प्रणाली को क्यों चुना।

Answer 2

संबंधित पोस्ट यहाँ

मेरे लिए जो काम किया गया है वह ईएसए द्वारा प्रदान किए गए एस 2 केएमएल का उपयोग करना है जो वहां की सभी टाइलों की गणना करता है जो कि मेरे एओआई के साथ प्रतिच्छेद करते हैं, और फिर एडब्ल्यूएस में इन टाइलों की खोज करते हैं।

यह केएमएल एस 2 द्वारा उत्पन्न सभी संभावित टाइल आईडी की परिभाषा के रूप में काम करता है, बहुत सारे अतिव्यापी विकल्पों को समाप्त करता है।

केवल KML (दृश्य निरीक्षण, 100% सुनिश्चित नहीं) को देखकर मुझे यह लगता है कि सबसे खराब स्थिति में आपको 4 टाइलों की खोज करनी होगी।

यह एल्गोरिथ्म अच्छा होगा कि ईएसए ने इसे और अधिक कुशल बनाने के लिए केएमएल को परिभाषित किया।