भू-स्थानिक डेटा के लिए संस्करण नियंत्रण प्रणाली को लागू करना? [बन्द है]


28

ऐसा नहीं है कि मैं यहाँ एक सही उत्तर की तत्काल आवश्यकता में हूँ, लेकिन मैंने हाल ही में भौगोलिक डेटा के लिए "(वितरित) संस्करण नियंत्रण प्रणालियों" की अवधारणा को पेश करने के कुछ प्रयास देखे हैं। नॉर्दर्न जीआईएस सॉफ्टवेयर विक्रेताओं और नॉर्वेजियन मैपिंग एजेंसी द्वारा ओपनजीओ ( 1 , 2 और 3 ) और " जियोसिंक्रोनिसरिंग (जियोसिंक्रोनाइज़ेशन)" परियोजना के तीन उदाहरणों के कुछ उदाहरण (जो मुझे पता है) हैं । मैंने भू-स्थानिक डेटा का वितरण संस्करण भी पाया है ? , जिसमें जियोगिट (ओपनजीओ द्वारा), और आर्कगिस मॉडलब्यूलर मॉडल पर संस्करण नियंत्रण लागू करने का उल्लेख है? आर्कजीआईएस में संस्करण नियंत्रण के बारे में।

एक डेवलपर होने के नाते मैं जानता हूं (कम से कम उन्हें इस्तेमाल करने में सक्षम) स्रोत कोड (जैसे SVN और Git) के लिए संस्करण नियंत्रण प्रणाली कैसे काम करती है, और भू-विज्ञान में मेरी पृष्ठभूमि मुझे बताती है कि भौगोलिक डेटा के साथ कुछ अनूठी चुनौतियां हैं जो इसे बनाती है जिस तरह से स्रोत कोड (जो मूल रूप से पाठ है) से पूरी तरह से संपर्क नहीं किया जाता है।

भौगोलिक डेटा के लिए (d) VCS'es के साथ काम करते समय क्या चुनौतियाँ हैं, आप उन्हें कैसे हल करेंगे, क्या हमें उनकी आवश्यकता है और क्या इन मुद्दों को हल करने के अन्य प्रयास हैं जो मैंने उल्लेख किए हैं?

मुझे पता है कि ओपनजीओ व्हाइटपैपर्स मेरे कुछ सवालों का जवाब देंगे, लेकिन जो मैं वास्तव में हूं उसके बाद एक और "शैक्षणिक" उत्तर है, "मुझे 10 साल का है जैसे मैं बताता हूं" की शैली में, ताकि मैं लोगों को उन चुनौतियों और समाधानों की एक बड़ी व्याख्या के लिए संदर्भित कर सकता हूं जो भौगोलिक डेटा मिश्रण में लाता है।

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

जवाबों:


19

वर्तमान में हम अपने जियोडैटैस्टोर्स के पूर्ण पुनर्निर्देशन पर काम कर रहे हैं। मेरा कहना है कि उनके विकास में अब तक 20 साल से अधिक का समय लगा। हमने भू-स्थानिक डेटा प्रबंधन में निम्नलिखित प्रमुख विशेषताओं की पहचान की:

  • एक साथ संपादन
  • डेटा के अंश पढ़ने या लिखने की अनुमति
  • डेटा पर भरोसा करने वाली सेवाओं को चलाते समय गर्म अपडेट (लेन-देन और ACID प्रतिमान)
  • आंतरिक और बाह्य स्कीमा (आंतरिक स्कीमा को संशोधित करना सेवाओं को प्रभावित नहीं करना चाहिए)
  • बड़ी मात्रा में डेटा को संग्रहीत करने और उपयोग करने की क्षमता (रैस्टर के टेराबाइट्स और वेक्टर डेटा के गीगाबाइट्स के hundrets)
  • विभिन्न परतों के बीच डेटा की संगति (प्रत्येक पार्सल एक जिले के अंतर्गत आता है और इसी तरह)

