Як вирішити великий процес мозаїки, який не вдається?

Мені потрібно зробити мозаїку близько 550 Гб зображень tif разом, а програмне забезпечення, яке я спробував, не вдається. Площа була розбита на зони, так що найменша має близько 200 плиток.

Я використовував останні версії ERDAS (Imagine and Mapper), ArcINFO та Global Mapper на 3,30 гігагерцах Intel Xeon E31245, DELL, 16 ГБ оперативної пам’яті, 64-розрядний Win 7 Professional. Мулти-сердечник (4 усього), гіпер-різьбовий (8 усього) апарат. Мій C має 700 Гб безкоштовно, а D - 1,5 ТБ.

Я шукаю використання трави (ніколи раніше), але i.image.mosaic, здається, обробляє лише 4 файли ... деякі з моїх мають 600 плиток. Будь-які інші варіанти чи програмне забезпечення з відкритим кодом, щоб спробувати?

Вибачте, слід додати, що ми не можемо використовувати мозаїчний набір даних (або еквівалент в іншому програмному забезпеченні), оскільки нам потрібно створити зони з визначеними областями без даних як ecw, щоб їх можна було відкрити в будь-якому програмному забезпеченні ГІС та поєднати з меншою роздільною здатністю / старшою дані, коли нові дані існують непросто.

Приклад того, як деякі мозаїчні файли виглядають у різних програмних засобах. Глобальний Mapper / ERDAS є нормальним, але це не є правильним у аркгізі.

--- СТАРІША ІНФОРМАЦІЯ ---

Вибачте за чорновий малюнок. Тому використання кольорових областей як 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,5 ТБ + вільного місця на диску, але процес виходить з ладу з помилкою 9999.

Чи оброблять навіть 100 плиток? -Так ми повинні дивитись на розбиття зон далі?

Мені доведеться запропонувати другий @ blah238 пропозицій використовувати якийсь інший метод доступу до даних, ніж створення єдиного мозаїчного зображення. Простий здогад скаже, що там немає робочого столу, який би міг обробляти кількість даних, які вам доведеться обробити, щоб мозаїкувати всі ці плитки.
Щоб розбити це, напевно, є два місця, де вам не вистачає місця.

1. Перший буде знаходитись у вашому буфері оперативної пам’яті. Для того, щоб зробити мозаїчні дані, ви об’єднуєте все в один файл, а це означає, що в ідеалі весь цей файл був би в пам'яті. У вас немає 550 Гб оперативної пам’яті, це означає, що ви будете читати / записувати з віртуальної пам'яті. Цього достатньо для того, щоб зупинити процес саме там.
2. Інша проблема, ймовірно, буде на жорсткому диску. Багато растрових операцій створюють тимчасові файли у вашому каталозі "робочої області", які є досить великими. Їх може бути 2 або 3 або більше, перш ніж кінцевий набір даних навіть буде записаний, тому можливо обробити весь дисковий простір під час обробки.

Тепер про інші рішення. Як було сказано в коментарях вище, є можливість створити набір даних Mosaic . Цей набір даних дозволить вам не тільки розглядати всі окремі плитки як єдине безшовне зображення, але й підтримувати метадані про окремі плитки, що містяться всередині. Він також дозволяє виконувати растрові операції, такі як Гіллсхед .

Іншим варіантом, який я рекомендую, виходячи з вашого коментаря щодо того, щоб хотіли розділити зони, було б створити каталог растр . Каталог растрових по суті є груповим шаром. Ви можете додати до нього декілька растрових наборів даних. Ними можна керувати в базі даних геоданих та імпортувати растри, або просто створити некерований набір даних, де каталог растрових файлів підтримує шляхи до початкових наборів растрових даних. Завантажуючи цей шар в 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) розмір зображення
Якщо ваші оригінали 550 Гб не стиснуті, слід перетворити їх у стиснуті jpeg файли tiff. Зберігайте їх побічно (не злившись). Ви можете стискати, використовуючи arcgis, gdal, що завгодно. Стиснення призведе до близько 23 Гб. Ще не створюйте піраміди / огляди. Для стиснення ви можете використовувати будь-яку вподобану програму 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

Ви можете легко зробити файл bat, який проходить через усі ваші нестиснені тиффи. Мені подобається використовувати gdalwarp для стиснення зображень замість звичного gdal_translate, оскільки це швидше (використовуючи багатооборотні варіанти для багатоядерних і -wm для достатньої кількості пам'яті).

2) обробка як єдине зображення
Ви можете створити "віртуальну" мозаїку, використовуючи формат gdal vrt. Це сумісно з arcgis, qgis, mapserver і т. Д. Не впевнений у глобальному картографі та картографічній інформації. Формат .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. Коли ви збільшите масштаб до реальної роздільної здатності своїх зображень, то зчиснені зображення будуть прочитані лише декількома видимими зображеннями, і це теж дуже швидко.

