أكثر

أداء ضعيف مع تخزين البيانات النقطية الكبيرة في PostGIS والتصور في QGIS


سؤالي يتعلق باستخدام وأداء عدة أدوات برمجية بالتزامن ، وهي PostgreSQL و PostGIS و QGIS و GDAL.

أنا مستخدم ArcGIS و Python و R منذ فترة طويلة وأهتم بالتنويع في نظام GIS الإيكولوجي المجاني مفتوح المصدر ونظام Linux أيضًا. لقد كنت مؤخرًا مهتمًا جدًا باستخدام QGIS (الإصدار 2.8) مع PostgreSQL (الإصدار 9.4) و PostGIS (الإصدار 2.1) ، وقمت بتثبيت البرنامج على جهاز كمبيوتر يعمل بنظام Windows 8.1 x64 (مواصفات الكمبيوتر باختصار: ThinkPad X200s مع 2.1 جيجاهرتز Core 2 و 8 جيجابايت من ذاكرة الوصول العشوائي و 240 جيجابايت SSD). بمجرد أن أتعلم كيفية إدارة بياناتي المكانية (تساوي 100 جيجابايت تقريبًا) ، أود تشغيل Ubuntu على هذا الجهاز.

في الوقت الحالي ، أحاول ببساطة تخزين واسترداد ملفات الأشكال والنقطية. لقد نجحت حتى الآن في تحميل ملفات الأشكال في PostGIS ، لكن البيانات النقطية تثبت أنها أكثر إشكالية. لقد أكملت بنجاح عمليات الاستيراد الفردية والدُفعية لملفات geoTIFF و GRID الصغيرة ، لكن البيانات النقطية الأكبر (على سبيل المثال ، ملف IMG بحجم 15619 × 14655 خلية أو ملف TIFF بحجم 870 ميجابايت على القرص) يستغرق وقتًا طويلاً للتحميل في PostGIS. لقد قمت بقراءة وتكوين أداة raster2pgsql لإنشاء مؤشرات مكانية وتحميل البيانات النقطية بواسطة المربعات باستخدام هذه المعلمات:

raster2pgsql -s 3161 -C -I D:  PostGIS_data  dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgres

لا يزال الأداء في الاستيراد ضعيفًا للغاية ، ولا يمثل الجهاز مشكلة. يعد تصور بيانات PostGIS النقطية في QGIS أسوأ من ذلك ، حيث يتم تحميل البيانات النقطية الصغيرة ببطء في أحسن الأحوال أو التجميد تمامًا. من المستحيل تصور النقطيات الكبيرة مثل التي ذكرتها في QGIS. من خلال مناقشات التوثيق والمنتدى ، يبدو أن هذا القصور يرجع إلى برنامج تشغيل البيانات النقطية لـ GDAL's PostGIS وليس QGIS نفسه. تذكر مناقشات المنتدى هذه المشكلة بإيجاز ويقترح البعض أنه لا ينبغي تخزين البيانات النقطية في PostGIS (ما هي النقطة في قاعدة البيانات المكانية التي لا تتعامل مع البيانات النقطية بسلاسة؟). ومع ذلك ، فأنا أستخدم قاعدة البيانات الجغرافية لملف ESRI بشكل روتيني لتخزين وتصور وتحليل البيانات النقطية الكبيرة جدًا (حوالي 70 جيجابايت) بسرعة وسهولة ، ولا يتجمد ArcGIS 10.1 أو يتباطأ أبدًا بسبب مثل هذه العمليات الروتينية. حواجز الأداء هذه مخيبة للآمال وتتركني غير متأثر بـ FOSS GIS.

هل هناك شيء أفتقده هنا ، عنق الزجاجة الذي لم أقم بمعالجته؟ هل تحتاج PostgreSQL ضبطًا لتحقيق فوائد أداء PostGIS؟ هل أفتقد نسخة من GDAL أحتاج إلى البحث عنها وجمعها؟ كيف يمكنني تحسين أداء PostGIS والتصور في QGIS لملفات الأشكال والنقطية على وجه الخصوص؟ كيف يمكنني الاستمتاع بمجد إدارة البيانات المكانية الشاملة والسريعة عبر محطة لينكس؟ أي مساعدة في هذه القضية سيكون موضع ترحيب!


