失敗している大規模なモザイクプロセスを回避するにはどうすればよいですか？

約550Gbのtif画像をモザイク化する必要があり、試したソフトウェアが失敗し続けます。領域はゾーンに分割されているため、最小のタイルは約200タイルです。

3.30ギガヘルツIntel Xeon E31245、DELL、16GB RAM、64ビットWin 7 ProfessionalでERDAS（ImagineおよびMapper）、ArcINFO、およびGlobal Mapperの最新バージョンを使用しました。マルチコア（合計4）、ハイパースレッド（合計8）マシン。私のCには700GBの空き容量があり、Dには1.5TBがあります。

Grassの使用を検討しています（以前はありません）が、i.image.mosaicは4つのファイルしか処理していないようです。他に試してみるオプションやオープンソースソフトウェアはありますか？

申し訳ありませんが、モザイクデータセット（または他のソフトウェアの同等物）は使用できません。ecwとして定義されたデータなしの領域を持つゾーンを作成し、任意のGISソフトウェアで開き、より低い解像度/古い新しいデータがシームレスに存在しない場合のデータ。

モザイク化されたファイルが異なるソフトウェアでどのように見えるかの例。Global Mapper / ERDASは問題ありませんが、arcgisでは正しくありません。

---旧情報---

ラフな描画でごめんなさい。したがって、5つのゾーンとして色付きの領域を使用すると、より大きなAOIでデータ領域がなくなります。

arcgisのコードは次のとおりです（これはモデルとして実行され、Pythonではなく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")

tifListはcsvファイルから読み込む必要がありますが、これはPythonでは機能しませんでしたので、代わりにモデルで上記を実行しています...

ドライブに1.5TB以上の空き容量がありますが、プロセスは9999エラーでクラッシュします。

100タイルでも処理できますか？-つまり、ゾーンをさらに分割する必要がありますか？

単一のモザイク画像を作成する以外のデータアクセス方法を使用するという2番目の@ blah238の提案が必要になります。単純な推測では、すべてのタイルをモザイク化するために処理しなければならないデータ量を処理できるデスクトップは存在しないと言えます。
それを分解するために、おそらくあなたがスペースを使い果たしている2つの場所があります。

1. 1つ目はRAMバッファーにあります。データをモザイク化するには、すべてを単一のファイルにマージします。つまり、理想的には、ファイル全体がメモリに保持されます。550GBのRAMがないため、仮想メモリから読み取り/書き込みができます。これでプロセスがクラッシュします。
2. もう1つの問題は、ハードディスクの空き容量です。ラスター操作の多くは、「ワークスペース」ディレクトリに非常に大きな一時ファイルを作成します。最終的なデータセットが書き込まれる前に、これらの2つまたは3つ以上が存在する可能性があるため、処理中にすべてのディスク領域を使い果たすことが考えられます。

さて、他のソリューションのために。上記のコメントで述べたように、Mosaic Datasetを作成するオプションがあります。このデータセットを使用すると、個々のタイルすべてを単一のシームレスなイメージとして扱うことができるだけでなく、含まれる個々のタイルに関するメタデータも保持できます。また、Hillshadeなどのラスター操作を実行できます。

ゾーンを分離したいというあなたのコメントに基づいて、私が推奨する他のオプションは、ラスタカタログを作成することです。ラスターカタログは、本質的にグループレイヤーです。複数のラスターデータセットを追加できます。ジオデータベースで管理し、ラスターをインポートするか、ラスターカタログが元のラスターデータセットへのパスを維持する非管理データセットを作成するだけです。このレイヤーをArcMapに読み込むとき、特定の数のラスタタイルのみを一度に読み込むように表示プロパティを設定したり、表示縮尺と解像度を設定したりできます。
現在、ラスタカタログを使用して、100ギガバイト以上の航空写真セットを並べています。性能はとても良いです。大量のタイルを管理するためだけに異なるタイプのデータストレージを探している場合は、本当にお勧めします。

ラスターカタログを作成し、タイルのワークスペースをインポートするために使用できるコードを次に示します。

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

すべての非圧縮TIFFを通過するbatファイルを簡単に作成できます。私は、通常のgdal_translateではなくgdalwarpを使用して画像を圧縮するのが好きです。

2）単一の画像として扱う
gdal vrt形式を使用して「仮想」モザイクを作成できます。これは、arcgis、qgis、mapserverなどと互換性があります。グローバルマッパーとmapinfoについてはわかりません。.vrt形式は、画像をリストした単一のxmlファイルです。これは、作成する単一のコマンドです。

gdalbuildvrt nameofmosaic.vrt compressed_tif_folder\*.tif

このファイルのサイズは数キロバイトです。

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のように1ファイルだけの概要を読み取るため、高速になります。画像の実際の解像度にズームインすると、圧縮された画像から目に見えるものだけが読み取られますが、これも非常に高速です。