5) обробка ділянок без даних, які відображаються чорним кольором. Для цього у
вас є три рішення: i) використовувати формат файлу, який обробляє нодатки, що буде складним; або ii) використовувати альфа-діапазон або iii) файл маски. Ви можете створити альфа-діапазон автоматично на кроці 2, сказавши GDAL, що ви хочете, щоб області нодатів були в альфа-діапазоні - ви просто додаєте параметр -addalpha:

gdalbuildvrt -addalpha nameofmosaic.vrt compressed_tif_folder\*.tif

Проблема з альфа-групами полягає в тому, що вони погано стискаються. Таким чином, ваші огляди будуть більшими. Якщо з вами все гаразд, тоді все закінчено.

Якщо ви хочете створити файл маски, то це трохи складніше. І я вважаю, що це не підходить до цього питання.

Тож сподіваємось, що це допомагає. Інформацію про інструменти gdal можна знайти за допомогою googling. Багато цікавого навколо.

550 Гб вхідних даних TIF легко обробляється одним файлом ECW. У нас багато клієнтів стискають значно більші набори даних, ніж це, тому, будь ласка, не думайте, що формат не здатний у цій галузі.

Ваша стратегія розділення проекту на невеликі плитки, щоб мінімізувати нульову площу, також є хорошим підходом до поточної версії формату, оскільки це скоротить час стиснення

Ваш приклад включає посилання на непідписані 16-бітні вхідні дані. Я порекомендую, якщо можливо, змінити значення до 8 біт (залежно від ваших вимог)

Поясніть, чому ви не змогли обробити ваш проект за допомогою IMAGINE або ERMapper, оскільки без цієї інформації я не можу вам допомогти. Або ще краще зв’язатися з місцевою командою підтримки

Зауважте, що, використовуючи формат набору даних мозаїки ESRI, у відповідях вище не згадується вимога генерувати рівень піраміди / огляду. Без цього продуктивність значно постраждає. Ймовірно, ви могли б створити еквівалентні файли ECW за той же час, але покращили якість зображення та значно менші вимоги до зберігання.

Хоча явно краще використовувати один із інших варіантів, ви можете спробувати наступне:

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

Це створює віртуальний формат GDAL, а потім конвертує в єдиний GeoTiff.

Мені це здається досить звичним, ми також виробляємо великі одиночні файли ECW з 500 теж 1 ТБ файлів TIF. Але я не хотів би останній на ArcGIS (ArcObjects та Geoprocessing Engine), оскільки він не в змозі надійно мозаїкувати цю суму. Якщо ви хочете залишитися у світі ESRI, я б рекомендував одразу нарізати мозаїчні шматки розміром приблизно 50 Гб або навіть меншим розміром набору даних Raster, що зберігається у базі даних Geodatabase. Інструмент мозаїки має тенденцію до виходу з ладу через деякий час, тож гарна ідея дозволить ArcGIS звільнити пам'ять після деяких GigaBytes.

Інша можливість - використовувати корпоративну або робочу групу SDE Geodatabase. За допомогою SDE ви отримуєте старомодні інструменти командного рядка SDE, які побудовані на надійній архітектурі C ++, окрім ненадійних матеріалів ArcObjects. За допомогою команди "sderaster -o mosaic ..." ви можете мозаїкувати RasterDataset, поки ваш накопичувач баз даних не заповниться. Також є команди для створення пірамід статистикою для RasterDataset, інакше це не дуже корисно, оскільки більшість клієнтів не можуть зберігати зображення в пам'яті під час читання, як зазначено вище blah238. Але Піраміди (насправді просторове індексування) повинні вирішити цю проблему.

Але ці рішення точно не допомагають вам з MapInfo. Ви згадали, що вже пробували ERDAS Mapper. Ось і інструмент, який я хотів би віддати перевагу. Ми вже мозаїкували 16000 файлів TIF, розміром кожного 50 Мб, які є 800 Гб. Потім ми стиснули його до однієї ECW із коефіцієнтом стиснення 1:20, що призвело до отримання ECW-файлу 30 Гб. Мені цікаво, що це для вас не працює ...

Принаймні весь процес працював на одному ядрі Pentium 4 1,6 ГГц з 2 ГБ оперативної пам’яті, тому апаратне забезпечення не повинно бути проблемою. Ми використовуємо Windows Server 2003 (або іншу серверну операційну систему), оскільки вона краще використовує програмні ресурси. Майте на увазі, що на весь процес стиснення потрібно багато часу. Наша машина працювала близько 5 тижнів над цим єдиним файлом, і тому що він іноді також виходив з ладу, нам довелося це робити кілька разів, але врешті-решт ми отримали наш файл ECW.

Я не знаю іншої системи чи механізму для зберігання великої кількості растратів, як правило, нейтральним для постачальників. Усі вищезазначені способи дуже специфічні для ESRI. Принаймні, з Oracle RASTER і досить схожою реалізацією в PostGIS, є два варіанти бази даних, які також не є нейтральними щодо постачальника, але відкриваються через інтерфейс SQL / MM.

Сподіваюсь, це трохи допомагає.