لقد اتبعت هذا الدليل بواسطة Duncan Golicher: https://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/

كنت أستخدم البلاط بإعداد تلقائي في الأصل ، لكنني قمت بإعادة ضبط التبليط إلى 100 × 100 خلية في كل صف ، ثم قمت بتضمين الأهرامات كما هو موضح في الدليل على النحو التالي:

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

تمكنت بنجاح من استيراد 870 ميجابايت IMG النقطية في وقت مناسب وعرضها في QGIS دون إبطاء أو تعطل التطبيق. وقت العرض ليس سريعًا كما كنت أتوقع ، لكنه مقبول. سأقرأ المزيد عن المعلمة -l لاستخدامها بشكل صحيح.

بالمناسبة ، عند استيراد ملف dem.img كجدول dem100 ، تم إنشاء جدول نقطي آخر يسمى "o_4_dem100". عندما أقوم باستيراده كطبقة في QGIS ، يكون له نطاق قيم يتراوح بين 201 إلى 524 ، بينما تتراوح الطبقة dem100 من 36 إلى 524. هل أنا محق في افتراض أن هذا الجدول الإضافي هو الجدول الهرمي الذي يحتوي على أضيق نطاق القيمة نتيجة لتجميعها بدقة أقل؟


لا أعتقد أن الأجهزة غير الكافية هي المشكلة. فيما يلي ملخص موجز لما وجدته حتى الآن.

واجه برنامج التشغيل النقطي PostGIS الخاص بـ GDAL مشكلات سابقة في الأداء (انظر هنا أيضًا). على الرغم من ملاحظة هذه المشكلات في عام 2012 ، إلا أنني أتساءل عما إذا كان GDAL 1.11.2 الموجود في QGIS 2.8 لا يزال يعاني من هذه المشكلة. هل هناك بالتأكيد آخرون يستخدمون QGIS و PostGIS للتصور النقطي والتخزين؟

في ملاحظة محتملة ذات صلة ، واجهت أيضًا مشكلات في الأداء مع فتح جداول سمات PostGIS في QGIS بجداول تضم حوالي 4.7 مليون سجل. بعد بعض الاقتراحات في هذا الموضوع وبدون إصلاح المشكلة ، قمت في النهاية بتقديم تقرير خطأ مع QGIS والذي تم إغلاقه في النهاية وربطه بتقرير الخطأ المماثل التالي. على الرغم من إغلاق تقرير الخطأ ، لا يبدو أنه تم إصلاحه ...

لتلخيص جهودي حتى الآن:

  • لقد قمت بتحسين خادم PostgreSQL للبيانات المكانية.
  • لقد قمت ببناء مؤشرات مكانية للجداول الهندسية وقمت بعمل فراغ.
  • يبدو أن سلوك QGIS لفتح جداول السمات الكبيرة (حوالي 4.7 مليون سجل) يحاول القراءة الكل بدلاً من إرجاع مجموعة فرعية للعرض الفوري. هذا يؤدي إلى ضعف الأداء.
  • يعمل الأداء في عرض جداول هندسة PostGIS الكبيرة ليس يبدو أنه يمثل مشكلة.

  • باستخدام raster2pgsql ، تمت فهرسة البيانات النقطية وتجانبها واستيرادها كجداول نقطية بأهرامات في PostGIS.

  • لا تزال البيانات النقطية من أي حجم معقول بطيئة للغاية في الاستيراد إلى PostGIS ، ناهيك عن فتحها وتحريكها في QGIS.