हमने निम्नलिखित दृष्टिकोणों का मूल्यांकन किया, यहां मैं उनके बारे में कह सकता हूं:

  1. ईएसआरआई एंटरप्राइज जियोदाटबेस(आर्कजीआईएस 10.1); बहुत कुछ वही है जो हमारे पास पहले (एसडीई) था, लेकिन लेनदेन को संभालने के लिए संस्करण सुविधा के व्यापक उपयोग के साथ। लेकिन यह वास्तव में एक एंटरप्राइज़ जियोडैटेबेस नहीं है, मेरी राय में एसडीई केवल एक कार्यसमूह में जियोडेटा सर्वर के रूप में काम करता है, जहां लोग सुबह 8:00 बजे से रात 8:00 बजे तक काम करते हैं, और आप इसे ऑफ़लाइन रख सकते हैं, फिर रखरखाव कार्यों के लिए, लेनदेन शुरू करना (ईएसआरआई भाषण में सामंजस्य और पोस्ट को साझा करना), प्रतिकृति, आदि ... यदि आप इस डेटा के शीर्ष पर सेवाओं का निर्माण करते हैं, तो आपको एक प्रतिकृति उत्पादन डेटाबेस (जहां काम किया जाता है) को एक दोहराया गया उत्पादन डेटाबेस संभालना होगा। यह प्रोग्रामिंग में बिल्ड / टेस्ट और तैनाती की तरह ही बहुत अधिक है। जबकि सुविधा संपन्न पैकेज ईएसआरआई डिलीवर काफी अच्छा है, लेकिन इसमें फ्लेक्सबिलिटी (स्कीमा में बदलाव, या रखरखाव कार्यों का अभाव है, जबकि लोग काम कर रहे हैं, उदाहरण के लिए इंडेक्स निर्माण)।

  2. फ्लैट फाइलें और एक संस्करण नियंत्रण प्रणालीहम Git चुनते हैं (पता नहीं है कि पहले से ही एक GeoGit है)। अरे हाँ, मेरे कुछ दोस्त और खुद भी सॉफ्टवेयर इंजीनियरिंग से आते हैं। यह सब इतना सरल हो सकता है। मुझे लगता है कि इसकी समस्या है: इसकी एक कार मैकेनिक की तरह एक कार का निर्माण। यह उसके लिए बनाए रखने के लिए सरल होगा, लेकिन यह भी ड्राइव करने के लिए कष्टप्रद होगा और बदसूरत देखने के लिए खराब होगा। मुझे लगता है कि इसके कुछ प्रमुख नुकसान भी हैं: 2 टेराबीटे (या इससे भी अधिक, बाइनरी) रैस्टरडैटसेट को कैसे नियंत्रित किया जाए? और किस प्रारूप में है? यदि आप टैक्स्टेड फॉरमेट (उदाहरण के लिए जीएमएल) का उपयोग करते हैं, तो वेक्टर डेटा आसानी से नियंत्रित किया जा सकता है, लेकिन इसके बाद एक बिलियन वाइडस्क्रीन के साथ काम करना भी कठिन होता है। मुझे अभी भी यकीन नहीं है कि हम प्रभावी उपयोगकर्ता अनुमति प्रबंधन कर सकते हैं, क्योंकि हर किसी को सब कुछ संपादित करने या यहां तक ​​कि देखने की अनुमति नहीं दी जानी चाहिए। और आप एक वेक्टर डेटासेट को कैसे मर्ज करते हैं जो एक ही समय में 4 उपयोगकर्ताओं द्वारा तीव्रता से संपादित किया गया था? कम से कम आपको यह सब प्रभावी ढंग से करने के लिए एक वास्तविक कंप्यूटर वैज्ञानिक / प्रोग्रामर होना चाहिए ... हमारे जीआईएस उपयोगकर्ता योजनाकार, सर्वेक्षणकर्ता, भूवैज्ञानिक और इतने पर हैं। यह बस उनके लिए एक समस्या है कि वे प्रोग्रामर जैसे वर्जन लाइनेज के बारे में सोचते हैं, या जिस तरह से इसकी जरूरत है उस ब्रांचिंग का उपयोग करते हैं। फिर भी, साझा पुनर्खरीद के रूप में डेटस्टोर्स की सोच एक दिलचस्प विचार है।

  3. एक साधारण कंटेनर के रूप में फ्लैट tabled डेटाबेस । एसडीई के रूप में ही करता है, लेकिन एसडीई सामान के बिना। अभी भी बनाए रखने के लिए मुश्किल है, क्योंकि आप वास्तव में एक RDBMS आपको प्रदान करता है फायदे का उपयोग नहीं करते हैं। हाँ एक डेटाबेस में सब कुछ लोड करने के लिए इसका बहुत सरल है, लेकिन डेटा प्रबंधन बिल्कुल नहीं है।

  4. Bigdata और NoSQL । फ्लैट फाइल और फ्लैट टेबल के रूप में समान समस्याएं। मेरी राय में वेब में उपयोग के लिए एक सरल फाइलसिस्टम एपीआई। हां यह वेब में अच्छी तरह से काम करता है, और हाँ इसका आसान है कि आप अपने दस्तावेज़ों को अंदर फेंक दें, लेकिन मुझे लगता है कि अगर मैं (संभवतः रेखापुंज) डेटा के टेराबाइट्स पर स्थानिक डेटा विश्लेषण को पूरा करना चाहता हूं, तो मुझे यह पसंद है कि इसे क्रमबद्ध और निरूपित नहीं किया जाए। HTTP इंटरफ़ेस पर।

