내 질문은 PostgreSQL, PostGIS, QGIS 및 GDAL과 같은 여러 소프트웨어 도구의 사용 및 성능에 관한 것입니다.
저는 무료 오픈 소스 GIS 생태계와 Linux 로의 다양 화에 관심이있는 오랜 ArcGIS, Python 및 R 사용자입니다. 최근 PostgreSQL (9.4 버전) 및 PostGIS (2.1 버전)와 함께 QGIS (버전 2.8)를 사용하는 데 관심이 많았으며 Windows 8.1 x64 (컴퓨터 사양 요약 : ThinkPad) 컴퓨터에 소프트웨어를 설치했습니다. 2.1GHz 코어 2, 8GB RAM 및 240GB SSD가 장착 된 X200). 공간 데이터 (100GB 상당)를 관리하는 방법을 배우면이 컴퓨터에서 Ubuntu를 실행하고 싶습니다.
지금은 쉐이프 파일과 래스터를 안정적으로 저장하고 검색하려고합니다. 지금까지 쉐이프 파일을 PostGIS에로드하는 데 성공했지만 래스터는 더 문제가 있습니다. 작은 geoTIFF 및 GRID 파일의 단일 및 일괄 가져 오기를 성공적으로 완료했지만 더 큰 래스터 (예 : 디스크에서 크기가 15619x14655 셀 IMG 또는 870MB 인 TIFF 파일)를 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가져 오기 성능은 여전히 매우 좋지 않으며 하드웨어는 문제가되지 않습니다. QGIS에서 PostGIS 래스터의 시각화는 더 나빠져서 작은 래스터를 천천히 또는 최대로 천천히로드합니다. 내가 언급 한 것과 같은 큰 래스터는 QGIS에서 시각화 할 수 없습니다. 문서 및 포럼 토론에서이 단점은 QGIS 자체가 아니라 GDAL의 PostGIS 래스터 드라이버 때문인 것으로 보입니다. 포럼 토론에서이 문제를 간략하게 언급하고 일부는 래스터를 PostGIS에 저장해서는 안된다고 제안합니다 (래스터를 원활하게 처리하지 않는 공간 데이터베이스의 요점은 무엇입니까?). 그러나 저는 ESRI의 파일 지오 데이터베이스를 사용하여 매우 큰 (~ 70GB) 래스터를 빠르고 쉽게 저장, 시각화 및 분석하고 ArcGIS 10.1은 이러한 일상적인 작업으로 인해 정지되거나 느려지지 않습니다.
여기에 내가 놓친 것이 있습니까? 아직 해결하지 못한 병목 현상이 있습니까? PostGIS의 성능 이점을 실현하기 위해 PostgreSQL을 조정해야합니까? 사냥하고 컴파일 해야하는 GDAL 버전이 누락 되었습니까? 모양 파일 및 래스터의 QGIS에서 PostGIS 성능 및 시각화를 어떻게 개선합니까? Linux 터미널을 통해 포괄적이고 빠른 공간 데이터 관리의 영광을 어떻게 누릴 수 있습니까? 이 문제에 대한 도움을 환영합니다!
나는 Duncan Golicher가이 가이드를 따랐다 : 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좋은 시간에 870MB IMG 래스터를 성공적으로 가져 와서 응용 프로그램 속도를 늦추거나 충돌시키지 않고 QGIS에 표시 할 수있었습니다. 렌더링 시간이 예상만큼 빠르지는 않지만 허용됩니다. 제대로 사용하기 위해 -l 매개 변수에 대해 더 읽어 볼 것입니다.
또한 dem.img 파일을 dem100 테이블로 가져올 때 "o_4_dem100"이라는 다른 래스터 테이블이 만들어졌습니다. QGIS에서 레이어로 가져올 때 201에서 524 사이의 값 범위를 갖는 반면 dem100 레이어의 범위는 36에서 524 사이입니다.이 추가 테이블이 더 좁은 피라미드 테이블이라고 가정합니다. 더 낮은 해상도로 집계 된 결과 범위?
부적절한 하드웨어가 문제라고 생각하지 않습니다. 지금까지 내가 찾은 것에 대한 간략한 요약입니다.
GDAL의 PostGIS 래스터 드라이버에는 과거의 성능 문제 가있었습니다 ( 여기 참조 ). 이러한 문제가 2012 년에 언급되었지만 QGIS 2.8에서 발견 된 GDAL 1.11.2에 여전히이 문제가 있는지 궁금합니다. 래스터 시각화 및 스토리지에 QGIS 및 PostGIS를 사용하는 다른 업체가 있습니까?
가능한 관련 메모에서, ~ 4.7m 레코드 테이블을 사용하여 QGIS에서 PostGIS 속성 테이블을 열 때 성능 문제가 발생했습니다 . 해당 스레드에서 몇 가지 제안을 한 후 문제를 해결하지 않고 결국 QGIS에 버그 보고서를 제출하여 결국 닫히고 다음과 유사한 버그 보고서에 연결했습니다 . 버그 리포트가 닫혀 있지만 수정되지 않은 것 같습니다 ...
지금까지 나의 노력을 요약하면 다음과 같습니다.
- 공간 데이터에 맞게 PostgreSQL 서버를 최적화했습니다.
- 지오메트리 테이블에 대한 공간 인덱스를 작성하고 VACUUM을 수행했습니다.
- 큰 속성 테이블 (~ 4.7m 레코드)을 여는 QGIS 동작은 즉각적인보기를 위해 서브 세트를 리턴하지 않고 모든 레코드를 읽으려고 합니다. 이로 인해 성능이 저하됩니다.
큰 PostGIS 지오메트리 테이블 렌더링 성능 에는 문제 가 없는 것 같습니다.
raster2pgsql을 사용하면 PostGIS에서 래스터를 색인화하고 바둑판 식으로 배열하고 피라미드가있는 래스터 테이블로 가져 왔습니다.
- 합리적인 크기의 래스터는 PostGIS로 가져 오기가 여전히 매우 느리며 QGIS에서 열거 나 돌리지 않아도됩니다.
큰 래스터를 가져 오거나 PostGIS로 큰 속성 테이블을 열 때 raster2pgsql 및 qgis-bin의 메모리 소비가 1GB를 초과한다는 점도 주목할 가치가 있습니다. @Michael과 @Paul이 초기 질문에 대한 답변으로 언급했듯이 PostGIS는 래스터 저장에 많은 이점을 가져다 줄 의도가 아닙니다. 그러나 그 시점에서 특히 ESRI fileGDB가 래스터 속성, 모자이크 데이터 세트 및 지리 데이터베이스에 의해 촉진되는 기타 래스터 작업을 활성화 할 때 GIS 요구에 대해 QGIS + PostGIS를 실행하는 이유에 대해 질문합니다. 어쩌면 내가 실제로 누락되었거나 QGIS이고 PostGIS가 내 GIS 요구를 충족시키지 못할 수도 있습니다. 나는 후자가 믿기 어렵다는 것을 안다.
