Низкая производительность из-за хранения больших растров в PostGIS и визуализации в QGIS

Мой вопрос касается использования и производительности нескольких программных инструментов совместно, а именно PostgreSQL, PostGIS, QGIS и GDAL.

Я давний пользователь ArcGIS, Python и R, который заинтересован в диверсификации в бесплатную ГИС-экосистему с открытым исходным кодом и Linux. В последнее время я очень заинтересовался использованием QGIS (версия 2.8) вместе с PostgreSQL (версия 9.4) и PostGIS (версия 2.1), и я установил программное обеспечение на компьютер с Windows 8.1 x64 (кратко о технических характеристиках компьютера: ThinkPad X200 с 2,1 ГГц Core 2, 8 ГБ ОЗУ и SSD на 240 ГБ). Как только я научусь управлять своими пространственными данными (стоимостью ~ 100 ГБ), я хочу запустить Ubuntu на этом компьютере.

На данный момент я просто пытаюсь надежно хранить и извлекать шейп-файлы и растры. До сих пор я успешно загружал шейп-файлы в PostGIS, но растры оказываются более проблематичными. Я успешно выполнил одиночный и пакетный импорт небольших файлов geoTIFF и GRID, но большие растры (скажем, IMG-файл TIFF размером 15619x14655 с ячейками размером 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. Из документации и обсуждений на форуме этот недостаток, по-видимому, связан с драйвером растра PostGIS от 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. Я прав, если предположить, что эта дополнительная таблица является таблицей пирамид, которая имеет более узкую диапазон значений в результате агрегирования с более низким разрешением?

Я не думаю, что проблема в недостаточном оборудовании. Вот краткое изложение того, что я нашел до сих пор.

У драйвера растра GDAL PostGIS были проблемы с производительностью в прошлом ( см. Также здесь ). Хотя эти проблемы были отмечены в 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 для своих нужд ГИС, особенно когда файловые базы данных ESRI включают атрибуты растра, наборы данных мозаики и другие растровые операции, облегчаемые базой геоданных. Так что, возможно, я либо что- то упустил, либо QGIS и PostGIS не соответствуют моим потребностям в ГИС. В последнее мне трудно поверить.

Если вы хотите отображать большие растры в QGIS, вы должны построить пирамиды либо для tif-изображения в файловой системе, либо для изображения, зарегистрированного в Postgis.

Разница в производительности при рендеринге QGIS между большим растром в файловой системе или в Postgis незначительна. Пользователи не заметят разницу. Но - если и только если - вы строите пирамиды с опцией -l.

Если вы просто импортируете изображение без опции -l, или просто -l 4 не будет работать .

Если вы используете, например, -l 2,4,8,16четыре уровня пирамид будут созданы, как в слое ниже:

Если вы хотите улучшить взаимодействие с пользователем, вы должны добавить больше уровней пирамид, например -l 2,4,8,16,32,64,128,256. Это создаст восемь уровней пирамид.

Подводя итог, можно сказать, что ответ на этот вопрос: импортируйте растр с опцией -lи используйте такое же количество уровней пирамиды, которое вы используете для того же растра в файловой системе.

Например:

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, но кроме этого я не могу быть слишком полезным. Мне также, возможно, придется полагаться на файловую систему для обслуживания растров в моей организации.

Не уверен, что это был ваш случай, но я обнаружил, -Iчто не следует использовать вместе с добавлением данных -a.

Я импортировал много файлов TIF в БД и -Iфактически снова создал индекс и выполнил analyseдля каждого файла таблицу, что занимает в 10 раз больше времени.

-Iследует использовать только при создании таблицы с -pопцией.