gdalwarpप्रोजेक्ट और अलाइन-टू-ग्रिड ( -tapथ्रू) का उपयोग करने के बाद मैंने कई आपदाओं पर ध्यान दिया कि आउटपुट आपदाएं मूल आपदाओं की तुलना में काफी बड़ी थीं। एक पूरी तरह से वेब खोज ने इस Trac मुद्दे को बदल दिया :
फ्रैंक वार्मडम ने कारण बताया:
"सावधान समीक्षा पर, प्रश्न में फ़ाइल में अंतर इसलिए है क्योंकि gdal_translate GTiffDataset :: CreateCopy?) से आउटपुट फ़ाइल लिखने के लिए TIFFWriteScanline () इंटरफ़ेस का उपयोग करता है, और यह केवल अंतिम 'स्ट्रिप' के रूप में लिखता है? फ़ाइल को छवि क्षेत्र को पूरा करने के लिए आवश्यक है। लेकिन गालवडप ब्लॉकियो इंटरफेस के माध्यम से जाता है जो पूर्ण अंतिम पट्टी लिखता है, यहां तक कि वह हिस्सा जो फ़ाइल के अंत में गिरता है। "
हालांकि, यह Trac मुद्दा ~ 7 साल पुराना है, और मुझे पता है कि GDAL उपयोगिताओं में कुछ बदलाव किए गए हैं, जिनमें से gdalwarpअब तक किए गए हैं। मैं जानना चाहूंगा कि क्या उपरोक्त तर्क अभी भी है और यदि फ़ाइल आकार मुद्रास्फीति मैं देख रहा हूं तो "सामान्य" है। यहाँ "सामान्य" शब्द का अर्थ लिया जा सकता है कि वह बिना सोचे - समझे या अपेक्षित है , लेकिन इससे भी महत्वपूर्ण बात यह है कि क्या ऐसा कुछ है जो प्रभाव को कम करने के लिए किया जा सकता है यानी आउटपुट रैस्टर फ़ाइल का आकार कम कर सकता है? नीचे फ़ाइल आकार मुद्रास्फीति की एक तालिका मैं अनुभव कर रहा हूं।
Input File Size (bytes) Output File Size (bytes) Inflation
1437380431 1698334217 18%
1428001178 1698334433 19%
41683165 137036637 228%आर्क टीआईएस में इनपुट टीआईएफएफ फाइलें बनाई गईं और इस प्रकार बाहरी वर्ल्डफाइल्स, एक्सएमएल और डीबीएफ फाइलें हैं लेकिन ये फ़ाइल आकार में अंतर नहीं करती हैं। यहाँ एक नमूना gdalwarpकॉल है जैसा कि मैंने इन सभी मामलों में इसका उपयोग किया है; वास्तविक निष्पादन एक अजगर द्वारा नियंत्रित किया गया था subprocess( subprocess.Popen):
$ gdalwarp -tap -tr 30 30 -t_srs "+proj=aea +lat_1=20 +lat_2=60 +lat_0=40 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs" -co "COMPRESS=LZW" input_file.tif output_file.tifमैं समझता हूं कि दुर्लभ मामलों में संपीड़न एक बड़ी फ़ाइल बनाता है, लेकिन प्रभाव LZW संपीड़न के बिना समान है। तालिका में अनुपात LZW संपीड़न के साथ हैं।