Jak obejść duży proces mozaiki, który się nie udaje?

Muszę połączyć razem około 550 GB zdjęć w formacie tif, a oprogramowanie, które wypróbowałem, zawiesza się. Obszar został podzielony na strefy, dzięki czemu najmniejszy ma około 200 płytek.

Korzystałem z najnowszych wersji ERDAS (Imagine and Mapper), ArcINFO i Global Mapper na 3,30 gigaherca Intel Xeon E31245, DELL, 16 GB RAM, 64-bit Win 7 Professional. Maszyna Mullti-core (łącznie 4), Hyper-Threaded (łącznie 8). Moje C ma 700 GB wolnego miejsca, a D ma 1,5 TB.

Zastanawiam się nad użyciem Grassa (nigdy przedtem), ale i.image.mosaic wydaje się obsługiwać tylko 4 pliki ... niektóre moje mają 600 płytek. Jakieś inne opcje lub oprogramowanie typu open source do wypróbowania?

Niestety należy dodać, że nie możemy użyć mozaikowego zestawu danych (lub odpowiednika w innym oprogramowaniu), ponieważ musimy utworzyć strefy ze zdefiniowanymi obszarami bez danych jako ecw, aby można je było otworzyć w dowolnym oprogramowaniu GIS i połączyć z niższą rozdzielczością / starszą dane, gdy nowe dane nie istnieją płynnie.

Przykład, jak niektóre mozaikowane pliki wyglądają w innym oprogramowaniu. Global Mapper / ERDAS są w porządku, ale nie są poprawne w Arcgis.

--- INFORMACJE DLA STARSZYCH ---

Przepraszam za szorstki rysunek. Posiadanie kolorowych obszarów jako 5 stref zminimalizuje obszary braku danych w większym AOI.

W Arcgis kod wygląda następująco (jest uruchamiany jako model, a nie w Pythonie, ponieważ nie mogę go pobrać z wejścia 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")

gdzie należy odczytać tifList z pliku csv, ale to nie działało w pythonie, więc zamiast tego uruchamiam powyższe w modelu ...

Mam 1,5 TB + wolnego miejsca na dysku, ale proces ulega awarii z błędem 9999.

Czy przetworzy nawet 100 płytek? -Czy powinniśmy popatrzeć na dalsze dzielenie stref?

Będę musiał zasugerować 2. @ blah238 sugestie dotyczące zastosowania innej metody dostępu do danych niż stworzenie pojedynczego mozaikowego obrazu. Proste przypuszczenie powiedziałoby, że nie ma tam komputera stacjonarnego, który poradziłby sobie z ilością danych, które musiałbyś przetworzyć, aby mozaikować wszystkie te kafelki.
Aby to rozbić, prawdopodobnie są dwa miejsca, w których kończy się miejsce.

1. Pierwszy będzie w buforze pamięci RAM. W celu mozaikowania danych scalasz wszystko w jeden plik, co idealnie oznacza, że ​​cały plik byłby przechowywany w pamięci. Nie masz 550 GB pamięci RAM, co oznacza, że ​​będzie można czytać / zapisywać z pamięci wirtualnej. To wystarczy, aby zawiesić cały proces.
2. Innym problemem może być miejsce na dysku twardym. Wiele operacji rastrowych tworzy dość duże pliki tymczasowe w katalogu „obszaru roboczego”. Mogą być ich 2 lub 3 lub więcej, zanim ostateczny zestaw danych zostanie nawet zapisany, więc możliwe jest wykorzystanie całego miejsca na dysku podczas przetwarzania.

Teraz inne rozwiązania. Jak wspomniano w komentarzach powyżej, istnieje możliwość utworzenia zestawu danych mozaiki . Ten zestaw danych pozwoli nie tylko traktować wszystkie pojedyncze kafelki jako pojedynczy jednolity obraz, ale także zachowuje metadane dotyczące poszczególnych zawartych w nim kafelków. Umożliwia także wykonywanie operacji rastrowych, takich jak Hillshade .

Inną opcją, którą poleciłbym na podstawie twojego komentarza o chęci oddzielenia stref, byłoby utworzenie katalogu rastrowego . Katalog rastrowy jest zasadniczo warstwą grupową. Możesz dodać do niego wiele zestawów danych rastrowych. Można nimi zarządzać w geobazie i importować rastry lub po prostu utworzyć niezarządzany zestaw danych, w którym katalog rastrowy zachowuje ścieżki do oryginalnych zestawów danych rastrowych. Kiedy ładujesz tę warstwę do ArcMap, możesz ustawić właściwości wyświetlania, aby ładować tylko określoną liczbę kafelków rastrowych na raz lub ustawić skalę wyświetlania i rozdzielczość.
Obecnie używam katalogu rastrowego do układania ponad 100 GB zdjęć lotniczych. Wydajność jest bardzo dobra. Jeśli szukasz innego rodzaju pamięci do przechowywania danych po prostu w celu zarządzania dużą liczbą kafelków, naprawdę polecam.

Oto kod, którego możesz użyć do utworzenia katalogu rastrowego, a następnie zaimportuj do niego obszar roboczy płytek :

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")

Mam nadzieję że to pomoże!

------------- Edytować

Oto grafika płytek obsługiwanych przez mój katalog rastrowy. Pamiętaj, że możesz wybrać wyświetlanie ramek lub danych rastrowych. Katalog rastrowy zawiera tabelę atrybutów, do której można dodawać pola, na przykład, jeśli chcesz dodać oznaczenia stref jak na grafice. Następnie możesz wybrać wyświetlanie tylko tych rastrów w określonej strefie.
Podczas drukowania grafiki z widoku układu używana jest pełna rozdzielczość rastrów, więc nie ma utraty jakości wydruku.

Oto ta sama grafika, ale pokazuje niektóre dane rastrowe wraz z niektórymi ramkami.

Wiem, że jestem spóźniony na przyjęcie. Ale oto moja sugestia.

1) rozmiar obrazu
Jeśli oryginały 550 GB są nieskompresowane, należy je przekonwertować na skompresowane pliki JPEG w formacie JPEG. Zachowaj je osobno (nie scalone). Możesz kompresować za pomocą arcgis, gdal, co tylko chcesz. Kompresja zapewni ci około 23 GB. Nie twórz jeszcze piramid / przeglądów. Do kompresji możesz użyć dowolnego programu gis, który ci się podoba, ale lubię używać gdal, więc polecenie jest w zasadzie następujące:

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

