重要なのは、Windowsエクスプローラーが単一のファイルを処理する方法と、ArcCatalog / ArcGISがラスターを処理する方法の違いだと思います。ここにはいくつかの要因があります。
ファイルGDB形式では、ラスターは単一のファイルで表されません。データテーブルと、おそらくピラミッドとインデックスで構成されています。これが重要なのは、ArcCatalogがラスターをコピーするときに、最初にこれらの個別のファイルをすべてラスターとして表示されるものに結合するためです。次に、ArcGISプログラミングレイヤーを介して実行し、新しいファイルGDBにコピーします。これは、プログラミングの追加レイヤーであるため、Windowsシステムリソースを使用してファイルをコピーするよりも、表面上ははるかに複雑です。
次の部分は、ArcCatalogで別のフィーチャクラスをコピーしたときに表示されるものに関連しています。ArcCatalogにコピーして貼り付けると、元のフィーチャクラスとターゲットフィーチャクラスを示す進行状況ウィンドウが表示され、転送されたフィーチャの数をカウントするイテレータが表示されます。これは、フィーチャクラスを通じて行ごとに反復していることを示しています。これは、データの整合性の観点からは、各機能がコピーされ、次の機能に進む前に検証されるため、理にかなっています。これがラスターに関連するのは、ラスターが数千ではないにしても数百のポイントで構成されるということです。ラスターデータセットがベクターフィーチャクラスと同じ方法でコピーされる場合、ArcCatalogは基本的にラスター内の各座標ペアを反復処理して、ある座標ペアから別の座標ペアにコピーします。
最後の要素はデータセットのサイズです。あなたの場合、表示しているファイルGDBには20,671,104 KBのテーブルがあり、これは最大20GBです。これは大きなRasterで、間違いなく何百万ものポイントが含まれています。これは、繰り返し処理する多くの座標ペアです。
ラスターデータセットのサイズを組み合わせて、各行（座標ペア）を反復処理する必要があり、それをすべてArcGISプログラミングレイヤーで実行すると、単一のコピーよりもはるかに複雑で時間がかかる操作になりますWindowsシステム関数を使用してファイル。
-------編集
ファイルジオデータベース間でラスターをコピーするためのより高速な方法に関する元の質問に答えるために、私が試す1つのことは、arcpyを呼び出すpythonスクリプトを記述することです。その後、追加のArcCatalog / ArcMapコードを実行せずにAPIを直接操作するため、わずかに高速になる場合があります。コードサンプルは次のとおりです。
import arcpy
from arcpy import env
env.workspace = "C:/data"
arcpy.Copy_management("olddata.gdb/raster1", "newdata.gdb/raster1")
速度の違いが顕著かどうかはわかりませんが、それはオプションです。
@ blah238が参照するもう1つのオプションは、ラスタをファイルジオデータベースに格納するのではなく、「geotiff」やArcINFOグリッドなどのファイルベースの形式で格納することです。これにより、ファイルをWindowsのインターフェイスから完全に操作できます。 。
残念ながら、これ以外に、ArcGISインターフェイスの外部でファイルジオデータベースを操作するためのオプションは限られています。プログラマーがさまざまなソフトウェアでそれとやり取りできるようにするFile GDBのAPIがあります。現在の1つの例は、GDAL / OGRライブラリ、および間もなく、Quantum GISです。APIの問題は、現時点ではラスターデータセットをサポートしていないことです。これがあなたが主張したいものである場合は、ArcGIS Ideasサイトのこのエントリにサポートを追加します。
