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

23

Мой вопрос касается использования и производительности нескольких программных инструментов совместно, а именно 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 не соответствуют моим потребностям в ГИС. В последнее мне трудно поверить.

mbcaradima
источник
Есть ли растры должны быть в PostGIS? Какие преимущества / дополнительные функции вы надеетесь получить от этого? Я обнаружил, что вектор PostGis был приемлемым и предлагал многопользовательское редактирование, но растр PostGis не имел реальных преимуществ по сравнению с растром на основе файлов (на сервере). Хороший вопрос, хотя; вполне возможно, что есть некоторые преимущества, которые я упустил в своей оценке ...
Майкл Стимсон
Я подумал, что растры PostGIS обеспечивают более быстрые растровые вычисления, а также лучшую производительность с растровыми / векторными операциями. Это в дополнение к преимуществам пространственной БД: надежность, доступность, средства резервного копирования, более компактное хранилище и т. Д. В любом случае, подход файла / мозаики не учитывает функции поиска, предварительно построенные пирамиды, мозаику и другие возможности, которые улучшают использование и визуализацию растра.
mbcaradima
Я не видел метрики, которая говорит о том, что растры PostGIS работают быстрее при растровых вычислениях ... в любом случае с твердотельным накопителем на 240 ГБ (хороший выбор, кстати, быстрее, чем RAID за небольшую долю затрат / усилий), вы очень быстро заполните растры ... ECW / JP2 для 8-битной или GeoTIFF с LZW / Deflate тиковым большинством этих блоков, предварительно построенными пирамидами, мозаикой (через VRT), резервным копированием в виде файлов и т. Д. ... единственным преимуществом является функция поиска. Я понимаю, что немного отклоняюсь от темы, но если PostGIS-растр не выполняет то, что вы ожидаете, то почему бы не использовать растровый файл для отображения?
Майкл Стимсон,
3
Кто нибудь говорил, что растры PostGIS быстрее всех? Они могут быть более удобными (удобный API доступа к SQL) и могут быть полезны для анализа (растр и вектор в одном сегменте), но быстрее ? Никогда.
Пол Рэмси
1
Я работаю над книгой о PostGIS (PostGIS in Action, 2-е изд), и было вполне естественно предположить, что преимущества хранения шейп-файлов в пространственной БД распространятся и на растр. Конечно, учитывая их различные модели данных, я вижу, что это предположение было чисто интуитивным. Тем не менее, растры обычно хранятся в базах геоданных с помощью ArcGIS и позволяют строить пирамиды, ускорять геообработку и строить мозаики. Как рабочий ГИС должен работать с растрами в рабочем процессе с открытым исходным кодом? Кстати, я буду правильно ударить себя по лицу.
mbcaradima

Ответы:

9

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

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

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

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

Пирамиды, созданные с -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
jgrocha
источник
5

У меня точно такие же проблемы с рендерингом растров в QGIS от PostGIS (см. Мой недавний вопрос ). Я нашел этот пост полезным и немного увеличил следующий улучшенный рендеринг растров:

shared_buffers = 5000 МБ work_mem = 100 МБ maintenance_work_mem = 100 МБ

Однако с учетом сказанного я полностью согласен с тем, что производительность растров PostGIS в QGIS невелика. Я имею дело с 608 сжатыми геотифами, которые отлично загружаются как VRT, но по существу непригодны для использования в PostGIS. Попробуйте увеличить производительность сервера dbase, но кроме этого я не могу быть слишком полезным. Мне также, возможно, придется полагаться на файловую систему для обслуживания растров в моей организации.

утес
источник
Спасибо за ваш комментарий, Клифф. Я применил некоторые ваши изменения и сообщу о любых существенных улучшениях производительности. В целом я должен сказать, что производительность QGIS разочаровывает для визуализации растров PostGIS и загрузки / запроса таблиц атрибутов. Растровая производительность в PostGIS также разочаровывает. У меня нет ни одной из этих проблем с файловыми базами геоданных, поэтому мне интересно, что не так?
mbcaradima
1
Мои чувства точно. Я провел неделю, пытаясь заставить это работать, и просто не мог заставить это работать. Сейчас я тестирую свою виртуальную машину (Ubuntu Server) с 10 процессорами и 10 ГБ оперативной памяти. Если это все еще вялый, я должен делать что-то еще не так. Я также озадачен, почему слои WMS в QGIS в основном непригодны из-за их низкой скорости рендеринга. Мы должны больше об этом рассказать, поскольку мы оба в одной лодке.
Клифф
Если они отлично загружаются как VRT, почему вы не остановились на этом? Какую выгоду вы ожидаете от этого великого растрового путешествия?
Пол Рэмси
Полагаю, мой ответ на этот вопрос, Пол, именно то, что OP сказал в следующем посте: «Однако в этот момент я задаюсь вопросом, зачем вообще запускать QGIS + PostGIS для своих нужд ГИС, особенно когда файловые базы данных ESRI включают растровые атрибуты, наборы данных мозаики». и другие растровые операции, выполняемые базой геоданных. Так что, возможно, либо я действительно что-то упустил, либо QGIS и PostGIS не соответствуют моим потребностям в ГИС. Мне трудно в это поверить ».
Клифф
1
Кроме того, я бы сказал, что около 70% анализа, который я делаю, проводится на растрах, и примерно 40% данных, которые я хочу передать своей организации через QGIS, являются растровыми данными. Просто имеет смысл иметь все растровые и векторные данные в одной базе данных, чтобы пользователи могли установить одно соединение и иметь доступ к базе данных всей нашей организации. Вместо этого мне пришлось бы создавать кредиты для базы данных и кредиты для общего файлового ресурса. С другой стороны, я серьезно подумываю о ликвидации QGIS и создании веб-приложения с Geoserver (ps: всегда готов сотрудничать в этом с кем-либо заинтересованным).
Клифф
4

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

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

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

Рафаэль Жоливе
источник