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

11

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.

wprowadź opis zdjęcia tutajPrzykł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 ---

wprowadź opis zdjęcia tutaj

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?

GeorgeC
źródło
3
To niesamowita ilość danych do przepychania. Nie próbujesz scalić go w jeden gigantyczny plik TIF, prawda? Sugerowałbym utworzenie mozaikowego zestawu danych lub usługi mapowania w pamięci podręcznej .
blah238
tak to jest ... nie, to idealnie będzie 7 indywidualnych ecw lub tif (jeśli używasz arcgis). Mogę dodać grafikę rozmiaru / stref, ale nie jestem pewien, czy byłoby to pomocne.
GeorgeC
Opierając się na twoich komentarzach dotyczących twojej organizacji korzystającej z MapInfo i innego oprogramowania, zamiast ArcGIS, usuwam moją odpowiedź, ponieważ tak naprawdę wcale nie spełnia twoich potrzeb. Sugeruję jednak, abyś w swoim pytaniu podał pewne szczegóły dotyczące wymagań dotyczących oprogramowania, aby zapobiec dalszej podróży ścieżką Esri.
Uzyskaj program Spatial
@GetSpatial - dzięki za szczegółową odpowiedź. Jest to jedno rozwiązanie na krótką metę i prawdopodobnie z niego skorzystamy, ale jak wspomniałem w moim pytaniu, jesteśmy naprawdę niezależni od oprogramowania i mamy duże firmy (ESRI / ERDAS / MAPINFO i Global Mapper). Kluczem jest dla nas wynik - ~ 5 mozaik ze zdefiniowanymi obszarami bez danych, aby można było użyć innych zdjęć. ECW powinny mieć zdefiniowane brak danych w całym oprogramowaniu - stwierdziliśmy, że niektóre mozaiki nie zachowują właściwości braku danych w innym oprogramowaniu. Podam przykład. Dzięki jeszcze raz. Chciałbym prosić o zachowanie odpowiedzi tutaj, podniosę głosowanie.
GeorgeC

Odpowiedzi:

9

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.

wprowadź opis zdjęcia tutaj

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

wprowadź opis zdjęcia tutaj

Uzyskaj przestrzenny
źródło
Dziękuję za poświęcony mi czas. Jest to dobre rozwiązanie krótkoterminowe, ale ponieważ organizacja korzysta z Mapinfo i innego oprogramowania, naprawdę musimy być w stanie tworzyć ecw z obszarem rady podzielonym na około 5 stref. Mapinfo ma jednolite warstwy (podobne do katalogu rastrowego). Ważne jest jednak, aby zdefiniować obszary bez danych, abyśmy mogli nałożyć nowe zdjęcia na starsze obrazy o szerszym zasięgu i zmniejszyć liczbę otwieranych plików.
GeorgeC
1
W przyszłości prawdopodobnie uzyskasz trafniejszą odpowiedź, jeśli podasz tego rodzaju informacje w swoim pierwotnym pytaniu.
Uzyskaj Spatial
1
Czy sprawdziłeś, jakie usługi map internetowych mogą być wykorzystywane przez MapInfo? Podejrzewam, że będziesz chciał umieścić w pamięci podręcznej wersje wszystkich tych danych na serwerze w celu ich wykorzystania przez organizację, a nie surowe dane. Myślę, że kwestia braku danych jest kwestią sporną w przypadku usług map, ponieważ po prostu nie tworzysz kafelków, w których nie ma danych, a wszystko, co jest pod nimi, przejdzie.
blah238
7

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.

Duarte Carreira
źródło
1
Niezły post. Należy pamiętać, że gdalwarp podczas faktycznego wypaczania (np. Ponowne rzutowanie, ponowne próbkowanie itp.) Ma długotrwały problem z tworzeniem wyjścia znacznie większego niż potrzeba, gdy używana jest kompresja. W takich przypadkach lepiej jest pominąć kompresję w fazie gdalwarp, a następnie kontynuować gdal_translate -co compress=xxx. Nie stanowi to problemu, jeśli jest używany tylko jako tłumacz (jak sugerowano tutaj).
matt wilkie
1
dzięki. Myślę, że ten problem został rozwiązany, ponieważ ostatnio projektowałem i kompresowałem w tym samym czasie i uzyskałem dobre współczynniki.
Duarte Carreira
5

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.

Chris Tweedie
źródło
1
Na podstawie dostarczonych nowych informacji obszary zerowe ECW nie są poprawnie wyświetlane w ESRI, ponieważ nadal zawierają bardzo stary zestaw SDK v3, który nie obsługuje kanału nieprzezroczystości (jest po prostu ignorowany). Aby to naprawić, odwiedź erdas.com i pobierz wtyczkę ArcGIS ECW, która zainstaluje zestaw SDK v4 z obsługą krycia, a ECW będą wyświetlać się tak samo jak w oprogramowaniu Globalmapper i ERDAS
Chris Tweedie
Wystarczy zauważyć, że ta wtyczka naprawiła „problem” w ArcGIS, ale potem przerwała wyświetlanie Mapwfo ecw i dlatego musiała zostać odinstalowana na każdym komputerze, który miał oba.
GeorgeC
4

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.

Matthew Snape
źródło
3

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.

Jürgen Zornig
źródło
Dziękujemy za zachętę - że działało na jeszcze większych zestawach danych. W przypadku systemu ERDAS problemem był nie tylko rozmiar zestawu danych powodujący awarię, ale także nieprawidłowo zdefiniowane obszary braku danych. Zobacz zaktualizowane pytanie. Czy udokumentowałeś proces wykorzystany w ERDAS i czy możesz go udostępnić?
GeorgeC