मेरे सवाल में कई सॉफ्टवेयर टूल्स के उपयोग और प्रदर्शन की चिंता है, जैसे कि PostgreSQL, PostGIS, QGIS और DDAL।
मैं एक लंबे समय तक आर्कजीआईएस, पायथन और आर उपयोगकर्ता हूं जो मुक्त खुले स्रोत जीआईएस पारिस्थितिकी तंत्र और लिनक्स में भी विविधता लाने में रुचि रखते हैं। हाल ही में मैं PostgreSQL (ver 9.4) और PostGIS (ver 2.1) के साथ QGIS (2.8 2.8) का उपयोग करने में बहुत दिलचस्पी रहा हूं, और मैंने विंडोज 8.1 x64 (संक्षिप्त में कंप्यूटर चश्मा) के साथ कंप्यूटर पर सॉफ्टवेयर स्थापित किया है: थिंकपैड 2.1GHz कोर 2, 8GB रैम और एक 240GB SSD) के साथ X200s। एक बार जब मैं अपने स्थानिक डेटा (~ 100GB मूल्य) का प्रबंधन करना सीख लेता हूं, तो मैं इस मशीन पर Ubuntu चलाना चाहूंगा।
फिलहाल, मैं बस मज़बूती से स्टोर करने और शेपफाइल्स और आपदाओं को दूर करने की कोशिश कर रहा हूँ। अब तक मैं PostGIS में शेपफाइल्स लोड करने में सफल रहा हूं, लेकिन आपदाएं अधिक समस्याग्रस्त साबित हो रही हैं। मैंने छोटे जियोफाई और जीआरआईडी फाइलों के एकल और बैच आयातों को सफलतापूर्वक पूरा कर लिया है, लेकिन बड़ी आपदाओं (कहते हैं, एक 15619x14655 सेल आईएमजी या डिस्क पर आकार में 870 एमबी फ़ाइल) को हमेशा के लिए पोस्टजीआईएस में लोड करना है। मैंने इन मापदंडों का उपयोग करके टाइलों द्वारा स्थानिक सूचकांक बनाने और चूहों को लोड करने के लिए raster2pgsql टूल को पढ़ा और कॉन्फ़िगर किया है:
raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgresआयात करने में प्रदर्शन अभी भी बहुत खराब है, और हार्डवेयर समस्या नहीं है। क्यूजीआईएस में पोस्टगिस चूहों की कल्पना और भी बदतर है, धीरे-धीरे छोटे चूहों को सबसे अच्छे रूप से लोड करना या पूरी तरह से ठंड। मेरे द्वारा उल्लिखित एक बड़ी आपदाएं QGIS में कल्पना करना असंभव हैं। प्रलेखन और मंच चर्चा से, यह कमी GDAL के PostGIS रेखापुंज चालक के कारण प्रतीत होती है न कि स्वयं QGIS के कारण। फोरम चर्चा में इस समस्या का संक्षेप में उल्लेख किया गया है और कुछ ने यह भी सुझाव दिया है कि पोस्टगिस में चूहों को संग्रहीत नहीं किया जाना चाहिए (स्थानिक डेटाबेस में बिंदु क्या है जो आसानी से चूहों को संभाल नहीं करता है?)। फिर भी मैं नियमित रूप से ईएसआरआई की फाइल जियोडैटेबेस का उपयोग स्टोर करने, कल्पना करने और बहुत बड़ी (~ 70 जीबी) की आपदाओं का जल्दी और आसानी से विश्लेषण करने के लिए करता हूं, और आर्कजीआईएस 10.1 इस तरह के नियमित संचालन के कारण कभी भी जमा या धीमा नहीं होता है।
क्या कुछ ऐसा है जो मुझे याद आ रहा है, एक अड़चन है जिसे मैंने संबोधित नहीं किया है? क्या PostgreSQL को PostGIS के प्रदर्शन लाभों का एहसास करने के लिए ट्यूनिंग की आवश्यकता है? क्या मुझे GDAL का एक संस्करण याद आ रहा है जिसे मुझे शिकार करने और संकलन करने की आवश्यकता है? मैं विशेष रूप से आकृति विज्ञान और आपदाओं के क्यूजीएस में पोस्टजीस के प्रदर्शन और दृश्य में सुधार कैसे कर सकता हूं? मैं लिनक्स टर्मिनल के माध्यम से व्यापक और त्वरित स्थानिक डेटा प्रबंधन की महिमा का आनंद कैसे ले सकता हूं? इस मुद्दे पर किसी भी मदद का स्वागत किया जाएगा!
मैंने डंकन गोलिचर द्वारा इस गाइड का अनुसरण किया: https://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/
मैं मूल रूप से एक स्वचालित सेटिंग के साथ टाइल का उपयोग कर रहा था, लेकिन मैंने प्रति पंक्ति 100x100 कोशिकाओं को टाइलिंग को रीसेट कर दिया और फिर पिरामिड को शामिल किया जैसा कि गाइड में दिखाया गया है:
raster2pgsql -s 3161 -d -C -I -M -l 4 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgresमैं अच्छे समय में 870MB IMG रेखापुंज को सफलतापूर्वक आयात करने और अनुप्रयोग को धीमा या दुर्घटनाग्रस्त किए बिना QGIS में प्रदर्शित करने में सक्षम था। रेंडरिंग टाइम उतनी तड़क-भड़क वाला नहीं है जितना मैं उम्मीद करता हूं, लेकिन यह स्वीकार्य है। मैं ठीक से उपयोग करने के लिए -l पैरामीटर पर आगे पढ़ूंगा।
संयोग से, dem.img फ़ाइल को dem100 तालिका के रूप में आयात करने में, एक और रेखापुंज तालिका "o_4_dad100" नामक बनाई गई थी। जब मैं इसे QGIS में एक परत के रूप में आयात करता हूं, तो इसकी मूल्य सीमा 201 से 524 के बीच होती है, जबकि dem100 परत में 36 से 524 तक की सीमा होती है। क्या मैं यह मानने में सही हूं कि यह अतिरिक्त तालिका पिरामिड तालिका है जिसमें एक संकरा है कम रिज़ॉल्यूशन के लिए एकत्रित होने के परिणामस्वरूप मूल्य सीमा?
मुझे नहीं लगता कि अपर्याप्त हार्डवेयर समस्या है। यहाँ मैंने अभी तक जो कुछ भी पाया है उसका एक संक्षिप्त सारांश है।
GDAL के PostGIS रेखापुंज चालक के पास पिछले प्रदर्शन के मुद्दे हैं ( यहाँ भी देखें )। हालांकि इन समस्याओं को 2012 में नोट किया गया था, मुझे आश्चर्य है कि क्या GGAL 1.11.2 QGIS 2.8 में पाया गया है फिर भी यह समस्या है। निश्चित रूप से रास्टर विज़ुअलाइज़ेशन और स्टोरेज के लिए QGIS और PostGIS का उपयोग करने वाले अन्य हैं?
एक संभावित संबंधित नोट पर, मैंने QGIS में पोस्टजीस विशेषता टेबल खोलने के साथ ~ 4.7 मीटर रिकॉर्ड के साथ प्रदर्शन के मुद्दे भी रखे हैं । उस धागे में कुछ सुझावों के बाद और समस्या को ठीक किए बिना, मैंने अंततः क्यूजीआईएस के साथ एक बग रिपोर्ट दायर की जो अंततः बंद हो गई और निम्नलिखित समान बग रिपोर्ट से जुड़ी हुई थी । हालांकि बग रिपोर्ट बंद हो गई है, यह तय नहीं लगता ...
अब तक के मेरे प्रयासों को पूरा करने के लिए:
- मैंने स्थानिक डेटा के लिए PostgreSQL सर्वर को अनुकूलित किया है।
- मैंने ज्यामिति तालिकाओं के लिए स्थानिक सूचकांक बनाए हैं और एक VACUUM प्रदर्शन किया है।
- बड़ी विशेषता तालिकाओं को खोलने के लिए QGIS व्यवहार (~ 4.7 मीटर रिकॉर्ड) तात्कालिक देखने के लिए सबसेट वापस करने के बजाय सभी रिकॉर्डों को पढ़ने की कोशिश करता है। इससे खराब प्रदर्शन होता है।
बड़े PostGIS ज्यामिति तालिकाओं को प्रस्तुत करने में प्रदर्शन एक समस्या नहीं लगती है।
Raster2pgsql के साथ, रेखापुंज को अनुक्रमित किया गया, टाइल लगाया गया, और PostGIS में पिरामिड के साथ रेखापुंज तालिकाओं के रूप में आयात किया गया।
- किसी भी उचित आकार की आपदाएं अभी भी अविश्वसनीय रूप से धीमी गति से पोस्टगिस में आयात करने के लिए धीमी हैं, क्यूजीआईएस में चारों ओर खुला और पैन है।
यह भी ध्यान देने योग्य है कि जब बड़े चींटियों का आयात करते हैं या पोस्टजीआईएस के साथ बड़ी विशेषता तालिकाओं को खोलते हैं, तो raster2pgsql और qgis-bin के लिए मेमोरी की खपत 1GB से अधिक है। जैसा कि @Michael और @Paul ने मेरे शुरुआती सवाल के जवाब में उल्लेख किया है, ऐसा प्रतीत होता है कि पोस्टगिस का मतलब चूहों को संचय करने से कोई लाभ नहीं है। हालांकि, उस बिंदु पर मैं सवाल करता हूं कि मैं अपनी जीआईएस जरूरतों के लिए क्यूजीआईएस + पोस्टजीस को क्यों चलाऊंगा, खासकर जब ईएसआरआई फाइलगीडीएस रेखापुंज विशेषताओं, मोज़ेक डेटासेट, और अन्य रेखापुंज संचालन को सक्षम करता है, जो कि जियोडेटाबेस द्वारा सुगम होता है। इसलिए शायद या तो मुझे वाकई कुछ याद आ रहा है या QGIS और PostGIS मेरी GIS की जरूरतों को पूरा नहीं करते हैं। मुझे विश्वास करना मुश्किल है।
