डेटाबेस में आकृति डेटा को केंद्रीकृत करना


13

मुझे विभिन्न विभिन्न जीआईएस परियोजनाओं से सैकड़ों शेपफाइल्स मिले हैं, जिन्हें मैं एक एकल डेटाबेस प्लेटफॉर्म में समेकित करना शुरू करना चाहता हूं, वर्तमान में पोस्टग्रेज / पोस्टजीआईएस के साथ यह प्रयास कर रहा है।

शायद ही कोई डेटा मानकीकृत है - जिसका अर्थ है कि यह समान डेटा प्रकारों का एक बहुत है , लेकिन विशेष विशेषता नाम / प्रकार मेल नहीं खाते हैं।

मुझे इससे कैसे निपटना चाहिए? क्या मुझे प्रत्येक आकार-प्रकार को पहले स्थानांतरित करने के लिए एक मानक मॉडल विकसित करना चाहिए (जैसे Hydro_line, transport_line, Hydro_poly standard, etc)?

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

इस चुनौतीपूर्ण काम से निपटने के लिए कोई सलाह?

जवाबों:


7

स्पैटियल ईटीएल सॉफ्टवेयर्स पर एक नज़र डालें (एक्सट्रैक्ट - ट्रांसफॉर्म - लोड), वे ऐसे कार्यों के लिए समर्पित हैं। सबसे अधिक ज्ञात सुरक्षित से FME है, लेकिन कुछ खुले स्रोत (आंशिक) विकल्प अब उपलब्ध हैं, जैसे कि Sdi (स्थानिक डेटा इंटीग्रेटर) और GeoKettle


2
मैंने पिछले प्रश्न में तुलना करने के लिए कहा है, इसलिए यदि आप इस मार्ग पर जाते हैं, तो कृपया एक राइट-अप करें। gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton

मैंने FME का एक परीक्षण संस्करण पकड़ा, और दोनों sdi और GeoKettle को स्थापित किया। मैं उन्हें आज़माता हूँ और देखता हूँ कि क्या मैं उनमें से कुछ समझ सकता हूँ। FME एक सूप-टू-नट्स समाधान की तरह दिखता है, लेकिन मुझे पहले सीखने की अवस्था में उतरना होगा :)।
कोलमैन

1
@ कोलमैन- आपने इस पर क्या किया? आपको कौन सा उत्पाद सबसे उपयोगी लगा?
रयानKalton

6

अभिनंदन

मैं इसे पहले PostGIS में आयात करूंगा। अलग-अलग तालिकाओं में कई आकृतियों को लोड करने के लिए उपकरण है। QGIS थूक विस्तार एक है। PostGIS ट्रंक या प्रयोगात्मक बायनेरिज़ में नया ग्राफिकल shp2pgsql एक और विकल्प है। या आप बस shp2pgsql के साथ एक बैच स्क्रिप्ट लिख सकते हैं।

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

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

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

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

मैं textfiles के साथ अंत करने के लिए उपयोग की तरह कुछ देख:

-- A query to merge all roads in Norway

Create table road_tables.all_roads as
SELECT id as roadid, status, the_geom from original.big_roads
union all
SELECT rid as roadid, condition as status, the_geom from original.small_roads;

और इसी तरह। पाठ फ़ाइल के रूप में सहेजा गया यह कुछ वर्षों के बाद एक महान मूल्य है।

सादर निकलैस


1
+1 मुझे लगता है कि यह एक बहुत अच्छा तरीका है। सब कुछ Postgres के भीतर किया जाता है, बहुत पारदर्शी और आसानी से पुन: पेश करने में सक्षम होने पर।
UnderDark

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

2
@ ब्रैड हम्म, मुझे आश्चर्य है कि अगर वह एक तर्क है जो पारदर्शी पारदर्शी और तेज़ तरीके से काम कर रहा है या मेरे और मेरे डेटा के बीच में एसडी लगाकर लॉक होने के खिलाफ एक तर्क है ... ;-)
निकलैस एवन

1
@ ब्रैड: कोलमैन ने ESRI का उल्लेख नहीं किया है, इसलिए उत्तर अच्छा प्रतीत होता है।
UnderDark

मैंने ESRI Sde फीचरक्लासेस और SQL सर्वर 2008 (w / देशी ज्यामिति) के साथ इसी तरह का काम किया है - मैंने पहले फीचरक्लास बनाया, फिर सम्मिलित कथनों की एक श्रृंखला के साथ लोड किया। IIRC, मुझे एक नए फीचरक्लास के अंत में फीचरक्लास का निर्यात करना था क्योंकि मैं नए ऑब्जेक्ट को सही तरीके से उत्पन्न नहीं कर सका। एक बार मैंने ऐसा किया था, हमेशा की तरह व्यापार।
जय कमिंस

4

मेरा सुझाव होगा कि आप अपने उपयोग किए गए डेटा लेयर (शेपफाइल्स) में से 2-5 को चुनें और उन्हें एक rdbms में माइग्रेट करें।
उन डेटा के लिए वर्कफ़्लो की जांच और कार्यान्वयन करें। फ़ाइल आधारित डेटा बनाम rdbms की परिसीमन और आवश्यकताओं के लिए उपयोग किया जा रहा है।

सीमाओं में शामिल हैं: आवश्यक निर्यात, लैंडिंग ज़ोन, कोऑर्डिसेस, सहयोग के लिए फ़ाइल प्रकार।

आप जो प्रस्ताव दे रहे हैं, उसके कई लाभ हैं।
साइड नोट: (मेरे दादाजी ने मेरे माता-पिता से कहा कि खरीदने से पहले एक घर की तलाश में 6 महीने का समय व्यतीत करें) आप अपने डेटा के लिए एक घर (दीर्घकालिक) की तलाश कर रहे हैं, तो आप अभी से कुछ 30 yrs के लिए भुगतान नहीं करना चाहते हैं कि आप पसंद नहीं है।

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

चापलूसी डेटा को एकीकृत करने के लिए आर्कगिस के भीतर विधियां हैं (मेरा assupmtion: आपने अपना पसंदीदा सिस्टम निर्दिष्ट नहीं किया है)।

यदि आप अच्छी डिजाइन प्रथाओं को सीखने में रुचि रखते हैं तो आप इनमें से कुछ जानकारी की कोशिश कर सकते हैं ...

जियोडेटाबेस डिजाइन ओवरव्यू
जियोडैटेबस डॉक्यूमेंटेशन
आर्क 10 के लिए भी कुछ इसी तरह के दायित्व हैं।
रिसोर्स सेंटर
आर्क 10 जियोडेटाबेस

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