विभिन्न रेखापुंज डेटा प्रारूपों की गति

25

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

विशेष रूप से, अगर मैं एक रेखापुंज (जैसे, एक GEOTIFF फ़ाइल) को एक अलग प्रारूप (जैसे, एक netCDF) में परिवर्तित करने में दिलचस्पी रखता हूं, तो कभी भी पढ़ने / लिखने और अन्य कार्यों को गति देने के उद्देश्य से सार्थक होता है।

— जॉर्ज
स्रोत

2

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

— whuber

9

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

लेख सारांश: ऐसा लगता है कि पैकट्स आपको डिस्क एक्सेस की सबसे अच्छी एक्सेस टाइम (डिस्क स्पेस की कीमत पर) देता है, जबकि डिफ्लेट आपको इंटरमीडिएट / छोटी फाइलों के लिए इंटरमीडिएट / स्लो एक्सेस टाइम देता है। इसके अलावा, आप विभिन्न आकारों और समयों के थंबनेल बनाकर अधिक अनुभवजन्य रूप से परीक्षण कर सकते हैं कि इसमें कितना समय लगता है। उदाहरण आदेश:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

यह मानते हुए कि इस मामले में R से संबंधित एकमात्र चीज यह है कि यह फ़ाइल से डेटा को कितनी जल्दी पढ़ सकता है, ठीक उसी तरह जैसे कोई अन्य प्रक्रिया होगी, तो यह आपको एक अच्छा संकेत दे सकता है।

— आर थिदे
स्रोत

लिंक किए गए लेख के लिए +1, लेकिन महत्वपूर्ण जानकारी ऑफ़साइट है और हमारे पास खो जाएगी यदि वह पृष्ठ कभी नीचे जाता है या चलता है। मेरा सुझाव है कि लेख का एक सारांश निष्कर्ष दिया जाए ताकि इस घटना में पृष्ठ उपलब्ध न हो, यहां तक कि क्षण भर के लिए भी, पाठकों के पास भविष्य के अनुसंधान और सोच के साथ काम करने के लिए कुछ है। धन्यवाद!

— मैट विल्की

काफी उचित! ऐसा लगता है कि पैकट्स आपको डिस्क एक्सेस की सबसे अच्छी एक्सेस टाइम (डिस्क स्पेस की कीमत पर) देता है, जबकि डिफ्लेट आपको इंटरमीडिएट / छोटी फाइलों के लिए इंटरमीडिएट / स्लो एक्सेस टाइम देता है। इसके अलावा, आप विभिन्न आकारों और समयों के थंबनेल बनाकर अधिक अनुभवजन्य रूप से परीक्षण कर सकते हैं कि इसमें कितना समय लगता है। उदाहरण कमान: "समय gdal_translate -outsize <थंबनेल आयाम> -of GTiff <संपीड़ित छवि फ़ाइल> <थंबनेल फ़ाइल>"

— R Thiede

1

धन्यवाद! मैंने सारांश को उत्तर में ही मोड़ दिया, इसलिए यह अधिक आत्म निहित है (प्रत्येक उत्तर / प्रश्न के नीचे बाईं ओर संपादित करें लिंक देखें)।

— मैट विल्की सेप

@RThiede को एक वैध चिंता थी: यह अब वास्तव में लगता है कि ब्लॉग का लिंक अधिक वैध नहीं है?

— मतिफॉ

@RThiede आपका लिंक मृत है क्या आप एक नया प्रदान कर सकते हैं?

— माजिद होजती

6

के लिए पढ़ने / लिखने के संचालन, आप system.time का उपयोग करने वालों के संचालन की गति परीक्षण कर सकते हैं ()। आर (रैस्टर पैकेज) में डीईएम फ़ाइल लोड करने के कुछ परिणाम यहां दिए गए हैं, जिनका अनुवाद चार प्रारूपों (एएससीआईआई, आईएमजी और टीआईएफ में किया गया है, जिसमें कोई संपीड़न और अपस्फीति नहीं है)। उदाहरण के लिए, ~ 26MB रेखापुंज पर:

> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
 user  system elapsed 
 0.154   0.002   0.157

'बीता हुआ' ऑपरेशन के लिए लिया गया कुल समय (सेकंड) देता है। प्रत्येक ऑपरेशन को 10 बार चलाना और औसत बीते हुए समय को देखना:

              mean   diff
ASC         0.2237 0.3317
IMG         0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none    0.1495 0.0000
tif-pack    0.1513 0.0118

बिना किसी संपीड़न के TIFF सबसे तेज़ है ... इसके बाद Deflate (0.1% धीमा) और TIFF-Packbits (1.8% धीमा), फिर IMG (3.2% धीमा) और ASC (33% धीमी) द्वारा बहुत निकटता से। (यह एक एसएसडी के साथ मैकबुक प्रो 2.4 गीगाहर्ट्ज पर है, इसलिए तेज डिस्क संचालन)

यह केवल फाइलों को लोड करने के लिए है, उन्हें हेरफेर करने के लिए नहीं।

