भू-स्थानिक डेटा की बड़ी मात्रा का प्रबंधन? [बन्द है]


83

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

मैं यह भी सुनने के लिए उत्सुक हूं कि क्या कोई संशोधन नियंत्रण प्रणाली में अपने भू-स्थानिक डेटा का प्रबंधन करता है; मैं वर्तमान में अपने कोड और छोटे डेटासेट के लिए एक का उपयोग करता हूं, लेकिन पूर्ण डेटासेट के लिए नहीं।


1
यह जानने के लिए उपयोगी होगा कि आप किस तरह की फ़ाइलों का उपयोग करते हैं, किन अनुप्रयोगों के लिए फ़ाइलों तक पहुंच की आवश्यकता होती है, आदि, आदि
जेसनबेर

मैं आम तौर पर इस समस्या में दिलचस्पी लेता हूं, इसलिए कोई भी उत्तर बहुत अच्छा है।
scw

1
मुझे एहसास हुआ कि इस सवाल को शायद सामुदायिक विकि होना चाहिए ताकि हमें एक ठोस जवाब मिल सके; hindight एक सटीक विज्ञान है।
sc

जवाबों:


51

मुझे लगता है कि स्टॉक / स्पष्ट उत्तर एक मेटाडेटा सर्वर जैसे कि esri's GeoPortal या ओपन जिओ नेटवर्क के रूप में मेटाडेटा सर्वर के साथ संयोजन में एक स्थानिक डेटाबेस (PostGIS, Oracle, SDE, MSSQL स्थानिक, आदि) का उपयोग करना होगा और कुल मिलाकर मुझे लगता है कि यह आम तौर पर होता है सबसे अच्छा समाधान। हालाँकि, आपको हमेशा प्रोजेक्ट-आधारित स्नैपशॉट / शाखाओं / टैग की आवश्यकता होगी। अधिक उन्नत डेटाबेस में से कुछ के प्रबंधन के तरीके हैं, लेकिन वे आम तौर पर उपयोगकर्ता / प्रबंधन के लिए यह सब आसान नहीं है।

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

मैंने हालांकि कुछ दिलचस्प समाधान देखे हैं ...

जब बीसी पर्यावरण मंत्रालय आर्क / इन्फो कवरेज से दूर की चीजें चला रहा था, तो उनके पास वास्तव में शांत rsync- आधारित दो तरह से सिंक्रनाइज़ेशन प्रक्रिया थी। केंद्रीय नियंत्रण में रहे कवरेज को रात भर के क्षेत्रों में धकेल दिया गया, और क्षेत्रीय डेटा को वापस अंदर धकेल दिया गया। यह ब्लॉक-लेवल डिफरेंस ट्रांसफर वास्तव में अच्छी तरह से काम किया, यहां तक ​​कि 56k लिंक पर भी। ओरेकल-आधारित विशेषता डेटाबेस की प्रतिकृति के लिए समान प्रक्रियाएं थीं, लेकिन मुझे नहीं लगता कि वे आमतौर पर डायल-अप पर बहुत अच्छा करते थे :)

मेरे काम का वर्तमान स्थान एक समान संकर समाधान का उपयोग करता है। प्रत्येक डेटासेट की अपनी आधिकारिक प्रतिलिपि होती है (ओरेकल में कुछ, MapInfo में अन्य, व्यक्तिगत जियोडैट डेटाबेस में अन्य) और ये FME का उपयोग करते हुए रात में क्रॉस-ETL'd हैं। जब यह रखरखाव की बात आती है, तो यहां कुछ बहुत बड़ा ओवरहेड है; किसी भी नए डेटासेट को बनाने और संगठनात्मक दृश्यता सुनिश्चित करने का प्रयास काफी अधिक होना चाहिए। हम इस ओवरहेड से बचने के लिए समेकन के कुछ तरीके खोजने के उद्देश्य से एक समीक्षा की प्रक्रिया में हैं।


10
आप PostGIS उपयोग कर रहे हैं, तो इसके लायक उल्लेख इतिहास टेबल्स 1.5 में नई सुविधा
fmark

1
यदि डेटा सेट संबंधित हैं, तो Postgresql वंशानुक्रम को बनाए रखने में मदद करने, प्रदर्शन में सुधार, और पदानुक्रमित सारांश की अनुमति देने पर भी विचार करने योग्य है।
एड्रियन

जियोस्पेशियल डेटा की बड़ी मात्रा वितरित वर्जनिंग प्रणाली के उपयोग के कारण होती है, जो हर नोड पर डेटा को दोहराता है (ज्यादातर कोड के लिए संशोधन नियंत्रण प्रणाली के साथ उपयोग किया जाता है)। यह क्लाइंट-सर्वर (सेंट्रलाइज्ड) डेटा वर्जनिंग सिस्टम में नहीं होता है, उदाहरण के लिए पोस्टग्रेज-पोस्टगिस का उपयोग करना। youtube.com/watch?v=1FsonLiSDR8
अल्फ्रेडो गार्सिया

