моє запитання стосується використання та продуктивності декількох програмних засобів спільно, а саме PostgreSQL, PostGIS, QGIS та GDAL.
Я давній користувач ArcGIS, Python та R, який зацікавлений у тому, щоб диверсифікуватись у вільну екосистему з відкритим кодом GIS та Linux. Нещодавно мені було дуже цікаво використовувати QGIS (ver 2.8) разом з PostgreSQL (ver 9.4) та PostGIS (ver 2.1), і я встановив програмне забезпечення на комп'ютер під керуванням Windows 8.1 x64 (комп'ютерні характеристики коротко: ThinkPad X200 з 2,1 ГГц Core 2, 8 Гб оперативної пам’яті та 240 ГБ SSD). Як тільки я дізнаюся, як керувати своїми просторовими даними (~ 100 ГБ), я хотів би запустити Ubuntu на цій машині.
На даний момент я просто намагаюся надійно зберігати та витягувати форми та растри. Досі я мав успіх у завантаженні форм-файлів у PostGIS, але растри виявляються більш проблематичними. Я успішно завершив одноразовий та пакетний імпорт невеликих файлів geoTIFF та GRID, але більші растри (скажімо, на диске розміром з розміром стільникового зображення IMG або TIFF розміром 15619x14655 на диску) вічно завантажуються в 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, а не самим QGIS. На форумі дискусії коротко згадують про цю проблему, а деякі навіть припускають, що растри не слід зберігати в PostGIS (який сенс у просторовій базі даних, яка не обробляє растри без проблем?). Тим не менш, я регулярно використовую файлову базу даних ESRI, щоб швидко та легко зберігати, візуалізувати та аналізувати досить великі (~ 70 Гб) растри, і ArcGIS 10.1 ніколи не зависає або сповільнюється через такі рутинні операції.
Щось тут мені не вистачає, вузьке місце, до якого я не звертався? Чи потрібна PostgreSQL налаштування, щоб усвідомити переваги продуктивності PostGIS? Чи пропускаю я версію GDAL, яку мені потрібно шукати та компілювати? Як особливо покращити продуктивність та візуалізацію PostGIS у QGIS форм-файлів та растрах? Як я можу насолодитися славою всебічного та швидкого управління просторовими даними через термінал Linux? Будь-яка допомога в цьому питанні буде ласкаво просимо!
Я дотримувався цього керівництва Дунканом Голіхером: 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Мені вдалося вчасно вдало імпортувати растр IMG 870 Мб і відобразити його в 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-сервер для просторових даних.
- Я створив просторові індекси для таблиць з геометрії та виконав VACUUM.
- Поведінка QGIS для відкриття великих таблиць атрибутів (~ 4,7 м записів), схоже, намагається прочитати всі записи, а не повертати підмножину для миттєвого перегляду. Це призводить до низької продуктивності.
Продуктивність при візуалізації великих таблиць геометрії PostGIS не здається проблемою.
За допомогою raster2pgsql растри були індексовані, викладені плиткою та імпортовані як растрові таблиці з пірамідами в PostGIS.
- Растри будь-якого розумного розміру все ще неймовірно повільні для імпорту в PostGIS, не кажучи вже про відкриття та панорамування в QGIS.
Варто також зазначити, що при імпорті великих растрових або відкриття великих таблиць атрибутів за допомогою PostGIS споживання пам'яті для raster2pgsql та qgis-bin перевищує 1 Гб. Як згадували @Michael і @Paul у відповідь на моє первинне запитання, схоже, PostGIS не принесе великої користі для зберігання растра. Однак у цей момент я сумніваюся, чому я взагалі запускаю QGIS + PostGIS для моїх потреб у ГІС, особливо коли файли ESRI fileGDB включають растрові атрибути, набори мозаїчних даних та інші растрові операції, полегшені базою даних геоданих. Тож, можливо, я щось дуже не вистачаю, або QGIS і PostGIS не відповідають моїм потребам в ГІС. В останнє мені важко повірити.
