Niska wydajność w zakresie przechowywania dużych rastrów w PostGIS i wizualizacji w QGIS

moje pytanie dotyczy użycia i wydajności kilku narzędzi programowych w połączeniu, a mianowicie PostgreSQL, PostGIS, QGIS i GDAL.

Jestem wieloletnim użytkownikiem ArcGIS, Python i R, który jest zainteresowany dywersyfikacją w kierunku wolnego ekosystemu GIS open source oraz Linuksa. Ostatnio bardzo interesuje mnie używanie QGIS (wer. 2.8) wraz z PostgreSQL (wer. 9.4) i PostGIS (wer. 2.1) i zainstalowałem oprogramowanie na komputerze z systemem Windows 8.1 x64 (w skrócie specyfikacja komputera: ThinkPad X200 z rdzeniem 2 2,1 GHz, 8 GB pamięci RAM i dyskiem SSD 240 GB). Gdy nauczę się zarządzać danymi przestrzennymi (wartość ~ 100 GB), chciałbym uruchomić Ubuntu na tym komputerze.

W tej chwili po prostu staram się niezawodnie przechowywać i odzyskiwać pliki kształtów i rastry. Do tej pory z powodzeniem ładowałem pliki kształtu do PostGIS, ale rastry okazują się bardziej problematyczne. Z powodzeniem ukończyłem import pojedynczych i seryjnych małych plików geoTIFF i GRID, ale większe rastry (powiedzmy, plik IMG komórki 15619x14655 lub plik TIFF o wielkości 870 MB na dysku) trwa wiecznie, aby załadować je do PostGIS. Przeczytałem i skonfigurowałem narzędzie raster2pgsql do budowania wskaźników przestrzennych i ładowania rastrów za pomocą kafelków przy użyciu tych parametrów:

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

Wydajność importowania jest nadal bardzo niska, a sprzęt nie stanowi problemu. Wizualizacja rastrów PostGIS w QGIS jest jeszcze gorsza, powoli ładuje co najwyżej małe rastry lub całkowicie zamraża. Duże rastry, takie jak te, o których wspomniałem, są niemożliwe do wizualizacji w QGIS. Z dokumentacji i dyskusji na forum wynika, że ​​to niedociągnięcie wynika ze sterownika rastrowego PostGIS GDAL, a nie z samego QGIS. Dyskusje na forum wspominają o tym problemie krótko, a niektórzy sugerują nawet, że rastry nie powinny być przechowywane w PostGIS (jaki jest sens w przestrzennej bazie danych, która nie radzi sobie płynnie z rastrami?). A jednak rutynowo używam geobazy danych pliku ESRI do szybkiego, łatwego przechowywania, wizualizacji i analizy dość dużych (~ 70 GB) rastrów, a ArcGIS 10.1 nigdy nie zawiesza się ani nie zwalnia z powodu takich rutynowych operacji.

Czy brakuje mi czegoś, wąskiego gardła, którego nie rozwiązałem? Czy PostgreSQL wymaga dostrajania, aby wykorzystać zalety PostGIS w zakresie wydajności? Czy brakuje mi wersji GDAL, którą muszę wytropić i skompilować? Jak mogę poprawić wydajność i wizualizację PostGIS w QGIS, zwłaszcza plików kształtów i rastrów? Jak mogę cieszyć się chwałą kompleksowego i szybkiego zarządzania danymi przestrzennymi za pośrednictwem terminala Linux? Każda pomoc w tej sprawie byłaby mile widziana!

Śledziłem ten przewodnik przez Duncana Golichera: https://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/

Początkowo korzystałem z kafelków z ustawieniem automatycznym, ale zresetowałem kafelki do 100 x 100 komórek na wiersz, a następnie umieściłem piramidy, jak pokazano w przewodniku, tak:

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

Udało mi się z powodzeniem zaimportować raster IMG o wielkości 870 MB w odpowiednim czasie i wyświetlić go w QGIS bez spowalniania lub zawieszania aplikacji. Czas renderowania nie jest tak szybki, jak się spodziewałem, ale jest do przyjęcia. Przeczytam dalej o parametrze -l, aby użyć go poprawnie.

Nawiasem mówiąc, podczas importowania pliku dem.img jako tabeli dem100 utworzono kolejną tabelę rastrową o nazwie „o_4_dem100”. Kiedy importuję go jako warstwę do QGIS, ma on zakres wartości od 201 do 524, podczas gdy warstwa dem100 ma zakres od 36 do 524. Czy mam rację zakładając, że ta dodatkowa tabela jest piramidą, która ma węższy zakres wartości w wyniku agregacji do niższej rozdzielczości?

Nie sądzę, że problemem jest nieodpowiedni sprzęt. Oto krótkie podsumowanie tego, co do tej pory znalazłem.

Sterownik rastrowy PostGIS w GDAL miał problemy z wydajnością w przeszłości ( patrz również tutaj ). Chociaż problemy te zostały odnotowane w 2012 roku, zastanawiam się, czy GDAL 1.11.2 znaleziony w QGIS 2.8 nadal ma ten problem. Czy na pewno są inni używający QGIS i PostGIS do wizualizacji i przechowywania rastra?

