Tốc độ của các định dạng dữ liệu raster khác nhau

Tôi gặp khó khăn khi định vị bất kỳ cuộc thảo luận hoặc so sánh điểm chuẩn nào của các định dạng tệp raster khác nhau (ví dụ: để sử dụng trong phân tích dữ liệu trong R). Có ai có cái nhìn sâu sắc về lý do tại sao các định dạng cụ thể có thể nhanh hơn hoặc chậm hơn? Hay sự khác biệt nên là tối thiểu?

Cụ thể, tôi quan tâm đến việc chuyển đổi raster (ví dụ: tệp GEOTIFF) sang định dạng khác (ví dụ: netCDF) có giá trị cho mục đích tăng tốc độ đọc / ghi và các hoạt động khác.

Đây là một bài viết blog cũ của tôi xem kích thước tệp và thời gian truy cập của các định dạng. Tôi đã không điều tra tốc độ ghi, chỉ có thời gian truy cập. Tôi muốn nói rằng họ có thể có liên quan trực tiếp, nhưng sẽ không thể chứng minh điều đó.

Tóm tắt bài viết: Dường như Packbits cung cấp cho bạn thời gian truy cập tốt nhất (với chi phí không gian đĩa), trong khi Deflate cung cấp cho bạn thời gian truy cập trung gian / chậm cho các tệp trung gian / nhỏ. Ngoài ra, bạn có thể kiểm tra thời gian truy cập theo kinh nghiệm nhiều hơn bằng cách tạo hình thu nhỏ có kích thước khác nhau và thời gian cần bao lâu. Lệnh ví dụ:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

Giả sử rằng điều duy nhất có liên quan đến R trong trường hợp này là nó có thể đọc dữ liệu từ tệp nhanh như thế nào, giống như bất kỳ quy trình nào khác, thì điều đó sẽ cho bạn một dấu hiệu tốt.

Đối với các hoạt động đọc / ghi , bạn có thể kiểm tra tốc độ của các hoạt động đó bằng system.time (). Dưới đây là một số kết quả từ việc tải tệp DEM trong R (gói Raster) được dịch sang bốn định dạng (ASCII, IMG và TIF không nén và Deflate). Ví dụ: trên raster ~ 26MB:

> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
 user  system elapsed 
 0.154   0.002   0.157 

'Đã qua' cho tổng thời gian (giây) được thực hiện cho thao tác. Chạy các hoạt động 10 lần mỗi lần và xem xét thời gian trôi qua trung bình:

              mean   diff
ASC         0.2237 0.3317
IMG         0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none    0.1495 0.0000
tif-pack    0.1513 0.0118

TIFF không nén là nhanh nhất ... được theo dõi rất chặt chẽ bởi Deflate (chậm hơn 0,1%) và TIFF-Packbits (chậm hơn 1,8%), sau đó là IMG (chậm hơn 3,2%) và ASC (chậm hơn 33%). (Đây là trên Macbook Pro 2.4 GHz với ổ SSD, do đó hoạt động trên đĩa rất nhanh)

Điều này chỉ đơn giản là để tải các tập tin, không thao tác chúng.

Có lẽ nó thực sự không phải là một câu hỏi về định dạng hình ảnh raster nào có điểm chuẩn mở tốt hơn - thay vào đó, định dạng hình ảnh raster nào là định dạng nguồn raster hiệu quả nhất để mở và đọc dưới dạng nhập vào một mảng số R. Và sau đó - định dạng đầu ra hiệu quả nhất từ ​​R giả sử bạn sẽ đưa kết quả trở lại cho raster.

Dù bằng cách nào, nếu bạn sẽ làm việc với raster trong R, bạn có thể sẽ sử dụng các gói ngf rgdal và R để bổ sung những gì có trong gói raster . Với sự phụ thuộc chính vào lệnh gdalwarp . Cần phải làm việc phụ thuộc định dạng ở đó để đưa ra lựa chọn raster của bạn. Bạn sẽ tìm thấy một chút bảo hiểm trên SO và các diễn đàn / blog / wiki OSGEO và R khác nhau.

Nhưng vì đây là một diễn đàn GIS nơi sử dụng Python tương đối cao, tôi sẽ lưu ý rằng có những lợi thế khi làm việc với dữ liệu raster trong một mảng numpy Python, với sự phụ thuộc tương tự vào các thư viện gdal để tải, chuyển đổi và xuất raster. Một số người tìm thấy quản lý bộ nhớ và cấu trúc mã trong Python thích hợp hơn R gốc - có lẽ hãy xem RPy2 hoặc PypeR vì có thể phù hợp với việc sử dụng phân tích của bạn.