Możesz łatwo utworzyć plik nietoperza, który przejdzie wszystkie nieskompresowane tiffy. Lubię używać gdalwarp do kompresji moich zdjęć zamiast zwykłego gdal_translate, ponieważ jest on szybszy (użycie opcji multi dla wielu rdzeni i -wm dla dużej ilości pamięci).

2) obsługa jako pojedynczy obraz
Możesz stworzyć „wirtualną” mozaikę w formacie gdal vrt. Jest to kompatybilne z arcgis, qgis, mapserver itp. Nie jestem pewien co do globalnego mapera i mapinfo. Format .vrt to tylko jeden plik xml zawierający listę obrazów. To jedno polecenie do utworzenia:

gdalbuildvrt nameofmosaic.vrt compressed_tif_folder\*.tif

Ten plik ma rozmiar kilku KB.

3) wizualizacja prędkości
Musisz budować piramidy / przeglądy. Po prostu użyj do tego swojego preferowanego oprogramowania. Korzystając z narzędzi gdal możesz:

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

To zajmie trochę czasu. Przygotuj się na czekanie 2–3 dni nieprzerwanego przetwarzania.

4) za pomocą mozaiki
Załaduj wirtualną mozaikę do swojego programu gis. Będzie to szybkie, ponieważ czyta przeglądy, które są w jednym pliku jak ecw. Kiedy powiększysz rzeczywistą rozdzielczość twoich obrazów, tylko kilka widocznych ze skompresowanych obrazów zostanie odczytanych, i to też jest naprawdę szybkie.

5) obsługa obszarów bez danych, które pokazują czarny
Masz na to 3 rozwiązania: i) użyj formatu pliku, który obsługuje nodata, co będzie skomplikowane; lub ii) użyć pasma alfa lub iii) plik maski. Możesz utworzyć pasmo alfa automatycznie w kroku 2, mówiąc GDAL, że chcesz, aby obszary nodata były w pasmie alfa - wystarczy dodać opcję -addalpha:

gdalbuildvrt -addalpha nameofmosaic.vrt compressed_tif_folder\*.tif

Problem z pasmami alfa polega na tym, że źle się kompresują. Twoje przeglądy będą większe. Jeśli nie masz nic przeciwko, to koniec.

Jeśli chcesz utworzyć plik maski, jest to nieco bardziej skomplikowane. I uważam, że nie pasuje to do obecnego pytania.

Mam nadzieję, że to pomoże. Informacje na temat narzędzi gdal można znaleźć w Google. Wokół mnóstwo interesujących rzeczy.

550 GB danych wejściowych TIF można łatwo obsłużyć w jednym pliku ECW. Mamy wielu klientów kompresujących znacznie większe zbiory danych niż ten, więc nie sądzę, że format nie jest w tym obszarze odpowiedni.

