如何解决大型镶嵌过程失败的问题？

我需要将大约550Gb的tif图像拼接在一起，而我尝试过的软件始终会失败。该区域已划分为多个区域，因此最小的区域大约有200个图块。

我在3.30 GHz的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个文件……我的一些文件有600个图块。还有其他选择或开源软件可以尝试吗？

抱歉，我们不能使用镶嵌数据集（或其他软件中的等效数据），因为我们需要创建具有定义为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")

应该从csv文件中读取tifList的地方，但这在python中不起作用，因此我在模型中运行了以上内容...

我的驱动器上有1.5TB +的可用空间，但是该过程因9999错误而崩溃。

还要100块瓷砖吗？-ie我们应该考虑进一步划分区域吗？

我将不得不使用@ blah238的第二条建议，即使用其他一些数据访问方法来创建单个镶嵌图像。一个简单的猜测就是那里没有台式机可以处理为拼接所有这些图块而必须处理的数据量。
要分解它，可能有两个地方空间不足。

1. 第一个将在您的RAM缓冲区中。为了镶嵌数据，您将所有内容合并到一个文件中，这意味着理想情况下，整个文件都将保存在内存中。您没有550GB的RAM，这意味着将从虚拟内存中进行读取/写入。这足以使该过程立即崩溃。
2. 另一个问题可能是硬盘空间。许多栅格操作会在“工作区”目录中创建非常大的临时文件。甚至在写入最终数据集之前，可能有2或3个或更多，因此可以想象在处理过程中会耗尽所有磁盘空间。

现在，寻求其他解决方案。如以上注释中所述，可以选择创建Mosaic数据集。该数据集不仅使您可以将所有单个图块都视为一个无缝图像，而且还可以维护有关其中包含的单个图块的元数据。它还允许您执行栅格操作，例如Hillshade。

根据您对要分隔区域的评论，我建议的另一个选择是创建栅格目录。栅格目录本质上是一个组层。您可以向其中添加多个栅格数据集。可以在地理数据库中对其进行管理，并导入栅格，也可以简单地创建非托管数据集，其中“栅格目录”维护着原始栅格数据集的路径。将此图层加载到ArcMap中时，可以将显示属性设置为一次仅加载一定数量的栅格图块，也可以设置显示比例和分辨率。
我目前正在使用栅格目录来平铺100 + GB的航空照片集。表现非常好。如果您正在寻找仅用于管理大量切片的另一种类型的数据存储，那么我真的建议您。

这是可用于创建栅格目录，然后将切片的工作空间导入其中的代码：

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文件。我喜欢使用gdalwarp而不是通常的gdal_translate来压缩我的图像，因为它速度更快（对多核使用多选项，对大量内存使用-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等1个文件中的概述。当您放大图像的真实分辨率时，将仅读取压缩图像中的一些可见图像，这确实非常快。

5）处理没有数据的区域显示黑色
您有3种解决方案：i）使用处理nodata的文件格式，这将很复杂；或ii）使用Alpha波段或iii）遮罩文件。您可以通过告诉GDAL您希望nodata区域位于alpha波段中，在步骤2中自动创建一个alpha波段-您只需添加选项-addalpha即可：

gdalbuildvrt -addalpha nameofmosaic.vrt compressed_tif_folder\*.tif

Alpha波段的问题在于它们的压缩效果很差。因此，您的概述将会更大。如果您认为可以，那么您就完成了。

如果要创建遮罩文件，则要复杂一些。而且我发现这不适合当前的问题。

因此希望对您有所帮助。您可以通过谷歌搜索找到有关gdal工具的信息。周围有很多有趣的东西。

单个ECW文件可轻松处理550gb的输入TIF数据。我们有很多客户在压缩比这更大的数据集，所以请不要认为该格式在该领域不可行。

您将项目分成小块以最小化空区域的策略也是采用当前格式版本的一种好方法，因为它将减少压缩时间

您的示例包括对无符号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。

这听起来对我来说很熟悉，我们还从500个太1TB的TIF文件中生成大型的单个ECW文件。但是我不会最后使用ArcGIS（ArcObjects和Geoprocessing Engine），因为它不能以可靠的方式镶嵌此数量。如果您想留在ESRI世界中，建议您一次将大约50 GB甚至更小的镶嵌块镶嵌到文件地理数据库中存储的栅格数据集。镶嵌工具会在一段时间后崩溃，因此最好让ArcGIS在几G字节后释放内存。

另一种可能性是使用企业或工作组SDE地理数据库。使用SDE，您可以获得老式的SDE命令行工具，该工具基于不可靠的ArcObjects组件以外的强大C ++体系结构构建。使用“ sderaster -o mosaic ...”命令，可以镶嵌到RasterDataset，直到数据库存储已满。也有一些命令可以为RasterDataset建立金字塔统计信息，否则它不是非常有用，因为如上所述，大多数客户端在读取图像时都无法将图像保存在内存中。但是金字塔（实际上是空间索引）应该可以解决此问题。

但是这些解决方案肯定不能帮助您使用MapInfo。您提到您已经尝试过ERDAS Mapper。那也是我偏爱的工具。我们已经拼接了16000个TIF文件，每个文件的大小为50 MB，即800GB，然后我们以1:20的压缩率将其压缩为单个ECW，从而生成了30GB的ECW文件。我想知道这对您不起作用...

至少整个过程是在具有2 GB RAM的单核Pentium 4 1,6 GHz上运行的，因此硬件应该不是问题。我们使用Windows Server 2003（或其他服务器操作系统）是因为它更好地利用了硬件资源。请记住，整个压缩过程需要很多时间。我们的机器在单个文件上工作了大约5周，因为有时它也崩溃了，所以我们不得不这样做几次，但最终我们得到了ECW文件。

我不知道另一种以供应商中立的方式存储大量栅格的系统或机制。上面提到的所有方式都是ESRI特有的。至少对于Oracle RASTER和PostGIS中的一个非常类似的实现，有两个数据库化的Variants，它们也是与供应商无关的，而是通过SQL / MM接口打开的。

希望这会有所帮助。