Một câu hỏi lớn là liệu bạn sẽ đọc toàn bộ raster từ tệp vào bộ nhớ trước khi xử lý nó hay liệu tệp có lớn đến mức bạn sẽ xử lý nó tăng dần hay xử lý một số tập hợp con của tệp tổng thể.

Nếu bạn sẽ tải tất cả vào bộ nhớ, thì bạn sẽ thực hiện hầu hết truy cập tuần tự và định dạng nhanh nhất sẽ là sự thay đổi giữa bộ nhớ đơn giản và bộ nhớ nén (tùy thuộc vào những thứ như CPU ​​của bạn nhanh như thế nào so với đĩa). Bất kỳ định dạng tệp nhị phân nào cũng có thể sẽ khá gần (ASCII sẽ chậm hơn).

Nếu bạn cần xử lý một tập hợp con của một tệp rất lớn, thì định dạng nhóm các tập hợp con bạn muốn gần nhau hơn có thể nhanh hơn - ví dụ: gạch hoặc định dạng có thể tính toán bù đắp. Đôi khi các cách tiếp cận không nén đạt được ở đây vì có thể không quan trọng để tính toán khi bất kỳ phần nào của hình ảnh nằm trong tệp, đặc biệt nếu bạn chỉ cần một phần của một hàng rất lớn, nhưng việc nén có thể được thực hiện theo kiểu chi tiết phù hợp với một số mô hình truy cập.

Xin lỗi, nhưng có lẽ bạn sẽ phải điểm chuẩn tùy thuộc vào mẫu truy cập của bạn, thay vì lấy một kích cỡ phù hợp với tất cả. Tất nhiên nó có thể không chỉ phụ thuộc vào định dạng tệp và các yếu tố trên mà còn phụ thuộc vào trình điều khiển cho định dạng đó và phần mềm của bạn.

Cách bạn nghĩ về các loại vấn đề này là về cách ứng dụng của bạn truy cập tệp của bạn, so với cách dữ liệu được trình bày trong tệp của bạn. Ý tưởng là nếu bạn có thể truy cập dữ liệu của mình một cách tuần tự, nó sẽ hiệu quả hơn nhiều so với việc bạn truy cập ngẫu nhiên.

GeoTIFF là một tập hợp các "hình ảnh" 2D hoặc mảng. NetCDF là một kho lưu trữ mục đích chung cho các mảng đa chiều. Nhưng nếu bạn lưu trữ các mảng theo cùng một cách trong netCDF giống như trong GeoTIFF, bạn sẽ nhận được hiệu suất tương tự, ít nhiều.

Người ta cũng có thể sắp xếp lại dữ liệu trong netCDF, vì vậy về nguyên tắc có thể tối ưu hóa cho các kiểu đọc của bạn. Tôi đoán là hầu hết các ứng dụng GIS đều được tối ưu hóa cho bố cục GeoTIFF 2D, do đó không có nhiều thứ để đạt được bằng cách sắp xếp lại.

Cuối cùng, Id nói rằng nó thực sự chỉ quan trọng khi bạn có các tệp rất lớn, ít nhất là hàng chục megabyte.

Tôi đã đọc một vài trang về điều này vài năm trước và kể từ đó đã sử dụng tiff với nén packbits, được lát gạch với tiêu đề geotiff, và đã rất vui.

bài viết nhóm arcpad

wiki

Nhưng sau khi đọc những điều sau đây, tôi sẽ xem xét lại và có thể sử dụng loại khử mỡ.

Trang web Arcpad

Vì vậy, nhiều gói sử dụng GDAL dưới mui xe, ví dụ: rgdal, QGIS, GRASS, v.v. Nếu tôi đang sử dụng một trong những gói đó, thì tôi sẽ nghĩ đến việc chuyển đổi hình ảnh của mình sang vrt. Tôi thường thấy rằng khi bạn cần sử dụng hai lệnh GDAL, thì tệp trung gian phải là tệp vrt vì chi phí đọc là tối thiểu (ví dụ: http://www.perrygeo.com/lazy-raster- Processing -với-gdal-vrts.html ). Có vẻ như quy trình làm việc của bạn là: chuyển đổi một lần và đọc nhiều lần. Có lẽ vrt sẽ thích hợp.

[Chỉnh sửa: điều chỉnh liên kết]