تجدر الإشارة أيضًا إلى أنه عند استيراد البيانات النقطية الكبيرة أو فتح جداول البيانات الكبيرة باستخدام PostGIS ، فإن استهلاك الذاكرة لـ raster2pgsql و qgis-bin يزيد عن 1 جيجابايت. كما ذكرMichael وPaul ردًا على سؤالي الأولي ، يبدو أن PostGIS لا يُقصد به جلب الكثير من الفوائد ، إن وجدت ، لتخزين البيانات النقطية. ومع ذلك ، في هذه المرحلة ، أتساءل عن سبب تشغيل QGIS + PostGIS على الإطلاق لاحتياجات GIS الخاصة بي ، خاصةً عندما تمكّن ESRI fileGDBs السمات النقطية ومجموعات البيانات الفسيفسائية وعمليات البيانات النقطية الأخرى التي تسهلها قاعدة البيانات الجغرافية. لذلك ربما أنا كذلك حقا فقدان شيء ما أو أن QGIS و PostGIS لا يفيان باحتياجات نظم المعلومات الجغرافية الخاصة بي. أجد الأخير صعب تصديقه.


إذا كنت ترغب في عرض نقطية كبيرة في QGIS ، فيجب عليك إنشاء أهرامات ، إما لصورة tif على نظام الملفات أو لصورة مسجلة في Postgis.

يعد اختلاف الأداء في عرض QGIS بين البيانات النقطية الكبيرة في نظام الملفات أو في Postgis أمرًا ضعيفًا. لن يلاحظ المستخدمون الفرق. لكن - فقط إذا - تبني الأهرامات بالخيار.

إذا قمت ببساطة باستيراد الصورة بدون الخيار -l ، أو باستخدام فقط-ل 4لن يعمل.

إذا كنت تستخدم ، على سبيل المثال ،-l 2،4،8،16، سيتم إنشاء أربعة مستويات من الأهرامات ، كما في الطبقة أدناه:

إذا كنت ترغب في الحصول على تجربة مستخدم أفضل ، فيجب عليك إضافة المزيد من مستويات الأهرامات ، مثل- ل 2،4،8،16،32،64،128،256. سيؤدي ذلك إلى إنشاء ثمانية مستويات من الأهرامات.

للتلخيص ، الإجابة على هذا السؤال هي: استيراد البيانات النقطية مع الخيارواستخدم نفس عدد مستويات الهرم التي تستخدمها لنفس البيانات النقطية على نظام الملفات.

على سبيل المثال:

raster2pgsql -s 3161 -d -C -I -M -l 2،4،8،16،32،64،128،256 D:  PostGIS_data  dem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres

أواجه نفس المشكلات بالضبط مع عرض البيانات النقطية في QGIS من PostGIS (راجع سؤالي الأخير) لقد وجدت هذه المشاركة مفيدة وزيادة عرض البيانات النقطية المحسّن التالي قليلاً:

Shared_buffers = 5000 ميجابايت work_mem = 100 ميجابايت Maintenance_work_mem = 100 ميجابايت

ومع ذلك ، مع ذلك ، أوافق تمامًا على أن أداء البيانات النقطية PostGIS في QGIS ليس رائعًا. أتعامل مع 608 جيو تيفات مضغوطة يتم تحميلها بشكل كبير مثل VRT ولكنها غير قابلة للاستخدام بشكل أساسي في PostGIS. حاول زيادة أداء خادم dbase ، لكن بعد ذلك لا يمكنني أن أكون مفيدًا للغاية. أنا أيضًا قد أضطر إلى الاعتماد على نظام الملفات لخدمة البيانات النقطية داخل مؤسستي.


لست متأكدًا مما إذا كانت هذه هي حالتك ، لكنني اكتشفت-أنايجب عدم استخدامها مع إلحاق البيانات.

كنت أقوم باستيراد العديد من ملفات TIF إلى DB و-أنافي الواقع ينشئ الفهرس مرة أخرى وينفذتحليلعلى الجدول لكل ملف ، الأمر الذي يستغرق 10 أضعاف الوقت.

-أنايجب استخدامها فقط عند إنشاء الجدول بامتداد-pاختيار.


شاهد الفيديو: PostgreSQL Tutorial: How to import Shapefile into PostGIS EN (شهر اكتوبر 2021).