Hiển thị các geotiff lớn (hoặc vrts) với QGIS?


10

Tôi đang thao túng và xử lý các raster toàn cầu ở độ phân giải 30m. Tổng kích thước raster thường là [1.440.000 560.000]. Tôi có quyền truy cập vào một siêu máy tính, vì vậy tôi đã viết mã cho phép tôi chia các trình quét toàn cầu thành các phần có thể quản lý, thực hiện một số phép tính song song và ghi chúng vào đĩa khá nhanh.

Tôi đã va vào một bức tường, mặc dù, khi nói đến việc hiển thị kết quả. Tôi thường xây dựng một raster ảo của gạch bao phủ toàn cầu và kéo nó vào QGIS. Nhưng nó cực kỳ chậm (vài phút để tải, nếu có). Và nếu tôi cố xoay hoặc phóng to, nó sẽ mất nhiều phút nữa. Cách tiếp cận đầu tiên của tôi để giải quyết vấn đề này là xây dựng tổng quan bằng gdaladdo. Tuy nhiên, những thứ này sẽ mất mãi mãi để xây dựng (như trong vài ngày), điều này không có lợi cho việc phát triển các thuật toán. Dưới đây là danh sách những điều tôi đã thử và tại sao / làm thế nào chúng thất bại.

  1. xây dựng tổng quan về vrt. Như đã đề cập ở trên, việc này mất hơn 2 ngày để hoàn thành 8 cấp độ. Điều đó là không thể chấp nhận cho mục đích của tôi.

  2. xây dựng tổng quan trên các ô riêng lẻ, sau đó bằng cách nào đó hợp nhất thành một vrt có chứa các tổng quan. Tôi có thể xây dựng các tổng quan trên gạch khá nhanh (siêu máy tính), nhưng tôi không thể khắc phục chúng. Tôi đã thử:

    2a. gdal_merge trên các ô có tổng quan, nhưng các tổng quan không được giữ lại (hoặc ít nhất là không được công nhận bởi QGIS) trong tiff đầu ra.

    2b. gdalbuildvrt trên các ô có tổng quan, nhưng như trên, các tổng quan không được giữ lại. [Điều này không chính xác, xem chỉnh sửa.]

    2c. Tôi cũng đã thử kết hợp tổng quan xây dựng các ô cho các cấp 1-6 và xây dựng các cấp 7-8 trực tiếp trên vrt (về cơ bản là tùy chọn 2b) nhưng nó vẫn chỉ mất mãi mãi cho hai cấp này. Tôi đã làm một số thử nghiệm và thấy rằng tổng quan ngói đang thực sự sử dụng để xây dựng để tổng quan VRT, nhưng nó vẫn còn trên thứ tự của một ngày để hoàn thành việc tổng quan về VRT.

Vì vậy, tôi hy vọng ai đó ở đây có một số gợi ý về nơi tôi nên đi tiếp theo. Dưới đây là một số tùy chọn tôi đang xem xét:

  1. Tự tay tạo ra các kim tự tháp toàn cầu. Tôi cảnh giác khi kết hợp chúng thành một tệp .ovr vì tôi cho rằng điều đó sẽ khó khăn.

  2. Sử dụng máy chủ bản đồ (Geoserver). Tôi biết rất ít về điều này và tôi lo lắng rằng nó sẽ không vượt qua được rào cản thời gian trong khi thêm sự phức tạp vào quy trình của tôi.

  3. Tách tên miền theo châu lục hoặc một số khu vực khác. Tôi thực sự muốn tránh tùy chọn này.

Bạn có thể hỏi "tại sao bạn cần xem toàn bộ quả cầu ở độ phân giải 30m?" Một ví dụ: Tôi lấy mặt nạ các pixel nước (trên toàn cầu) và khung xương để tìm sông và thực hiện các phép đo. Thuật toán skeletonization của tôi yêu cầu một chút điều chỉnh (để cắt tỉa nhánh, loại bỏ các vòng lặp, làm sạch chung, v.v.), và đầu ra nhất thiết phải ở mức 30m. Vì các dòng sông và cảnh quan rất đa dạng trên toàn cầu, tôi cần có thể xoay quanh để xem tác động của bất kỳ thay đổi nào tôi đã thực hiện.