Twoja strategia dzielenia projektu na małe kafelki w celu zminimalizowania pustego obszaru jest również dobrym podejściem do obecnej wersji formatu, ponieważ skróci czas kompresji

Twój przykład zawiera odniesienie do niepodpisanych 16-bitowych danych wejściowych. Polecam przeskalowanie do 8 bitów, jeśli to możliwe (w zależności od twoich wymagań)

Proszę wyjaśnić, dlaczego nie udało się przetworzyć projektu za pomocą IMAGINE lub ERMapper, ponieważ bez tych informacji nie mogę ci pomóc. Lub jeszcze lepiej skontaktuj się z lokalnym zespołem wsparcia

Należy pamiętać, że przy użyciu formatu ESRI Mosaic Dataset, powyższe odpowiedzi nie wspominają o wymogu wygenerowania warstwy piramidy / przeglądu. Bez tego wydajność znacznie ucierpi. Możliwe, że możesz utworzyć równoważne pliki ECW w tym samym czasie, ale poprawiając jakość obrazu i znacznie mniejsze wymagania dotyczące miejsca na wyjściu.

Chociaż zdecydowanie lepiej jest użyć jednej z innych wymienionych opcji, możesz wypróbować następujące czynności:

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

Spowoduje to zbudowanie wirtualnego formatu GDAL, a następnie konwersję do pojedynczego GeoTiff.

Brzmi mi to dość znajomo, produkujemy również duże pojedyncze pliki ECW z 500 zbyt 1 TB plików TIF. Ale nie chciałbym przetrwać w ArcGIS (ArcObjects and Geoprocessing Engine), ponieważ nie jest w stanie w wiarygodny sposób mozaikować tej kwoty. Jeśli chcesz pozostać w Świecie ESRI, zaleciłbym mozaikowanie fragmentów o wielkości około 50 GB lub nawet mniejszych jednocześnie do zbioru danych rastrowych przechowywanego w geobazie pliku. Narzędzie do mozaikowania po pewnym czasie ulega awarii, więc dobrym pomysłem jest zwolnienie pamięci ArcGIS po niektórych GigaBajtach.

Inną możliwością jest użycie geobazy SDE Enterprise lub Workgroup SDE. Z SDE otrzymujesz staromodne narzędzia wiersza poleceń SDE, które są zbudowane na solidnej architekturze C ++ innej niż zawodne ArcObjects. Za pomocą polecenia „sderaster -o mozaika ...” możesz mozaikować RasterDataset, aż do zapełnienia magazynu bazy danych. Istnieją również Polecenia do budowania piramid statystyki dla RasterDataset, w przeciwnym razie nie jest to bardzo przydatne, ponieważ większość Klientów nie może przechowywać obrazów w pamięci podczas ich czytania, jak wspomniano powyżej blah238. Ale piramidy (w rzeczywistości indeksowanie przestrzenne) powinny rozwiązać ten problem.

Ale te rozwiązania na pewno nie pomogą w MapInfo. Wspomniałeś, że wypróbowałeś już ERDAS Mapper. To także narzędzie, które wolałbym. Już mozaikowaliśmy 16000 plików TIF, każdy o wielkości 50 MB, które mają 800 GB, a następnie skompresowaliśmy do pojedynczego ECW ze współczynnikiem kompresji 1:20, co dało 30 GB pliku ECW. Zastanawiam się, że to nie działa dla ciebie ...

Przynajmniej cały proces działał na jednym rdzeniu Pentium 4 1,6 GHz z 2 GB pamięci RAM, więc sprzęt nie powinien stanowić problemu. Korzystamy z systemu Windows Server 2003 (lub innego systemu operacyjnego serwera), ponieważ lepiej wykorzystuje zasoby harware. Należy pamiętać, że cały proces kompresji wymaga dużo czasu. Nasza maszyna pracowała około 5 tygodni nad tym pojedynczym plikiem, a ponieważ czasami ulegała awarii, musieliśmy to zrobić kilka razy, ale ostatecznie otrzymaliśmy nasz plik ECW.

Nie znam innego systemu ani mechanizmu do przechowywania dużych ilości rastrów w sposób neutralny dla dostawców. Wszystkie wyżej wymienione sposoby są bardzo specyficzne dla ESRI. Przynajmniej z Oracle RASTER i całkiem podobną implementacją w PostGIS istnieją dwa warianty bazodanowe, które również nie są neutralne dla dostawców, ale są otwierane przez interfejs SQL / MM.

Mam nadzieję, że to trochę pomoże.