실패하는 큰 모자이크 프로세스를 해결하는 방법은 무엇입니까?

약 550Gb의 tif 이미지를 모자이크로 만들어야하고 시도한 소프트웨어가 계속 실패합니다. 가장 작은 타일은 약 200 개의 타일을 갖도록 영역이 구역으로 분할되었습니다.

3.30 기가 헤르츠 Intel Xeon E31245, DELL, 16GB RAM, 64 비트 Win 7 Professional에서 최신 버전의 ERDAS (Imagine and Mapper), ArcINFO 및 Global Mapper를 사용했습니다. 멀티 코어 (총 4 개), 하이퍼 스레드 (총 8 개) 시스템. 내 C에는 700GB의 여유 공간이 있고 D에는 1.5TB의 여유 공간이 있습니다.

나는 Grass를 사용하려고 노력하고 있지만 (이전에는 없었 음) i.image.mosaic은 4 파일 만 처리하는 것 같습니다 ... 일부 600 타일이 있습니다. 다른 옵션이나 오픈 소스 소프트웨어를 사용해보십시오.

데이터가없는 영역을 ecw로 정의한 영역을 생성해야하므로 모자이크 데이터 셋 (또는 다른 소프트웨어와 동등한 소프트웨어)을 사용할 수 없습니다 .GIS 소프트웨어에서 열 수 있고 저해상도 / 이전 버전과 결합 할 수 있습니다. 새로운 데이터가 완벽하게 존재하지 않을 때의 데이터.

일부 모자이크 파일이 다른 소프트웨어에서 어떻게 보이는지에 대한 예. Global Mapper / ERDAS는 훌륭하지만 arcgis에서는 정확하지 않습니다.

--- 주문 정보 ---

거친 그림으로 죄송합니다. 따라서 색상 영역을 5 개 영역으로 지정하면 더 큰 AOI에서 데이터 영역이 최소화됩니다.

arcgis에서 코드는 다음과 같습니다 (이것은 tifList 입력을 취할 수 없기 때문에 파이썬이 아닌 모델로 실행됩니다).

arcpy.MosaicToNewRaster_management(tifList+";" +mask,RootOutput,"Tile1.tif","PROJCS['GDA_1994_MGA_Zone_55',GEOGCS['GCS_GDA_1994',DATUM['D_GDA_1994',SPHEROID['GRS_1980',6378137.0,298.257222101]],PRIMEM['Greenwich',0.0],UNIT['Degree',0.0174532925199433]],PROJECTION['Transverse_Mercator'],PARAMETER['False_Easting',500000.0],PARAMETER['False_Northing',10000000.0],PARAMETER['Central_Meridian',147.0],PARAMETER['Scale_Factor',0.9996],PARAMETER['Latitude_Of_Origin',0.0],UNIT['Meter',1.0]]","16_BIT_UNSIGNED","0.5","3","MAXIMUM","#")

# Replace a layer/table view name with a path to a dataset (which can be a layer file) or create the layer/table view within the script
# The following inputs are layers or table views: "test2"

arcpy.CopyRaster_management(OutputFile,RootOutput+"Tile1b.tif","#","256","256","NONE","NONE","16_BIT_UNSIGNED")

csv 파일에서 tifList를 읽어야하지만 파이썬에서는 작동하지 않으므로 위의 모델을 대신 실행합니다 ...

드라이브에 1.5TB 이상의 여유 공간이 있지만 프로세스가 9999 오류로 충돌합니다.

100 개의 타일도 처리됩니까? -영역을 더 세분화해야합니까?

모자이크로 된 단일 이미지를 만드는 것보다 다른 데이터 액세스 방법을 사용하는 @ blah238의 제안을 두 번째로해야합니다. 간단한 추측에 따르면 모든 타일을 모자이크 처리하기 위해 처리 해야하는 데이터 양을 처리 할 수있는 데스크탑이 없습니다.
이를 정리하기 위해 공간이 부족한 두 곳이있을 수 있습니다.

