QGIS क्षेत्र की गणना भिन्न होती है जब फ्लाई CRS परिवर्तन सक्षम होता है

जब मैं QGIS खोलता हूं, तो लेयर जोड़ें, और फ़ील्ड कैलकुलेटर के माध्यम से शेपफाइल के क्षेत्रों की गणना करें जब मैं QGIS खोलता हूं तो "मैं सीआरएस परिवर्तन को सक्षम करता हूं" की तुलना में एक अलग क्षेत्र प्राप्त करता हूं और क्षेत्र की गणना करता हूं। यह सुनिश्चित करने के बावजूद कि परियोजना और परत में समान समन्वय प्रणाली (समान EPSG संख्या) है। मैं क्या गलत कर रहा हूं?

मेरे पास आर्कजीआईएस के साथ किए गए क्षेत्र की गणनाओं के साथ एक आकृति है (मुझे नहीं हो, डेटा मुझे सौंप दिया गया था और मेरे पास कोई सुराग नहीं है जिसके लिए सीआरएस क्षेत्र की गणना आर्कजीआईएस के साथ की गई थी)। शेपफाइल लेयर CRS EPSG: 21781 (स्विट्जरलैंड) है। QGIS में, अगर मैं OTF सेटिंग नहीं बदलता और परियोजना CRS को EPSG: 4326 (WGS84) के रूप में छोड़ता हूँ, तो मुझे आर्कजीआईएस क्षेत्र मान के समान मूल्य मिलता है। हालाँकि, अगर मैं ईपीएसजी में परत जोड़ने से पहले ओटीएफ को बदल देता हूं: 21781 मुझे अलग-अलग क्षेत्र मान मिलते हैं। जैसा कि मैं समझता हूं कि यह बताता है कि आर्किस एरिया की गणना सीआरएस ईपीएसजी: 4326 के साथ की गई थी।

पहला वर्कफ़्लो:

QGIS खोलें
परियोजना CRS: EPSG 4326
परत जोड़ें
परियोजना सीआरएस स्वचालित रूप से लागू होती है और अभी ईपीएसजी 21781 है
क्षेत्र कैलकुलेटर के साथ $ क्षेत्र की गणना करें

दूसरा वर्कफ़्लो:

QGIS खोलें
परियोजना CRS: EPSG 4326
OTF चालू करें, प्रोजेक्ट CRS को EPSG 21781 पर सेट करें
परत जोड़ें
क्षेत्र कैलकुलेटर के साथ $ क्षेत्र की गणना करें

पहले और दूसरे वर्कफ़्लो के चरण 5 एक ही क्षेत्र का उत्पादन न करें।

qgis coordinate-system area

— kalakaru
स्रोत

क्या आप उपयोग किए गए वर्कफ़्लो और टूल का उदाहरण दे सकते हैं; मैंने इसे WGS84 में ऑन-द-फ्लाई सक्षम और अक्षम करने की कोशिश की है और इसने उसी क्षेत्र को दिया है। यह $areaदर्ज कैलकुलेटर में उपयोग कर रहा है। संक्षेप में, ऑन-द-फ्लाई प्रभावित करता है कि डेटा डे-फैक्टो में बदलाव किए बिना ज्यामिति कैसे प्रदर्शित की जा रही है। इस प्रकार यह संभव है कि त्रुटि वर्कफ़्लो के कारण हो।

— dof1985

क्या $ क्षेत्र परतों या परियोजनाओं के समन्वय प्रणाली के आधार पर क्षेत्र की गणना करता है?

— कलाकरु

मैंने जाँच की है और यह ओटीएफ इकाइयों में क्षेत्र को दे रहा है; फिर भी मुझे पूरा यकीन है कि यह परत की ज्यामिति का उपयोग स्वयं करता है

— dof1985

यही मेरी समस्या की जड़ हो सकती है। मेरे पास आर्कगिस के साथ किए गए एरिया कैलकुलेशन के साथ शेपफाइल है (मैं नहीं हूं, डेटा मुझे सौंप दिया गया था और मेरे पास कोई सुराग नहीं है जिसके लिए सीआरएस एरिया की गणना आर्कगिस से की गई थी)। आकृति आकार की परत सीआरएस ईपीएसजी: 21781 (स्विट्जरलैंड) है। अगर मैं ओटीएफ सेटिंग्स पर बदलाव नहीं करता हूं और प्रोजेक्ट सीआरएस को ईपीएसजी: 4326 (डब्ल्यूजीएस 84) के रूप में छोड़ देता हूं तो मुझे आर्कजी एरिया एरिया वैल्यू के समान मूल्य मिलता है। हालाँकि, अगर मैं ईपीएसजी में परत जोड़ने से पहले ओटीएफ को बदल देता हूं: 21781 मुझे अलग-अलग क्षेत्र मान मिलते हैं। जैसा कि मैं समझता हूं कि आर्कजीस क्षेत्र की गणना सीआरएस ईपीएसजी: 4326 के साथ की गई थी।