5）黒を表示するデータなし領域の処理
これには3つの解決策があります。i）nodataを処理するファイル形式を使用します。これは複雑になります。またはii）アルファバンドを使用するか、iii）マスクファイルを使用します。アルファバンドにnodataエリアを含めることをGDALに指示することにより、ステップ2でアルファバンドを自動的に作成できます-オプション-addalphaを追加するだけです：

gdalbuildvrt -addalpha nameofmosaic.vrt compressed_tif_folder\*.tif

アルファバンドの問題は、アルファバンドの圧縮が悪いことです。したがって、オーバービューはより大きくなります。それでよければ、それで終わりです。

マスクファイルを作成する場合は、もう少し複雑です。そして、これは現在の質問には収まらないと思います。

これが役立つことを願っています。グーグルでgdalツールに関する情報を見つけることができます。たくさんの興味深いものがあります。

550GBの入力TIFデータは、単一のECWファイルで簡単に処理できます。これよりもはるかに大きなデータセットを圧縮している多くの顧客がいるので、この領域でフォーマットが機能しないとは思わないでください。

プロジェクトを小さなタイルに分割してヌル領域を最小限に抑える戦略も、圧縮時間を短縮するため、現在のフォーマットバージョンで使用するのに適したアプローチです。

例には、符号なし16ビット入力データへの参照が含まれています。可能な場合は8ビットに再スケーリングすることをお勧めします（要件に応じて）

IMAGINEまたはERMapperを使用してプロジェクトを処理できなかった理由について詳しく説明してください。この情報がないと、私はお手伝いできません。または、ローカルサポートチームにお問い合わせください

ESRI Mosaic Dataset形式を使用することにより、上記の回答で言及されていないのは、ピラミッド/オーバービューレイヤーを生成するための要件であることに注意してください。それなしでは、パフォーマンスはかなり低下します。ECWと同等のファイルを同じ時間で作成できますが、画質が向上し、出力ストレージ要件が大幅に小さくなります。

言及されている他のオプションのいずれかを使用する方が明らかに優れていますが、以下を試すことができます。

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

これにより、GDAL仮想フォーマットが構築され、単一のGeoTiffに変換されます。

それは私にはかなり馴染みがありますが、1TBのTIFファイル500個から大きな単一のECWファイルも作成します。しかし、ArcGIS（ArcObjectsとジオプロセシングエンジン）には長続きしません。信頼できる方法でこの量をモザイク化できないからです。ESRIの世界に滞在したい場合は、ファイルジオデータベースに保存されているラスターデータセットに約50 GBまたはそれ以下のチャンクを一度にモザイク化することをお勧めします。モザイクツールはしばらくするとクラッシュする傾向があるため、GigaBytesの後にArcGISがメモリを解放できるようにすることをお勧めします。

別の可能性は、エンタープライズまたはワークグループSDEジオデータベースを使用することです。SDEを使用すると、信頼性の低いArcObjectsのもの以外の堅牢なC ++アーキテクチャ上に構築された、旧式のSDEコマンドラインツールを取得できます。「sderaster -o mosaic ...」コマンドを使用すると、データベースストアがいっぱいになるまでRasterDatasetにモザイクできます。上記のblah238のように、ピラミッドを構築してRasterDatasetの統計情報を作成するコマンドもあります。そうしないと、ほとんどのクライアントが画像を読み取るときにメモリに画像を保持できません。しかし、ピラミッド（実際には空間インデックス付け）がこの問題を解決するはずです。

しかし、これらのソリューションは、MapInfoを確実に支援するものではありません。あなたはすでにERDAS Mapperを試したことがあると言いました。それも私が好むツールです。既にサイズがそれぞれ50 MBの800 GBの16000 TIFファイルをモザイク化し、1：20の圧縮率で1つのECWに圧縮した結果、30 GBのECWファイルになりました。これはあなたのために働いていないのだろうか...

少なくともプロセス全体が、2 GB RAMを備えたシングルコアPentium 4 1,6 GHzで実行されていたため、ハードウェアは問題になりません。Windows Server 2003（または別のサーバーオペレーティングシステム）を使用しているのは、Harwareリソースをより適切に使用しているためです。圧縮プロセス全体に多くの時間が必要であることを忘れないでください。私たちのマシンはその単一のファイルで約5週間動作していました。クラッシュすることもあったため、これを数回行う必要がありましたが、最終的にECWファイルを取得しました。

大量のラスターをほとんどベンダーに依存しない方法で保存する別のシステムまたはメカニズムを知りません。上記の方法はすべて、ESRI固有のものです。少なくともOracle RASTERとPostGISの非常に類似した実装では、2つのデータベース化されたバリアントがあります。これらは、ベンダーに中立ではなく、SQL / MMインターフェイスを通じて開かれます。

これが少し役立つことを願っています。