다양한 래스터 데이터 형식의 속도

25

다른 래스터 파일 형식에 대한 토론이나 비교 벤치마킹을 찾는 데 문제가 있습니다 (예 : R의 데이터 분석에 사용). 왜 특정 형식이 더 빠르거나 느린 지에 대한 통찰력이 있습니까? 아니면 차이가 최소화되어야합니까?

특히, 래스터 (예 : GEOTIFF 파일)를 다른 형식 (예 : netCDF)으로 변환하는 것이 읽기 / 쓰기 및 기타 작업 속도를 높이는 데 가치가 있는지에 관심이 있습니다.

— 성 조지
소스

2

이 질문은 GIS와 관련이 있지만 R 전문가의 하위 커뮤니티가 강한 SO에 대한 답변을 얻을 가능성이 더 높습니다. 신속하게 답변을받지 못한 경우이 질문에 플래그를 지정하면 중재자가 질문을 마이그레이션합니다.

— whuber

9

다음 은 파일 크기와 형식의 액세스 시간을 살펴 보는 오래된 블로그 기사 입니다. 쓰기 속도, 액세스 시간 만 조사하지 않았습니다. 나는 그들이 직접적으로 관련되어 있지만 그것을 보증 할 수는 없다고 말하고 싶습니다.

기사 요약 : Packbits는 디스크 공간을 희생시키면서 최상의 액세스 시간을 제공하는 반면, Deflate는 중간 / 작은 파일에 대한 중간 / 느린 액세스 시간을 제공합니다. 또한 다양한 크기의 썸네일을 만들고 시간이 얼마나 걸리는지를 통해 경험적으로 액세스 시간을 테스트 할 수 있습니다. 명령 예 :time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

이 경우 R과 관련이있는 유일한 방법은 다른 프로세스와 마찬가지로 파일에서 데이터를 얼마나 빨리 읽을 수 있는지를 가정하면 좋은 표시가 될 것입니다.

— R 티 에드
소스

링크 된 기사의 경우 +1이지만 중요한 정보는 오프 사이트에 있으며 해당 페이지가 다운되거나 이동하면 Google에 손실됩니다. 페이지를 사용할 수없는 경우 잠시라도 독자들이 미래의 연구와 생각을 위해 작업 할 무언가를 갖도록 기사의 요약 결론을 제시하는 것이 좋습니다. 감사!

— 매트 윌키

충분합니다! Packbits는 디스크 공간을 희생시키면서 최상의 액세스 시간을 제공하는 반면, Deflate는 중간 / 작은 파일에 대한 중간 / 느린 액세스 시간을 제공합니다. 또한 다양한 크기의 썸네일을 만들고 시간이 얼마나 걸리는지를 통해 경험적으로 액세스 시간을 테스트 할 수 있습니다. 명령 예 : "time gdal_translate -outsize <썸네일 크기> -of GTiff <압축 된 이미지 파일> <썸네일 파일>"

— R Thiede

1

감사! 요약을 답변 자체로 접었으므로 더 많이 포함되어 있습니다 (각 답변 / 질문의 왼쪽 하단에있는 편집 링크 참조).

— 매트 윌키

@RThiede는 유효한 관심사를 가지고있었습니다 : 이제 블로그 링크가 더 이상 유효하지 않은 것 같습니다.

— Matifou

@RThiede 귀하의 링크가 죽었습니다 새로운 링크를 제공 할 수 있습니까?

— Majid Hojati

6

들어 읽기 / 쓰기 작업, 당신은 system.time를 사용하는 작업의 속도를 테스트 할 수 있습니다 (). 다음은 4 가지 형식 (ASCII, IMG 및 TIF, 압축 및 수축 없음)으로 변환 된 R (래스터 패키지)로 DEM 파일을로드 한 결과입니다. 예를 들어 ~ 26MB 래스터에서 :

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

'경과'는 작업에 소요 된 총 시간 (초)을 제공합니다. 각 작업을 10 회 실행하고 평균 경과 시간을 확인합니다.

              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가 가장 빠릅니다. Deflate (0.1 % 느림) 및 TIFF-Packbits (1.8 % 느림), IMG (3.2 % 느림) 및 ASC (33 % 느림)가 매우 밀접하게 뒤 따릅니다. (이것은 SSD가 장착 된 Macbook Pro 2.4 GHz에 있으므로 빠른 디스크 작동)

이것은 단순히 파일을 조작하는 것이 아니라로드하는 것입니다.

— 심바 만구
소스

4

어쩌면 어떤 래스터 이미지 형식이 더 나은 오프닝 벤치 마크를 갖는지에 대한 질문이 아닐 수도 있습니다. 오히려 어떤 래스터 이미지 형식이 R 숫자 형 배열에 입력으로 열고 읽을 때 가장 효율적인 래스터 소스 형식입니다. 결과적으로 래스터로 결과를 다시 출력한다고 가정하면 R에서 가장 효율적인 출력 형식은 무엇입니까?

어느 쪽이든, R에서 래스터로 작업하려는 경우 rgdal 및 R ncdf 패키지를 사용하여 R 래스터 패키지에 포함 된 내용을 보완 할 수 있습니다. gdalwarp 명령 에 대한 주요 의존 . 래스터를 선택하려면 형식 종속성을 해결해야합니다. SO 및 다양한 OSGEO 및 R 포럼 / 블로그 / wiki에 대해 상당히 많은 정보를 제공합니다.