— कलाकरु

जहाँ तक मैं जानता हूँ कि आर्गिस कई तरीकों से ज्यामिति की गणना कर सकता है। क्षेत्र कैलकुलेटर की अजगर अभिव्यक्ति का उपयोग !shape.area!परत सीआरएस के अनुसार क्षेत्र देना चाहिए; गणना की तुलना में ज्यामिति अलग काम कर सकती है। इसलिए यह बताना मुश्किल है, वास्तव में क्या ArcGIS में किया गया था, फिर भी अगर आप एक ही परिणाम प्राप्त है, जैसे डिग्री और न मीटर की दूरी पर है, यह meens उस क्षेत्र गणना वास्तव में ESPG पर आधारित था: 4326.

— dof1985

जवाबों:

EDIT - अस्वीकरण: मैं पाठकों को नीचे क्रिस की चर्चा के साथ संदर्भित करना चाहूंगा। यह हो सकता है कि ओटीएफ सीआरएस के आधार पर एक क्षेत्र प्राप्त करना सब के बाद बग नहीं है; यानी, कम से कम, आर्कगिस में इसका उपयोग विभिन्न सीआरएस से दो परतों को जियोप्रोसेस करने की अनुमति देने के लिए भी किया जा रहा है।

ऊपर के मुद्दे पर विस्तार से बताने के लिए। जैसा कि आंद्रे जे ने सुझाव दिया था और दिखाते हैं - यह शायद कगिस के वर्तमान संस्करण में एक बग है। फिर भी यह ध्यान दिया जाना चाहिए कि समस्या गलत क्षेत्र नहीं है, लेकिन यह कि क्षेत्र में गणना पर किसी भी तरह से परिवर्तन का प्रभाव प्रभावित होता है।

ऑन-द-फ्लाई ट्रांस्फ़ॉर्मेशन / प्रोजेक्शन का उद्देश्य विभिन्न स्रोतों से और विभिन्न सीआरएस के साथ डेटा को संरेखित करना है। यह मुख्य रूप से प्रदर्शन उद्देश्यों के लिए है। ईजी arcmap स्वचालित रूप से किसी भी मामले में एक परत CRS डेटा फ्रेम CRS से मेल नहीं खाता में-पर-उड़ान प्रक्षेपण करते हैं।

आर्कमैप डेटा को संपादित करने की संभावना प्रदान करता है, जबकि-ऑन-द-फ्लाई का अनुमान लगाया जाता है, लेकिन यह भी नोट करता है: ( स्रोत )

हालांकि, यह ध्यान रखना महत्वपूर्ण है कि कुछ संपादन संचालन अप्रत्याशित संरेखण या सटीकता की समस्याएं पैदा कर सकते हैं, जो कि समन्वयित प्रणालियों के उपयोग पर निर्भर करता है।

विशिष्ट संपादन कार्य जिनके कारण समस्याएँ हो सकती हैं, उनमें सुविधाओं की आकृतियों को बदलना, किनारे पर तड़कना या सुविधाओं की सीमा या विस्तार और ट्रिमिंग सुविधाएँ शामिल हैं। ये समस्याएँ तब अधिक होती हैं जब आपके द्वारा संपादित की जा रही सुविधाएँ किनारे के करीब होती हैं या समन्वय प्रणाली के उपयोग के क्षेत्र से परे होती हैं

यह कहना है: एक अलग सीआरएस (जो भी अपनी समस्याओं का परिचय देता है) को डेटा को प्रोजेक्ट करने की तुलना में फ्लाई ट्रांसफॉर्मेशन कम तीक्ष्ण है।

यह कहते हुए कि यह आश्चर्यजनक नहीं है कि ऑन-द-फ्लाई ट्रांस्फ़ॉर्म के आधार पर एक गलत क्षेत्र की गणना की जा रही है, फिर भी यह आश्चर्य की बात है कि ऑन-द-फ्लाई सक्षम किया गया था जो किसी भी तरह से ज्यामिति की गणना को प्रभावित करता है, जिसे करना चाहिए डेटा पर आधारित हो। इस प्रकार, यह कोई फर्क नहीं पड़ता कि ऑन-द-फ्लाई ट्रांसफॉर्मेशन एक ही या एक अलग सीआरएस पर आधारित है, क्षेत्र की गणना हर बार समान होनी चाहिए।

अधिक व्यावहारिक होने के लिए, यदि आपका उद्देश्य इस क्षेत्र की गणना करना है तो ऑन-द-फ्लाई का उपयोग न करें। यदि आपके पास गलत सीआरएस है, तो अपना डेटा प्रोजेक्ट करें।

— dof1985
स्रोत