1. 첫 번째는 RAM 버퍼에 있습니다. 데이터를 모자이크 처리하기 위해 모든 것을 단일 파일로 병합하는 것이 이상적입니다. 즉, 전체 파일이 메모리에 보관되는 것이 이상적입니다. 550GB의 RAM이 없으므로 가상 메모리에서 읽고 쓸 수 있습니다. 그것은 프로세스를 바로 중단하기에 충분합니다.
2. 다른 문제는 하드 디스크 공간 일 수 있습니다. 많은 래스터 작업은 "작업 공간"디렉토리에 상당히 큰 임시 파일을 만듭니다. 최종 데이터 세트를 작성하기 전에 이들 중 2 개 또는 3 개 이상이있을 수 있으므로 처리 중에 모든 디스크 공간을 모두 사용할 수 있습니다.

이제 다른 솔루션의 경우 위의 주석에서 언급했듯이 Mosaic Dataset 을 만드는 옵션이 있습니다 . 이 데이터 세트를 사용하면 모든 개별 타일을 하나의 완벽한 이미지로 취급 할 수있을뿐만 아니라 그 안에 포함 된 개별 타일에 대한 메타 데이터도 유지할 수 있습니다. Hillshade 와 같은 래스터 작업을 수행 할 수도 있습니다 .

영역을 분리하고 싶다는 의견에 따라 권장하는 다른 옵션은 Raster Catalog 를 만드는 것 입니다. 래스터 카탈로그는 기본적으로 그룹 레이어입니다. 여러 래스터 데이터 세트를 추가 할 수 있습니다. 지리 데이터베이스에서 관리하고 래스터를 가져 오거나 래스터 카탈로그가 원래 래스터 데이터 세트의 경로를 유지하는 관리되지 않는 데이터 세트를 만들 수 있습니다. 이 레이어를 ArcMap에로드 할 때 한 번에 특정 수의 래스터 타일에만로드하도록 디스플레이 속성을 설정하거나 디스플레이 배율 및 해상도를 설정할 수 있습니다.
현재 래스터 카탈로그를 사용하여 100GB 이상의 항공 사진을 바둑판 식으로 배열하고 있습니다. 성능이 매우 좋습니다. 많은 수의 타일을 관리하는 수단으로 다른 유형의 데이터 스토리지를 찾고 있다면 실제로 권장합니다.

다음은 래스터 카탈로그 를 생성 한 다음 타일 ​​작업 공간 을 가져 오는 데 사용할 수있는 코드입니다 .

import arcpy
import os

newdir = r"c:\data"
dbname = "Aerialphotos.gdb"
gdbdir = os.path.join(newdir, dbname)
rcat = "AerialCatalog"

arcpy.CreateRasterCatalog_management(gdbdir, rcat,
                                     "NAD 1983 StatePlane California VI FIPS 0406 (US Feet).prj", 
                                     "NAD 1983 StatePlane California VI FIPS 0406 (US Feet).prj",
                                     "MAX_FILE_SIZE_4GB", "1000", "3000", "9000",
                                     "UNMANAGED", "")

#Load all raster datasets in workspace to Raster Catalog
rcatdir = os.path.join(gdbdir, rcat)
rastertiledir = os.path.join(newdir, "tiles")

arcpy.WorkspaceToRasterCatalog_management(rastertiledir, rcatdir,
                                          "INCLUDE_SUBDIRECTORIES",
                                          "PROJECT_ONFLY")

도움이 되었기를 바랍니다!

------------- 편집하다

다음은 래스터 카탈로그에서 처리 한 타일의 그래픽입니다. 와이어 프레임 또는 래스터 데이터를 표시하도록 선택할 수 있습니다. 래스터 카탈로그에는 그래픽과 같이 영역 지정을 추가하려는 경우 필드를 추가 할 수있는 속성 테이블이 있습니다. 그런 다음 특정 영역에 해당 래스터 만 표시하도록 선택할 수 있습니다.
레이아웃보기에서 그래픽으로 인쇄 할 때는 래스터의 전체 해상도가 사용되므로 인쇄 품질이 저하되지 않습니다.

다음은 동일한 그래픽이지만 일부 와이어 프레임과 함께 일부 래스터 데이터를 보여줍니다.

나는 파티에 늦었다는 것을 안다. 그러나 여기 내 제안이 있습니다.