Tôi cũng đã xem qua QGIS để đảm bảo rằng không có bất kỳ cài đặt nào tôi có thể chơi để hiển thị các trình quét lớn nhanh hơn, nhưng tôi không thấy gì cả. Thiếu mua ổ SSD, tôi nghĩ rằng nó chạy nhanh nhất có thể. (Ổ cứng của tôi có I / O ~ 250MB / s).


Tôi phát hiện ra rằng việc xây dựng các tổng quan trên các ô riêng lẻ, sau đó xây dựng một vrt dường như duy trì các tổng quan - phần "Kim tự tháp" của QGIS trong siêu dữ liệu cho tệp trống, nhưng trong phần "Kích thước" có một mục nhập cho mỗi cấp độ tổng quan (ví dụ: X 720000, Y 140; X 360000, Y 70, v.v.). Vì vậy, tôi đã sai khoảng 2b.

Tôi cũng thấy rằng nếu tôi chỉ kéo tất cả các ô vào QGIS, nó sẽ hiển thị trong vòng một phút, trong khi nếu tôi kéo vrt tham chiếu các ô đó, sẽ mất> 5 phút (không biết chính xác tôi đã giết bao lâu quá trình).


Tôi đã thực hiện một số thử nghiệm trên máy tính có ổ SSD và tôi thấy rằng tôi có thể tải, hiển thị và hiển thị các vrts toàn cầu (không có bất kỳ tổng quan nào) một cách thành công và ở mức chấp nhận được. Tôi đã đặt mua ổ SSD PCIe 1TB với hy vọng nó sẽ cho phép tôi làm điều tương tự trên máy tính của mình. Sẽ cập nhật với kết quả.


Bạn có tạo tổng quan cho tệp VRT hoặc hình ảnh riêng lẻ từ tệp VRT không? GDAL cho phép bạn sử dụng tổng quan VRT ở độ phân giải thấp (ví dụ: đối với 64 x 64, 128 x 128) và sử dụng tổng quan từ các trình quét riêng lẻ ở độ phân giải trung bình. Để tạo tổng quan cho các trình quét riêng lẻ từ VRT, hãy sử dụng gdaladdo trên tập lệnh sẽ lặp lại các tệp của bạn. Trước hết tạo tổng quan cá nhân. Hơn tạo tổng quan cho toàn bộ VRT. Đừng chồng chéo tổng quan!
Dmitry Baryshnikov

Cảm thấy như tùy chọn 2c ở trên và hơn 2 ngày để tạo tổng quan cho toàn bộ VRT được coi là không thể chấp nhận.
dùng49584

Bởi vì tổng quan cá nhân mast được tạo ra trước. Và dường như đối với tôi, mức độ tổng quan đã chọn sai. Cần gdaladdo tmp.vrt 2 4 8 16 và gdaladdo cá nhân.tif 2 4 8 16 32 64 ... Topicstarter phải tính mức tổng quan vrt max là: kích thước vrt trong pix / số lượng hình ảnh * 64 pix = tổng quan tối đa cho vrt. Chúng tôi đã tạo ra các tổng quan như vậy cho Bắc Mỹ cho Landsat 30 m trên máy tính để bàn. Kết quả được tạo ra trong vài ngày. Và kết xuất VRT trong QGIS nhanh hơn so với geotiff được khảm trong ArcGIS.
Dmitry Baryshnikov

1
Hãy xem, họ đã viết I also tried a hybrid of building overviews for the tiles for levels 1-6 and building levels 7-8 directly on the vrtmà cảm thấy giống như thứ tự mà bạn đề xuất và đó tự nhiên là đúng. Bản thân tôi sẽ không tính toán 2 4 8 ... tổng quan về VRT nếu các ô riêng lẻ có chúng để tiết kiệm thời gian và dung lượng đĩa. ROI nhỏ sau đó sẽ tìm thấy tổng quan từ một vài gạch và điều đó là đủ nhanh.
dùng49584

Điều này không đúng vì 2 4 8 của tệp riêng lẻ (không phải gạch!) Không giống với 2 4 8 của vrt. Ví dụ: chúng tôi có hình ảnh riêng lẻ với kích thước 8000 x 8000 và 1000 x 1000 hình ảnh trong vrt. Kích thước hình ảnh tổng quan 64 x 64 pix sẽ ở mức 8 cho từng tệp riêng lẻ và đối với toàn bộ vrt, nó sẽ ở cấp 18! Và mức tối thiểu cho toàn bộ vrt sẽ là 8. Vì vậy, đối với toàn bộ vrt cần sử dụng các cấp từ 9 đến 18 và cho các tệp riêng lẻ từ 2 đến 8.
Dmitry Baryshnikov