W ewentualnej powiązanej notatce miałem również problemy z wydajnością podczas otwierania tabel atrybutów PostGIS w QGIS z tabelami o ~ 4,7 mln rekordów . Po kilku sugestiach w tym wątku i bez rozwiązania problemu, ostatecznie złożyłem raport o błędzie w QGIS, który został ostatecznie zamknięty i powiązany z następującym podobnym raportem o błędzie . Mimo że raport o błędzie jest zamknięty, wydaje się, że nie został naprawiony ...

Podsumowując dotychczasowe wysiłki:

• Zoptymalizowałem serwer PostgreSQL pod kątem danych przestrzennych.
• Zbudowałem wskaźniki przestrzenne dla tabel geometrii i wykonałem VACUUM.
• Wygląda na to, że zachowanie QGIS podczas otwierania dużych tabel atrybutów (~ 4,7 mln rekordów) próbuje odczytać wszystkie rekordy, zamiast zwracać podzbiór do natychmiastowego przeglądania. Prowadzi to do słabej wydajności.

• Wydajność renderowania dużych tabel geometrii PostGIS nie wydaje się stanowić problemu.

• W raster2pgsql rastry zostały zindeksowane, sąsiadująco i zaimportowane jako tabele rastrowe z piramidami w PostGIS.

• Importowanie rastrów o dowolnym rozsądnym rozmiarze jest nadal niezwykle powolne do PostGIS, nie mówiąc już o otwieraniu i przeglądaniu w QGIS.

Warto również zauważyć, że podczas importowania dużych rastrów lub otwierania dużych tabel atrybutów za pomocą PostGIS zużycie pamięci dla raster2pgsql i qgis-bin wynosi ponad 1 GB. Jak wspomnieli @Michael i @Paul w odpowiedzi na moje początkowe pytanie, wydaje się, że PostGIS nie ma przynosić wiele, jeśli w ogóle, żadnych korzyści z przechowywania rastrów. Jednak w tym momencie zastanawiam się, dlaczego miałbym w ogóle uruchamiać QGIS + PostGIS dla moich potrzeb GIS, szczególnie gdy pliki ESRI GDB obsługują atrybuty rastrowe, mozaikowe zestawy danych i inne operacje rastrowe obsługiwane przez geobazę. Więc może albo naprawdę coś mi brakuje, albo QGIS i PostGIS nie spełniają moich potrzeb GIS. Trudno w to uwierzyć.

Jeśli chcesz wyświetlać duże rastry w QGIS, musisz zbudować piramidy, albo dla obrazu tif w systemie plików, albo dla obrazu zarejestrowanego w Postgis.

Różnica w wydajności renderowania QGIS między dużym rastrem w systemie plików lub w Postgis jest miminalna. Użytkownicy nie zauważą różnicy. Ale - jeśli i tylko jeśli - budujesz piramidy z opcją -l.

Jeśli po prostu zaimportujesz obraz bez opcji -l lub po prostu -l 4 nie będzie działać .

Jeśli użyjesz, na przykład, -l 2,4,8,16zostaną utworzone cztery poziomy piramid, jak na poniższej warstwie:

Jeśli chcesz mieć lepszą obsługę, powinieneś dodać więcej poziomów piramid -l 2,4,8,16,32,64,128,256. Stworzy to osiem poziomów piramid.

Podsumowując, odpowiedź na to pytanie brzmi: zaimportuj raster z opcją -li użyj tej samej liczby poziomów piramidy, jak w przypadku tego samego rastra w systemie plików.

Na przykład:

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

Mam dokładnie takie same problemy z renderowaniem rastrów w QGIS z PostGIS (patrz moje ostatnie pytanie ). Ten post był pomocny i nieznacznie zwiększyłem następujące ulepszone renderowanie rastrowe:

shared_buffers = 5000 MB work_mem = 100 MB Maintenance_work_mem = 100 MB

Niemniej jednak całkowicie się zgadzam, że wydajność rastrów PostGIS w QGIS nie jest świetna. Mam do czynienia z 608 skompresowanymi geotiffami, które ładują się świetnie jako VRT, ale są zasadniczo bezużyteczne w PostGIS. Spróbuj zwiększyć wydajność serwera dbase, ale poza tym nie mogę być zbyt pomocny. Ja też być może będę musiał polegać na systemie plików, aby obsługiwać rastry w mojej organizacji.

Nie jestem pewien, czy to był twój przypadek, ale dowiedziałem się, -Iże nie należy go używać razem z dołączanymi danymi -a.

Zaimportowałem wiele plików TIF do DB i -Ifaktycznie tworzy indeks ponownie i wykonuje analysena stole dla każdego pliku, co zajmuje 10 razy więcej czasu.

-Ipowinien być używany tylko podczas tworzenia tabeli, z -popcją.