1) 이미지 크기
550GB 원본이 압축되지 않은 경우 jpeg 압축 tiff 파일로 변환해야합니다. 개별적으로 (병합되지 않은) 유지하십시오. arcgis, gdal 등 원하는대로 압축 할 수 있습니다. 압축하면 약 23GB가됩니다. 아직 피라미드 / 개요를 만들지 마십시오. 압축하려면 원하는 gis 프로그램을 사용할 수 있지만 gdal을 사용하는 것이 좋으므로 명령은 기본적으로 다음과 같습니다.

gdalwarp -multi -wm 512 --config  GDAL_CACHEMAX 512 -co compress=jpeg -co tiled=yes -co jpeg_quality=70 -co PHOTOMETRIC=YCBCR -co INTERLEAVE=PIXEL uncompressed.tif compressed.tif

압축되지 않은 모든 스티프를 통과하는 박쥐 파일을 쉽게 만들 수 있습니다. 나는 gdalwarp을 사용하여 일반적인 gdal_translate 대신 이미지를 압축하는 것을 좋아합니다. 왜냐하면 속도가 빠르기 때문입니다 (멀티 코어의 경우 multi 옵션을 사용하고 메모리가 많은 경우 -wm 사용).

2) 단일 이미지로 처리
gdal vrt 형식을 사용하여 "가상"모자이크를 만들 수 있습니다. 이것은 arcgis, qgis, mapserver 등과 호환됩니다. 전역 맵퍼 및 mapinfo에 대해 잘 모르겠습니다. .vrt 형식은 이미지를 나열하는 단일 xml 파일입니다. 그것은 하나의 명령입니다.

gdalbuildvrt nameofmosaic.vrt compressed_tif_folder\*.tif

이 파일의 크기는 몇 kb입니다.

3) 시각화 가속화
피라미드 / 개요를 만들어야합니다. 이를 위해 선호하는 소프트웨어를 사용하십시오. gdal 도구를 사용하여 다음을 수행 할 수 있습니다.

gdaladdo -ro -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 70 nameofmosaic.vrt 2 4 8 16 32 64 128

시간이 오래 걸릴 것입니다. 2 ~ 3 일의 논스톱 처리를 기다릴 준비를하십시오.

4) 모자이크 사용
gis 프로그램에서 가상 모자이크를로드하십시오. ecw와 같은 파일 하나에있는 개요를 읽고 있기 때문에 빠릅니다. 이미지의 실제 해상도로 확대하면 압축 된 이미지에서 보이는 소수의 이미지 만 읽을 수 있으며 실제로도 빠릅니다.

5) 검은 색으로 표시되는 비 데이터 영역 처리 이에 대한
3 가지 솔루션이 있습니다. i) 데이터를 처리하지 않는 파일 형식을 사용하면 복잡 할 수 있습니다. 또는 ii) 알파 밴드를 사용하거나 iii) 마스크 파일. 2 단계에서 GDAL에 알파 영역에 데이터 영역이 없도록하려면 -addalpha 옵션 만 추가하면 알파 밴드를 자동으로 만들 수 있습니다.

gdalbuildvrt -addalpha nameofmosaic.vrt compressed_tif_folder\*.tif

알파 밴드의 문제는 압축이 심하다는 것입니다. 그래서 당신의 개요는 더 커질 것입니다. 그래도 괜찮다면 끝났습니다.

마스크 파일을 만들려면 조금 더 복잡합니다. 그리고 이것이 현재 질문에 맞지 않는다는 것을 알았습니다.

이것이 도움이되기를 바랍니다. 인터넷 검색을 통해 gdal 도구에 대한 정보를 찾을 수 있습니다. 주변에 많은 흥미로운 것들.

550gb의 입력 TIF 데이터는 단일 ECW 파일로 쉽게 처리됩니다. 우리는 이보다 훨씬 더 큰 데이터 세트를 압축하는 고객이 많으므로이 영역에서는 형식을 사용할 수 없다고 생각하지 마십시오.

널 영역을 최소화하기 위해 프로젝트를 작은 타일로 나누는 전략은 압축 시간을 줄이므로 현재 형식 버전을 사용하는 좋은 방법입니다.

예제에는 부호없는 16 비트 입력 데이터에 대한 참조가 포함됩니다. 가능하면 8 비트로 조정하는 것이 좋습니다 (요구 사항에 따라 다름)

IMAGINE 또는 ERMapper를 사용하여 프로젝트를 처리 할 수없는 이유에 대해 자세히 설명해주십시오.이 정보가 없으면 도와 드릴 수 없습니다. 또는 현지 지원팀에 문의하십시오.