23

मेटाडेटा अब तक का सबसे महत्वपूर्ण मुद्दा है। यदि मेटाडेटा उत्तर देता है कि कब, क्यों, कहाँ, यह एक स्वीकार्य मेटाडेटा रिकॉर्ड है।

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

मेटाडाटा मुद्दों को संभालने के लिए जियोनेटवर्क एक अच्छी शुरुआत है। केंद्रीय भंडार को हल करना अधिक जटिल है, क्योंकि यह डेटाबेस को डिजाइन / बनाए रखने के लिए किसी विशेष व्यक्ति को ले सकता है।

जटिल मुद्दा यह है कि क्यूए / क्यूसी इन डेटासेट और उनके मेटाडेटा के प्रभारी कौन होंगे। यद्यपि कंप्यूटर संचालित प्रक्रियाएं बहुत अच्छी होती हैं, वे एक अच्छे डेटा प्रबंधक / डेटा कीपर के रूप में कठोर नहीं हो सकते हैं, जो इस कंपनी में काम किया था। अब मेटाडेटा की समीक्षा / प्रतिबद्ध करने और भू-स्थानिक डेटा को व्यवस्थित करने के लिए विशेष रूप से कोई है जो एक DBMS में केंद्रीकृत नहीं है।


11

हमने एक फाइल सिस्टम का उपयोग किया है जो कि श्रेणीबद्ध तरीके से आयोजित किया गया है: - भौगोलिक सीमा (देश या महाद्वीप) - डेटा प्रदाता, लाइसेंसकर्ता - डोमेन / डेटासेट - दिनांक / संस्करण

उसके बाद हमारे पास स्रोत डेटा को अलग करने की नीति है (उसी प्रारूप में जो किसी सीडी / डीवीडी पर थी जो हमें प्रदाता से मिली थी) किसी भी व्युत्पन्न डेटासेट से जो हमने अपनी कंपनी के भीतर उत्पादित किया था।

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

परियोजनाओं के भीतर प्रबंधन की सुविधा के लिए, हम प्रतीकात्मक लिंक का उपयोग करते हैं। हम अपने वैक्टर को एक डेटाबेस (ओरेकल) में रखते हैं और हम इसे प्रति ग्राहक कम से कम एक डेटाबेस उदाहरण (और परियोजनाओं के लिए कई उपयोगकर्ता / स्कीमा) रखने का नियम बनाते हैं। हम एक डेटाबेस में कई आपदाओं को नहीं रख रहे हैं, हालांकि, वे एक के बाहर भी बहुत अधिक स्थान लेते हैं। इसके अलावा, हम अपने डेटाबेस उदाहरणों को यथासंभव हल्के रखना पसंद करते हैं।

और हां, हमारे पास पूरी चीजों को 'पुलिसिंग' के प्रभारी के रूप में रखा गया है ताकि यह बहुत गड़बड़ न हो।

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

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


6

जैसा कि @JasonBirch ने कहा, संस्करण नियंत्रण एक बहुत बड़ा मुद्दा है।

इसके अलावा, हमने पाया है कि एक उचित वर्कफ़्लो बेहद महत्वपूर्ण है। उदाहरण के लिए जब हम फ़ील्ड डेटा एकत्र कर रहे होते हैं तो हम स्टेजिंग डेटाबेस का उपयोग करते हैं जहाँ मास्टर डेटा में विलय होने से पहले फ़ील्ड डेटा QA'd हो सकता है। इस बात पर निर्भर करता है कि QA'd के लिए कितने डेटा की आवश्यकता है लेकिन यह हमेशा कुछ ओवरहेड बनाएगा।

इसके अलावा, अगर आपने इसे नहीं देखा है, तो मैं लार्स ब्रोडर्सन द्वारा भू-संचार और सूचना डिज़ाइन ईबुक पर एक नज़र डालने की सलाह देता हूं, कम से कम कुछ के लिए वह डेटा मॉडलिंग पर क्या कहना है।


5

दूसरों के कहे अनुसार सभी तरह से पोस्टग्रैट्स करें, हालाँकि यदि आप इसे पोर्टेबल और स्थानांतरित करने के लिए आसान रखना चाहते हैं, तो आप हमेशा SQLite + स्पैटियालाइट एक्सटेंशन का उपयोग करके देख सकते हैं।

प्रबंधन उपकरणों के संदर्भ में Postgres के रूप में उपयोग करना आसान नहीं है, लेकिन QGis बिना किसी समस्या के सीधे जीआईएस डेटाबेस के लिए एक स्थानिक सक्षम से बात कर सकता है।

मैं वास्तव में बैकअप के लिए SQLite + Spatialite का उपयोग करता हूं, मेरे पास एक विंडोज़ सेवा है जो पृष्ठभूमि में चलती है (कस्टम लिखित) जो मेरे PGSql उदाहरण पर नज़र रखता है, और मेरे GIS डेटा को विभिन्न SQLite DB में बाहरी USB ड्राइव पर रहता है।