Câu trả lời:


6

Bạn dường như có hai mối quan tâm chính: VRT id chậm với trình duyệt và chậm để xây dựng tổng quan toàn cầu.


Mặc dù tôi chắc chắn rằng GDAL VRT đã từng chậm đối với tôi và MapServer của tôi nhiều năm trước nhưng có thể tình hình đã thay đổi. Tôi đã tạo một lớp thử nghiệm với 10000 hình ảnh trên không (kích thước hình ảnh / hình xếp từ 10000x10000 đến 12000x12000 pixel) và bây giờ GDAL VRT thực sự nhanh hơn chỉ số shapefile MapServer gốc và phục vụ với máy tính thử nghiệm 6 ô (256x256) mỗi giây trong một thử nghiệm đơn giản với 1 luồng trong đó GetMaps đạt mức tổng quan đầu tiên. Khảm với 10000 hình ảnh vẫn còn khá nhỏ và tôi đoán rằng trong thử nghiệm của tôi, Linux có toàn bộ tệp VRT trong bộ nhớ đệm. Bạn có bao nhiêu hình ảnh trong VRT?

Chương sau có thể chứa thông tin cũ, đọc có trách nhiệm:

Có một số bằng chứng cho thấy VRT chậm khi chứa số lượng hình ảnh khổng lồ. Đó không phải là vì VRT là một chỉ mục ở định dạng XML và nó không hỗ trợ chỉ mục không gian dẫn đến quét toàn bộ tệp XML mỗi lần. Bạn không thể làm gì để cải thiện điều đó với GDAL đơn giản, thậm chí đã có một số cuộc thảo luận về việc thực hiện chỉ số không gian cho VRT http://osgeo-org.1560.x6.nabble.com/gdal-dev-Don-t-we- có bất kỳ ý tưởng nào cho GSoC-2017-td5309810.html .

Nếu bạn sẵn sàng cài đặt phần mềm mới, cách giải quyết đơn giản nhất có thể là sử dụng MapServer với brickindex http://www.mapserver.org/optimization/tileindex.html . Nếu bạn tạo một brickindex với gdaltindex http://www.gdal.org/gdaltindex.html và tạo một chỉ mục cho brickindex cũng như với shptree http://www.mapserver.org/utilities/shptree.htmlsau đó MapServer sẽ có thể truy cập rất nhanh tất cả các tệp hình ảnh mà bạn có. Tạo tổng quan cho từng ô riêng lẻ và phục vụ lớp thông qua WMS cho QGIS và bạn đã giải quyết phần đầu tiên của vấn đề nhưng không phải là vấn đề với tổng quan toàn cầu. Ngay cả khi bạn đã tạo tổng quan cho từng ô riêng lẻ, sẽ rất chậm để mở hàng nghìn tệp hình ảnh để bao phủ một khu vực rộng lớn và do đó bạn phải giới hạn số lượng tệp bằng cách tạo hình ảnh tổng quan bao phủ diện tích lớn hơn. Đó là những gì bạn đã cố gắng thực hiện bằng cách xây dựng các tổng quan về lỗ VRT với gdaladdo.

Tôi không biết bất kỳ công cụ làm sẵn nào trong thế giới GDAL / MapServer để tự động tạo các kim tự tháp toàn cầu. Bạn có thể chuyển đổi các ô xếp từ VRT toàn cầu thành một tập hợp các hình ảnh có kích thước pixel lớn hơn bằng cách viết một tập lệnh chạy gdal_translate http://www.gdal.org/gdal_translate.html bằng cách trượt -prowjin hoặc -srswin. Sau đó, bạn có thể kết hợp các ô kết quả thành một lớp tổng quan mới với gdalbuildvrt hoặc gdaltindex.

Vì bạn cũng cân nhắc sử dụng GeoServer, tôi khuyên bạn nên có một chiến lợi phẩm tại tập lệnh gdal_retile http://www.gdal.org/gdal_retile.html được viết để xử lý trường hợp của bạn. Cũng có thể sử dụng các ô mà gdal_retile tạo trực tiếp dưới dạng tổng quan với QGIS bằng cách xây dựng VRT trên chúng. Tuy nhiên, vấn đề đầu tiên với các tệp VRT khổng lồ chậm sẽ vẫn còn.