ESRI Mosaic 데이터 셋 형식을 사용함으로써 위의 답변에서 언급하지 않은 것은 피라미드 / 개요 레이어를 생성해야한다는 것입니다. 그렇지 않으면 성능이 상당히 저하됩니다. 동일한 시간에 ECW 동등한 파일을 작성할 수 있지만 이미지 품질이 향상되고 출력 스토리지 요구 사항이 크게 줄어 듭니다.

언급 된 다른 옵션 중 하나를 사용하는 것이 더 낫지 만 다음을 시도해 볼 수 있습니다.

gdalbuildvrt index.vrt *.tif
gdal_translate -of "GTiff" -co "COMPRESS=LZW" -co "TILED=YES" -co "BIGTIFF=YES" index.vrt out.tif

이렇게하면 GDAL 가상 형식이 만들어진 다음 단일 GeoTiff로 변환됩니다.

저에게도 매우 친숙하게 들리지만 500TB 중 1TB의 TIF 파일 중 큰 단일 ECW 파일도 생성합니다. 그러나 ArcGIS (ArcObjects 및 Geoprocessing Engine)에서는 신뢰할 수있는 방식 으로이 양을 모자이크 할 수 없기 때문에 마지막으로하지 않았습니다. ESRI World에 머 무르려면 한 번에 약 50GB 이하의 청크를 파일 지오 데이터베이스에 저장된 래스터 데이터 세트로 모자이크하는 것이 좋습니다. 모자이크 도구는 잠시 후에 충돌하는 경향이 있으므로 ArcGIS가 일부 기가 바이트 후에 메모리를 비우는 것이 좋습니다.

또 다른 가능성은 Enterprise 또는 Workgroup SDE 지오 데이터베이스를 사용하는 것입니다. SDE를 사용하면 신뢰할 수없는 ArcObjects 이외의 다른 강력한 C ++ 아키텍처에 구축 된 구식 SDE 명령 줄 도구를 사용할 수 있습니다. "sderaster -o mosaic ..."명령을 사용하면 데이터베이스 저장소가 가득 찰 때까지 RasterDataset으로 모자이크 할 수 있습니다. 피라미드를 RasterDataset에 대한 통계를 작성하는 명령도 있습니다. 그렇지 않으면 위에서 언급 한 blah238과 같이 대부분의 클라이언트가 이미지를 읽을 때 메모리에 이미지를 저장할 수 없기 때문에별로 유용하지 않습니다. 그러나 피라미드 (실제로 공간 인덱싱)는이 문제를 해결해야합니다.

그러나 이러한 솔루션은 MapInfo에 도움이되지 않습니다. ERDAS Mapper를 이미 시도했다고 언급했습니다. 그것은 또한 내가 선호하는 도구입니다. 크기는 각각 50MB, 800GB 인 16000 개의 TIF 파일을 모자이크 처리 한 후 압축 비율이 1:20 인 단일 ECW로 압축하여 30GB ECW 파일을 생성했습니다. 이것이 당신을 위해 작동하지 않는 것이 궁금합니다 ...

적어도 전체 프로세스는 2GB RAM의 단일 코어 Pentium 4 1,6 GHz에서 실행되었으므로 하드웨어에 문제가 없어야합니다. 우리는 Windows Server 2003 (또는 다른 서버 운영 체제)을 사용하고 있습니다. 하웨어 리소스를 더 잘 사용하기 때문입니다. 전체 압축 프로세스에는 많은 시간이 필요합니다. 우리 기계는 그 단일 파일에서 약 5 주간 작업을했으며 때로는 충돌했기 때문에이 작업을 여러 번 수행해야했지만 결국 ECW 파일을 얻었습니다.

나는 대부분의 벤더 중립적 인 방식으로 많은 양의 래스터를 저장하는 다른 시스템이나 메커니즘을 모릅니다. 위에서 언급 한 방법은 모두 ESRI에 따라 다릅니다. 최소한 Oracle RASTER와 PostGIS의 비슷한 구현에는 벤더 중립적이지 않지만 SQL / MM 인터페이스를 통해 열리는 두 가지 데이터베이스 변형이 있습니다.

이것이 조금 도움이되기를 바랍니다.