UPDATE 2018: यहां बहुत सारी नई चीजें हैं जो बहुत अधिक गति पैदा कर रही हैं। कुछ नाम है:

  • क्लाउड ब्लॉक स्टोरेज और एचडीएफएस
  • पायथन / सुडौल / डस्क स्टैक
  • अपाचे स्पार्क

    • वेक्टर डेटा के लिए जियोमेसा / जियोवेव
    • रेखापुंज डेटा के लिए GeoTrellis
  • और भी बहुत कुछ

    1. व्यापक क्लासिक डेटाबेस मॉडलिंग(RDBMS के साथ)। मुख्य समस्या यह है कि इसकी कड़ी मेहनत से कहीं भी डेटा को छोड़ दिया जाता है और आशा है कि यह भविष्य की हर जरूरत को पूरा करता है। लेकिन यदि आप एक डेटाबेस में एक मजबूत डेटामॉडेल (OSM ने भी वास्तव में ऐसा किया है) निर्दिष्ट करने के लिए समय की राशि डालते हैं, तो आप इसके सभी लाभों का उपयोग करने में सक्षम हैं। हम वितरित लेनदेन में डेटा को संपादित और अपडेट कर सकते हैं, हम उनके कोर स्कीमा को भी संशोधित कर सकते हैं, जबकि सेवाएं अभी भी उसी डेटा के बाहरी स्कीमा पर निर्भर हैं, हम इसे बनाए रख सकते हैं, हम इसकी निरंतरता की जांच कर सकते हैं, हम अनुमति दे सकते हैं और इनकार कर सकते हैं, हम हैं बहुत बड़ी मात्रा में डेटा संग्रहीत करने में सक्षम जबकि हम अभी भी इसे तेजी से एक्सेस कर सकते हैं, हम ऐतिहासिक डेटामॉडल्स का निर्माण करने और इसे पारदर्शी रूप से और इतने पर ट्रिगर करने में सक्षम हैं। चूँकि हम sql सर्वर का उपयोग करते हैं, हम अभी भी एक देशी रेखापुंज प्रकार की कमी कर रहे हैं, लेकिन अन्य डेटाबेस विक्रेता पहले से ही यह पेशकश करते हैं।

वैसे मुझे लगता है कि रिलेशनल डेटाबेस मॉडल पिछले कुछ वर्षों में स्थानिक डेटा प्रकारों के साथ स्थानिक दुनिया में उठता है (इससे पहले जहां यह BLOB कंटेनर है) और अभी भी डेटा संग्रहीत करने का सबसे लचीला और व्यावसायिक रूप है। इसका मतलब यह नहीं है कि इसे वीसीएस दृष्टिकोण या नोएसक्यूएल के साथ पूरक नहीं किया जाना चाहिए, लेकिन मैं इन दृष्टिकोणों को पेशेवर केंद्रीकृत स्थानिक डेटा प्रबंधन के रूप में उपयोगकर्ताओं के समूहों में डेटा वितरण के रूप में अधिक संभावना देखता हूं। इसके अलावा, OSM ने बहुत सारे कार्यों को केंद्रीकृत किया है, जो भीड़ सिर्फ प्रदान नहीं कर सकती है, जैसे बड़ी मात्रा में डेटा आयात करना (ऑस्ट्रिया में सबसे OSM डेटा एक दिन में आयात किया गया था, भीड़ नहीं थी) और टाइल पीढ़ी। सहयोगी (क्राउड सोर्सिंग) हिस्सा वास्तव में बहुत महत्वपूर्ण है, लेकिन इसका केवल आधा कारोबार है।

मुझे लगता है कि मुझे इसके बारे में बहुत कुछ बताना है और अधिक तथ्य प्रदान करना है। इस तरह का एक सवाल एक दो घंटे में बड़े पैमाने पर जवाब देना मुश्किल है, मैं अगले दिन अपने जवाब की गुणवत्ता में सुधार करने की कोशिश करूंगा


इस उत्तर के लिए कोई अद्यतन? मैं जीआईएस तकनीक के एक कार्यालय के लिए एक जीयूआई आधारित संस्करण नियंत्रण सेटअप की तलाश कर रहा हूं जो प्रोग्रामर-प्रेमी नहीं हैं, और हमें जिस कार्यक्षमता की आवश्यकता है वह बहुत बुनियादी है; हम NAS पर एक मास्टर डेटासेट सक्षम होना चाहते हैं और उपयोगकर्ताओं को समय-समय पर इसके साथ सिंक करते हैं ताकि वे डेटा की स्थानीय प्रतियों पर काम कर सकें लेकिन हमेशा NAS पर मास्टर डेटा के साथ सिंक में रहें क्योंकि वरिष्ठ जीआईएस विश्लेषक समय-समय पर अपडेट करते रहते हैं। एनएएस डेटा। मैंने Git और Mercurial पर ध्यान दिया है, लेकिन वे सभी बहुत अधिक प्रतीत होते हैं और कमांड-लाइन एक अधिक वांछनीय सरल कार्यान्वयन के लिए केंद्रित है। कोई विचार?
user25644
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.