câu hỏi của tôi liên quan đến việc sử dụng và hiệu suất của một số công cụ phần mềm kết hợp, cụ thể là PostgreSQL, PostGIS, QGIS và GDAL.
Tôi là người dùng ArcGIS, Python và R lâu năm, người quan tâm đến việc đa dạng hóa vào hệ sinh thái GIS nguồn mở miễn phí và cả Linux. Gần đây, tôi rất quan tâm đến việc sử dụng QGIS (ver 2.8) cùng với PostgreSQL (ver 9.4) và PostGIS (ver 2.1) và tôi đã cài đặt phần mềm trên máy tính có Windows 8.1 x64 (thông số kỹ thuật của máy tính ngắn gọn: ThinkPad X200s với Core 2 tốc độ 2.1 GHz, RAM 8GB và ổ SSD 240 GB). Khi tôi tìm hiểu cách quản lý dữ liệu không gian của mình (trị giá ~ 100 GB), tôi muốn chạy Ubuntu trên máy này.
Hiện tại, tôi chỉ đơn giản là cố gắng lưu trữ và lấy các shapefiles và raster một cách đáng tin cậy. Cho đến nay tôi đã thành công trong việc tải các shapefiles vào PostGIS, nhưng các raster đang tỏ ra có vấn đề hơn. Tôi đã hoàn thành nhập khẩu đơn lẻ và hàng loạt các tệp GeoTIFF và GRID nhỏ, nhưng các trình quét lớn hơn (giả sử, tệp 15619x14655 có kích thước 870 MB trên đĩa) có thể tải mãi mãi vào PostGIS. Tôi đã đọc và định cấu hình công cụ raster2pgsql để xây dựng các chỉ mục không gian và tải các trình quét bằng cách sử dụng các tham số sau:
raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgresHiệu suất trong nhập khẩu vẫn còn rất kém và phần cứng không phải là vấn đề. Hình dung của các trình quét PostGIS trong QGIS thậm chí còn tệ hơn, từ từ tải các trình quét nhỏ ở mức tốt nhất hoặc đóng băng hoàn toàn. Các raster lớn như người tôi đã đề cập là không thể hình dung được trong QGIS. Từ các tài liệu và thảo luận trên diễn đàn, sự thiếu sót này dường như là do trình điều khiển raster PostGIS của GDAL chứ không phải do chính QGIS. Các cuộc thảo luận diễn đàn đề cập đến vấn đề này một cách ngắn gọn và một số thậm chí còn đề xuất rằng các raster không nên được lưu trữ trong PostGIS (điểm nào trong cơ sở dữ liệu không gian không xử lý trơn tru các trình quét?). Tuy nhiên, tôi thường xuyên sử dụng cơ sở dữ liệu địa lý tệp của ESRI để lưu trữ, trực quan hóa và phân tích các trình quét khá lớn (~ 70GB) một cách nhanh chóng và dễ dàng, và ArcGIS 10.1 không bao giờ bị đóng băng hoặc chậm do các hoạt động thông thường như vậy.
Có điều gì tôi đang thiếu ở đây, một nút cổ chai tôi chưa giải quyết? PostgreSQL có cần điều chỉnh để nhận ra lợi ích hiệu suất của PostGIS không? Tôi có thiếu một phiên bản GDAL mà tôi cần săn lùng và biên dịch không? Làm cách nào để cải thiện hiệu suất và hình ảnh của PostGIS trong QGIS của shapefiles và raster đặc biệt? Làm cách nào tôi có thể tận hưởng vinh quang của việc quản lý dữ liệu không gian toàn diện và nhanh chóng thông qua thiết bị đầu cuối Linux? Bất kỳ trợ giúp về vấn đề này sẽ được hoan nghênh!
Tôi đã làm theo hướng dẫn này bởi một Duncan Golicher: https://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/
Tôi đã sử dụng gạch với cài đặt tự động ban đầu, nhưng tôi đặt lại ốp lát thành 100x100 ô mỗi hàng và sau đó bao gồm các kim tự tháp như trong hướng dẫn như sau:
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 postgresTôi đã có thể nhập thành công raster 870 MB IMG trong một thời gian tốt và hiển thị nó trong QGIS mà không làm chậm hoặc làm hỏng ứng dụng. Thời gian kết xuất không linh hoạt như tôi mong đợi, nhưng nó có thể chấp nhận được. Tôi sẽ đọc thêm về tham số -l để sử dụng nó đúng cách.
Ngẫu nhiên, khi nhập tệp dem.img dưới dạng bảng dem100, một bảng raster khác đã được tạo có tên là "o_4_dem100". Khi tôi nhập nó dưới dạng một lớp trong QGIS, nó có phạm vi giá trị trong khoảng từ 201 đến 524, trong khi lớp dem100 có phạm vi từ 36 đến 524. Tôi có đúng không khi cho rằng bảng phụ này là bảng kim tự tháp hẹp hơn phạm vi giá trị là kết quả của việc được tổng hợp đến độ phân giải thấp hơn?
Tôi không nghĩ rằng phần cứng không đầy đủ là vấn đề. Đây là một bản tóm tắt ngắn gọn về những gì tôi đã tìm thấy cho đến nay.
Trình điều khiển raster PostGIS của GDAL đã có vấn đề về hiệu suất trong quá khứ ( xem thêm ở đây ). Mặc dù những vấn đề này đã được ghi nhận vào năm 2012, tôi tự hỏi liệu GDAL 1.11.2 được tìm thấy trong QGIS 2.8 có còn vấn đề này không. Chắc chắn có những người khác sử dụng QGIS và PostGIS để hiển thị và lưu trữ raster?
Trong một lưu ý liên quan có thể có, tôi cũng đã gặp vấn đề về hiệu năng khi mở các bảng thuộc tính PostGIS trong QGIS với các bảng có ~ 4,7 triệu bản ghi . Sau một vài gợi ý trong chủ đề đó và không khắc phục được sự cố, cuối cùng tôi đã nộp báo cáo lỗi với QGIS cuối cùng đã bị đóng và liên kết với báo cáo lỗi tương tự sau đây . Mặc dù báo cáo lỗi đã bị đóng, nhưng nó dường như không được sửa ...
Để tổng hợp những nỗ lực của tôi cho đến nay:
- Tôi đã tối ưu hóa máy chủ PostgreSQL cho dữ liệu không gian.
- Tôi đã xây dựng các chỉ số không gian cho các bảng hình học và thực hiện VACUUM.
- Hành vi của QGIS để mở các bảng thuộc tính lớn (~ 4,7m bản ghi) dường như cố gắng đọc tất cả các bản ghi thay vì trả về một tập hợp con để xem tức thời. Điều này dẫn đến hiệu suất kém.
Hiệu suất trong việc hiển thị các bảng hình học PostGIS lớn dường như không phải là vấn đề.
Với raster2pgsql, các raster đã được lập chỉ mục, lát gạch và được nhập dưới dạng các bảng raster với các kim tự tháp trong PostGIS.
- Các trình quét có kích thước hợp lý vẫn rất chậm để nhập vào PostGIS, hãy để một mình mở và xoay quanh trong QGIS.
Cũng đáng lưu ý rằng khi nhập các trình quét lớn hoặc mở các bảng thuộc tính lớn bằng PostGIS, mức tiêu thụ bộ nhớ cho raster2pgsql và qgis-bin là hơn 1GB. Như @Michael và @Paul đã đề cập để trả lời câu hỏi ban đầu của tôi, có vẻ như PostGIS không mang lại nhiều lợi ích nếu lưu trữ các trình quét. Tuy nhiên, tại thời điểm đó tôi đặt câu hỏi tại sao tôi lại chạy QGIS + PostGIS cho tất cả các nhu cầu về GIS của mình, đặc biệt là khi tệp ESRIGDB cho phép các thuộc tính raster, bộ dữ liệu khảm và các hoạt động raster khác được cơ sở dữ liệu địa lý tạo điều kiện. Vì vậy, có lẽ tôi thực sự đang thiếu một cái gì đó hoặc QGIS và PostGIS không đáp ứng nhu cầu về GIS của tôi. Tôi thấy cái sau khó tin.