그러나 이것이 파이썬 사용이 상대적으로 우월한 GIS 포럼이므로 래스터 로딩, 변환 및 내보내기를 위해 gdal 라이브러리에 유사한 의존성을 가지고 파이썬 numpy 배열에서 래스터 데이터를 사용하는 이점이 있습니다. 일부 사람들은 파이썬에서 메모리 관리와 코드 구조가 네이티브 R보다 선호 된다는 것을 알고 있습니다. 아마도 분석 용도에 적합 할 수 있으므로 RPy2 또는 PypeR 을 살펴보십시오 .

— V 스튜어트 푸트
소스

R에서 netCDF 데이터 (래스터 소스 또는 기타)를 조작하는 경우 다음 두 개의 R CRAN 호스팅 netCDF 패키지 ( ncdf4-cran.r-project.org/web/packages/ncdf4/index.html 및 RNetCDF- cran

— V Stuart Foote

4

큰 문제는 파일을 처리하기 전에 파일에서 메모리로 전체 래스터를 읽을 것인지 또는 파일이 너무 커서 파일을 점진적으로 처리하거나 전체 파일의 일부를 처리 할 것인지 여부입니다.

메모리에 모두로드 할 경우 대부분 순차적 액세스를 수행하게되며 가장 빠른 형식은 CPU와 디스크의 속도와 같은 속도에 따라 일반 스토리지와 압축 스토리지 사이에서 발생합니다. 이진 파일 형식은 아마도 매우 비슷할 것입니다 (ASCII는 느려질 것입니다).

매우 큰 파일의 하위 집합을 처리해야하는 경우 타일 또는 오프셋을 계산할 수있는 형식과 같이 원하는 하위 집합을 그룹화하는 형식이 더 빠를 수 있습니다. 압축되지 않은 접근 방식은 특히 이미지의 특정 부분이 파일 내 어디에 있는지 계산하는 것이 쉽지 않기 때문에 여기에서 얻을 수 있습니다. 액세스 패턴.

죄송하지만, 한 번에 모든 것을 얻는 것이 아니라 액세스 패턴에 따라 벤치마킹해야 할 수도 있습니다. 파일 형식과 위의 요인뿐만 아니라 해당 형식의 드라이버 및 소프트웨어에 따라 달라질 수 있습니다.

— 제프
소스

2

이러한 종류의 문제에 대해 생각하는 방식은 응용 프로그램이 파일에 액세스하는 방식과 데이터가 파일에 배치되는 방식에 관한 것입니다. 아이디어는 데이터에 순차적으로 액세스 할 수 있으면 무작위로 액세스하는 것보다 훨씬 효율적이라는 것입니다.

GeoTIFF는 2D "이미지"또는 배열의 모음입니다. NetCDF는 다차원 어레이를위한 범용 스토리지입니다. 그러나 배열을 GeoTIFF와 동일한 방법으로 netCDF에 저장하면 동일한 성능을 얻을 수 있습니다.

netCDF에서 데이터를 재 배열 할 수 있으므로 원칙적으로 판독 패턴을 최적화 할 수 있습니다. 내 생각에 대부분의 GIS 응용 프로그램은 GeoTIFF 2D 레이아웃에 최적화되어 있으므로 다시 정렬하면 얻을 것이 많지 않습니다.

마지막으로, ID가 매우 큰 파일 (최소 수십 메가 바이트)이있는 경우에만 문제가된다고합니다.

— 존 카론
소스

무작위 액세스 또는 임의 위치의 읽기가 전체 파일이 읽힐 때까지 순차적 인 순서와 매우 다른 점에서 +1입니다. 나는 기본이 아닐 수도 있지만 Geotiff는 타일 저장 및 임의 액세스를 지원한다고 생각합니다. 스트립 / 행별로 가장 일반적이고 널리 지원됩니다. 또한 요즘에는 GIS에서 "매우 큰 파일"이 멀티 GB 범위에있는 경향이 있습니다. ;-)

— matt wilkie

2

나는 몇 년 전에 이것에 대해 몇 페이지를 읽었으며 그 후에 팩 비트 압축과 함께 tiff를 사용하고 geotiff 헤더로 바둑판 식으로 만들어서 행복했습니다.

아크 패드 팀 기사

위키

그러나 다음을 읽은 후에는 수축 변형을 재고하고 아마도 사용할 것입니다.

아크 패드 사이트

— 브래드 네섬
소스

2

rgdal, QGIS, GRASS 등과 같이 많은 패키지가 후드 아래에서 GDAL을 사용합니다. 패키지 중 하나를 사용하는 경우 이미지를 vrt로 변환하려고 생각합니다. 두 개의 GDAL 명령을 사용해야 할 때 읽기 오버 헤드가 최소이기 때문에 중간 파일이 vrt 파일이어야한다고 자주 보았습니다 (예 : http://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html ). 한 번 변환하고 여러 번 읽는 워크 플로처럼 들립니다. 아마도 vrt가 적절할 것입니다.

[편집 : 링크 조정]

— 사용자
소스