1
Tôi đánh giá cao downvote nhưng tôi cũng muốn đọc một lời giải thích hoặc một câu trả lời tốt hơn. Tuyến MapServer là lựa chọn của tôi khi VRT quá chậm và nó phục vụ tốt cho tôi với một số terabyte hình ảnh.
dùng49584

Chà, tôi đã không thể hoàn thành đầy đủ một vrt toàn cầu với các tổng quan nên tôi không biết điều đó sẽ diễn ra nhanh như thế nào. Không có tổng quan, bạn đúng là mất quá nhiều thời gian để hiển thị. Tôi có thể có nhiều hoặc ít hình ảnh trong vrt của mình như tôi muốn. Tôi đã thử ít nhất là 60 và lên tới 4000. Chưa bao giờ là 10000. Tôi muốn tránh sự phức tạp của giải pháp loại Mapserver. Tôi đã thực hiện một số nghiên cứu thêm và tôi nghĩ rằng có lẽ các tổng quan riêng lẻ thực sự được giữ lại khi tôi xây dựng một vrt - tôi sẽ kiểm tra điều này và đăng một bản cập nhật vào thứ Hai.
Jon

5

Ok, tôi đã giải quyết cả hai vấn đề của mình ... chủ yếu bằng cách mua SSD NVMe. Đĩa đọc / ghi của tôi đã tăng từ 125 MB / s lên 1200 MB / s.

Theo lập trình, có một vài điều bạn có thể làm để giúp tốc độ đọc / ghi của bạn tăng lên. Đầu tiên, hãy xem xét kích thước khối của tiff của bạn. Nếu bạn đang sử dụng một tiff sọc, khi bạn phóng to đến một khu vực cụ thể, phần mềm GIS sẽ phải đọc từng hàng hoàn chỉnh của khu vực, bao gồm các phần của tiff sẽ không được hiển thị, để hiển thị khu vực đó. Ví dụ: nếu bạn phóng to vào vùng 256 x 256 pixel, nếu bạn có một sọc kẻ sọc, phần mềm sẽ phải đọc ít nhất 256 khối (mỗi khối một hàng). Nếu bạn có một lát gạch (lát gạch ở 256 x 256), số khối tối đa phải đọc là 4 (và tối thiểu là 1). Vì vậy, điều đầu tiên bạn có thể làm là đảm bảo rằng bạn đang sử dụng một tiff tiff (tùy chọn tạo TILED = YES trong gdal),

Thứ hai, một cách tiếp cận lai với tổng quan dường như hoạt động tốt. Nếu bạn có thể song song hóa các hoạt động của mình, bạn có thể thêm tổng quan vào các ô riêng lẻ khá nhanh, nhưng điều này sẽ chỉ có lợi cho bạn đối với các độ phân giải nhỏ hơn kích thước của bạn. Tôi đã tạo tổng quan nội bộ của cấp 2 4 8 16 32 và 64 trên các ô riêng lẻ. Sau đó, xây dựng VRT và tạo tổng quan về các mức 128, 256 và 512 trên VRT (hãy nhớ rằng đây là các bộ dữ liệu toàn cầu ở độ phân giải 30m - cấp độ của bạn sẽ thay đổi tùy thuộc vào số pixel trong tiff của bạn). Tổng thời gian để tạo các tổng quan riêng lẻ là theo thứ tự phút (tùy thuộc vào số lượng chủ đề bạn có thể chạy và số lượng ô bạn có), nhưng việc tạo tổng quan trên VRT vẫn theo thứ tự một giờ. Sự cải thiện thời gian chạy so với bài đăng ban đầu của tôi là do SSD và tạo ra ít cấp độ hơn trên VRT.

Thứ ba, bạn có thể chơi với tùy chọn GDAL_MAX_DATASET_POOL_SIZE khi xây dựng vrts như được mô tả ở dưới cùng của trang này . Nó thiết lập số lượng tiff tối đa để giữ trong bộ nhớ cùng một lúc.

Thứ tư, tôi thấy rằng việc nén bằng PACKBITS cung cấp thời gian hiển thị nhanh nhất. Các tệp không nhỏ như LZW, nhưng đó là một sự đánh đổi mà bạn có thể sẵn sàng thực hiện.

Kết quả là một VRT tải nhanh và pans / zoom gần như liền mạch.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.