— Simbamangu
स्रोत

4

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

किसी भी तरह से, यदि आप R में raster के साथ काम करने जा रहे हैं, तो संभवतः R raster पैकेज में जो भी शामिल है, उसे पूरक करने के लिए आप rgdal और R ncdf संकुल का उपयोग करेंगे । गदलवार कमान पर प्रमुख निर्भरता के साथ । अपने रेखापुंज विकल्प बनाने के लिए प्रारूप निर्भरता पर काम करने की आवश्यकता है। आपको SO और विभिन्न OSGEO और R फ़ोरम / ब्लॉग / विकी पर उचित मात्रा में कवरेज मिलेगा।

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

— वी स्टुअर्ट फूटे
स्रोत

आर में netCDF डेटा (रेखापुंज स्रोत या अन्यथा) के हेरफेर के लिए, यहाँ दो R CRAN होस्ट किए गए netCDF संकुल, ncdf4 - cran.r-project.org/web/packages/ncdf4/index.html और RNetCDF - क्रैंक के लिंक दिए गए हैं। r-project.org/web/packages/RNetCDF/index.html

— V Stuart Foote

4

एक बड़ा सवाल यह है कि क्या आप फाइल को प्रोसेस करने से पहले मेमोरी से पूरी रेस्टर को पढ़ने जा रहे हैं, या क्या फाइल इतनी बड़ी है कि आप इसे इंक्रीमेंटल प्रोसेस करेंगे, या ओवरऑल फाइल के कुछ सब्मिट को प्रोसेस करेंगे।

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

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

क्षमा करें, लेकिन आपको संभवतः एक-आकार-फ़िट-सभी प्राप्त करने के बजाय अपने एक्सेस पैटर्न के आधार पर बेंचमार्क करना होगा। यह न केवल फ़ाइल प्रारूप और उपरोक्त कारकों पर निर्भर करता है, बल्कि उस प्रारूप और आपके सॉफ़्टवेयर के लिए ड्राइवरों पर भी निर्भर करता है।

— Zeph
स्रोत

2

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

GeoTIFF 2 डी "छवियों" या सरणियों का एक संग्रह है। NetCDF बहुआयामी सरणियों के लिए एक सामान्य उद्देश्य भंडारण है। लेकिन अगर आप सरणियों को उसी तरह से netCDF में संग्रहित करते हैं, जैसा कि वे जियो टीआईएफएफ में करते हैं, तो आपको कमोबेश वही प्रदर्शन मिलेगा।

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

अंत में, Id का कहना है कि यह वास्तव में केवल तभी मायने रखता है जब आपके पास बहुत बड़ी फाइलें हों, कम से कम दसियों मेगाबाइट्स हों।

— जॉन कैरन
स्रोत

इस बिंदु के लिए +1 कि रैंडम एक्सेस, या मनमाना स्थान पढ़ा, पूरी फ़ाइल पढ़ने तक एक के बाद एक अनुक्रमिक से बहुत अलग है। मैं आधार से दूर हो सकता हूं, लेकिन मुझे लगता है कि जियोटीफ़ भी टाइल-स्टोरेज और मनमानी एक्सेस का समर्थन करता है, यह सिर्फ इतना है कि स्ट्रिप / रो द्वारा सबसे आम और व्यापक रूप से समर्थित है। इसके अलावा इन दिनों जीआईएस में "बहुत बड़ी फाइलें" मल्टी जीबी रेंज में हैं। ;-)

— मैट विल्की

2

मैंने कई वर्षों पहले इसके बारे में कुछ पृष्ठों को पढ़ा है और जब से पैकेट संपीड़न के साथ टिफ का उपयोग किया है, एक जियोटीफ़ हेडर के साथ टाइल किया है, और खुश हैं।

आर्कपैड टीम लेख

विकि

लेकिन निम्नलिखित पढ़ने के बाद, मैं पुनर्विचार करूंगा और शायद डिफ्लेट किस्म का उपयोग करूंगा।

आर्कपैड साइट

— ब्रैड नेसोम
स्रोत

2

इतने सारे पैकेज हुड के तहत GDAL का उपयोग करते हैं, उदाहरण के लिए, rgdal, QGIS, GRASS, आदि। अगर मैं उन पैकेजों में से एक का उपयोग कर रहा था, तो मैं अपनी छवियों को vrt में बदलने के बारे में सोचूंगा। मैंने अक्सर यह सिफारिश की है कि जब आपको दो GDAL कमांड का उपयोग करने की आवश्यकता होती है, तो मध्यवर्ती फ़ाइल एक vrt फ़ाइल होनी चाहिए क्योंकि रीड ओवरहेड न्यूनतम है (उदाहरण के लिए, http://www.perrygeo.com/lazy-raster-processing -साथ-गदल- vrts.html )। ऐसा लगता है कि आपका वर्कफ़्लो है: एक बार कन्वर्ट और कई बार पढ़ें। शायद vrt उचित होगा।

[संपादित करें: लिंक समायोजित]

— user55937
स्रोत