मैं QGIS के बारे में निश्चित नहीं हूं, लेकिन आपके द्वारा यहां बताए गए कुछ विपरीत रूप से ArcGIS वास्तव में ओटीएफ प्रोजेक्शन या पूरी तरह से अलग प्रोजेक्शन का उपयोग करते हुए विधि के आधार पर पूरी तरह से अलग प्रोजेक्शन कर सकते हैं (यानी राइट-क्लिक करें विशेषता कॉलम और चुनें कैलिब्रेट ज्यामिति बनाम एक आकार / आकार के कोड / क्षेत्र कैलकुलेटर कॉल)। कभी-कभी 1) डेटा / लेयर, 2) का उपयोग करने के लिए विकल्प दिए जाते हैं। वर्तमान डेटाफ़्रेम, 3) एक निर्दिष्ट सीआरएस जो 1 या 2 से असंबंधित है (आमतौर पर, फिर से, आर्कजीआईएस) यदि पसंद प्रस्तुत नहीं किया गया है तो यह किया जाएगा। वर्तमान डेटाफ़्रेम का सीआरएस, इस बात पर ध्यान दिए बिना कि डेटा क्या है (इसलिए OTF)।

— क्रिस डब्ल्यू

मुझे यह भी उल्लेख करना चाहिए कि ओटीएफ केवल प्रदर्शन के उद्देश्य के लिए नहीं है - एक जियोप्रोसेसिंग टूल को चलाने के लिए किसी डेटासेट को अस्वीकार करने की आवश्यकता नहीं है जो एक अलग सीआरएस के साथ एक डेटासेट का उपयोग करता है; OTF हैंडल करता है। इस के लिए कुछ अपवादों को छोड़कर, जब दोनों डेटासेट हैं करते ही सीआरएस में रहना होगा।

— क्रिस डब्ल्यू

@ क्रिस, अगर मैं सही ढंग से समझता हूं; कुछ जियोप्रोसेसिंग उपकरण ओटीएफ सीआरएस को स्वीकार करते हैं क्योंकि यह परत का सीआरएस था। इस प्रकार ओटीएफ सीआरएस पर आधारित क्षेत्र प्राप्त करना जरूरी नहीं है कि एक बग हो। क्या वो सही है? आर्कगिस के बारे में, आइए हम WGS84 को ओटीएफ मान लें; क्या एक कॉल के बारे में की तरह:!shape.area@meters!

— dof1985

यह सही है। आपकी डेटाफ्रेम और पहली परत WGS84 हो सकती है, और आप एक दूसरी परत जोड़ सकते हैं जो कि NAD83 है। दूसरी परत ओटीएफ अनुमानित है, और आप इस पर किसी भी सामान्य उपकरण जैसे इंटरसेक्ट या यूनियन को चला सकते हैं और ऑपरेशन WGS84 में होता है। निश्चित रूप से क्षेत्र प्राप्त करना बग नहीं है। मेरे पास एक क्लाइंट है जो NAD83 में डेटा चाहता है, लेकिन जानकारी के लिए एकड़ में इकाइयों की आवश्यकता होती है और मैं जानकारी दर्ज करने के लिए एक अनुमानित सीआरएस में काम करता हूं। मैं आमतौर पर डेटाफ्रेम प्रोजेक्शन, कैल्क क्षेत्र को बदल देता हूं, और फिर इसे वापस स्विच करता हूं। मुझे यकीन नहीं है कि जब से मुझे लगता है कि यूनिट रूपांतरण गणना से अलग है, तब उस कॉल को कैसे संभाला जाएगा।

— क्रिस डब्ल्यू

मैं पुष्टि कर सकता हूं कि यह एक बग लगता है।

निम्नलिखित सामग्री के साथ एक csv फ़ाइल बनाएँ:

E N
600000 200000
700000 200000
700000 300000
600000 300000

इसे ईपीएसजी के साथ सीमांकित पाठ के रूप में आयात करें: 21781, स्नैपिंग को सक्षम करें और चार बिंदुओं पर एक बहुभुज को आकार दें।

ओटीएफ के बिना, परिणाम $area/1000000.010000 m result है (जो स्पष्ट रूप से सही है)।

OTF टर्निंग पर , और एक ही EPSG का चयन: 21,781, आप 9988.2338 वर्ग मीटर मिलता है।

ईपीएसजी: 4326 जैसे एक अलग सीआरएस को चुनना, 9990.5339 वर्ग मीटर में बचाता है, क्योंकि गणना एक अलग दीर्घवृत्त (डब्ल्यूजीएस84 के बजाय बेसेल) पर की जाती है।

Vector --> Geometry Tools --> Export/Add Geometry Columns सही मान देने लगता है।

बग में पहले से ही कुछ टिकट हैं: https://issues.qgis.org/issues/10966 और https://issues.qgis.org/issues/12473

— Andrej
स्रोत