PG के साथ एक और टिप, स्कीमा का उपयोग करें

बहुत से लोग जानते हैं कि मैं "सार्वजनिक" में सब कुछ छोड़ देता हूं और इसके साथ किया जाता हूं, लेकिन अगर आप अपने डेटाबेस को सही ढंग से व्यवस्थित करते हैं तो यह अंतर की दुनिया बना देता है।

उदाहरण के लिए, मेरे "ऑर्डनेन्स_सर्वे" डेटाबेस में वेक्टोरामैपडिस्टिक्ट वेक्टर्मैपलोकल टॉपो 50 लुकअपग्रिड्स कोडपॉइंटविथपॉलिगोन्स कोडपॉइंटऑन के लिए स्कीमा है।

जहां मैं सभी संबद्ध डेटा रखता हूं।

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


4

जैसा कि पिछले पोस्ट में उल्लेख किया गया है, स्थानिक डीबी और मेटाडेटा सर्वर सामान्य सेटअप हैं। मुझे लगता है कि याद रखने वाली एक महत्वपूर्ण बात यह है कि 'एक आकार सभी के लिए उपयुक्त नहीं है'। आप Oracle, फ़ाइल सर्वर, SQL सर्वर, जो भी हो, में फिट होने वाले डेटा के साथ समाप्त होंगे। मैंने एक समाधान में सभी डेटा जरूरतों को जूता-छेद करने की कोशिश की है और यह आमतौर पर विफल रहता है।

विभिन्न समाधानों का उपयोग करने की अपेक्षा करें जो डेटा को फिट करते हैं और उनके लिए योजना बनाते हैं। यह वह जगह है जहाँ वास्तव में जियो-पोर्टल (मेटाडेटा सर्वर) आता है।


2

मुझे ऊपर 'जॉर्ज' से सहमत होना होगा कि मेटाडेटा को भू-स्थानिक डेटा के प्रबंधन में एक बड़ी भूमिका निभानी चाहिए। वास्तव में किसी भी डिजिटल डेटा के साथ, मेटाडेटा कुंजी है - एक फोटोग्राफर के बारे में सोचें जो अपनी डिजिटल फोटो फ़ाइलों को प्रबंधित करने की कोशिश करता है w / o उचित मेटाडेटा। यदि आप धार्मिक रूप से चीजों को टैग करते हैं, और आपके पास अच्छा सॉफ़्टवेयर है जो डेटा का उपयोग कर सकता है, तो जीवन बहुत आसान हो जाता है। अब 'जियोस्पेशियल डेटा का प्रबंधन' के बारे में मूल प्रश्न बहुत व्यापक है - यह डेटा फॉर्मेट को स्टोर करने, नामकरण परंपराओं, डेटासेट्स के पदानुक्रम और विशेषताओं, संपादन भूमिकाओं और विशेषाधिकारों, आदि आदि के लिए हो सकता है।


1

भू-स्थानिक डेटा के लिए संग्रहण पैटर्न इस बात पर निर्भर करता है कि आप इसे कैसे क्वेरी करना चाहते हैं / आप इसके साथ क्या करना चाहते हैं। कुछ उपकरण निम्नलिखित हैं जिन पर आप विचार कर सकते हैं:

Postgres + PostGIS: भू-स्थानिक सूचकांक और सभी प्रकार के प्रश्नों का समर्थन करता है जिनकी आप कल्पना कर सकते हैं। डेटा की अपनी टेराबाइट्स को प्रबंधित करने के लिए आपको शार्पिंग, क्वेरी ऑप्टिमाइज़ेशन आदि को लागू करना होगा। यदि आपका राइट लोड भारी है, तो मैं इसकी अनुशंसा नहीं करूँगा।

MongoDB: यह बड़ी मात्रा में डेटा का समर्थन करता है। सरल भंडारण, पुनर्प्राप्ति और सीमित भू-स्थानिक प्रश्नों के लिए बढ़िया।

फ़ाइल संग्रहण: यदि आप वास्तव में केवल एक अभिलेखीय प्रणाली हैं और क्वेरी करने के लिए डेटा के कुछ हिस्से का उपयोग करते हैं तो आपके डेटा को फ़ाइलों के रूप में संग्रहीत करना किफायती हो सकता है। आपके संस्करण नियंत्रण की आवश्यकता इससे अच्छी तरह संतुष्ट हो सकती है।

रेडिस: आप रेडिस में 'हॉट' डेटा की छोटी मात्रा को संग्रहीत करने के लिए उपरोक्त किसी भी विकल्प को रेडिस जियो समर्थन के साथ जोड़ सकते हैं जिसे आपको अक्सर एक्सेस करने की आवश्यकता होती है। इसे आप अपना कैश समझिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.