Jaka jest różnica między gdalwarp i gdal_merge do mozaikowania

15

Chciałem połączyć około 20 dem tiffów po około 100 MB i użyłem gdalwarp (wiem o opcji pliku wirtualnego):

gdalwarp $(list_of_tiffs) merged.tiff

Jednak polecenie to trwało bardzo długo i po około 15 minutach przetwarzało 5. obraz z zestawu. Kończę to.

Następnie odkryłem, że skrypt gdal_merge.py może być również używany do mozaikowania i wypróbowałem:

gdal_merge.py $(list_of_tiffs)

która zakończyła się w mniej niż 3 minuty.

Jak się spodziewałem, że oba polecenia dadzą taki sam wynik, zastanawiam się, jaka jest różnica między nimi, dlaczego gdalwarp zajmuje tyle czasu, jeśli wynik jest taki sam?

gdal gdalwarp gdal-merge zetah
źródło

Odpowiedzi:

21

Chociaż nie wiem, dlaczego GDAL zapewnia takie nakładanie się funkcjonalności, pamiętaj, aby ustawić pamięć podręczną dla gdalwarp, aby była naprawdę szybka:

# assuming 3G of cache here:
gdalwarp --config GDAL_CACHEMAX 3000 -wm 3000 $(list_of_tiffs) merged.tiff

Pamiętaj, aby nie definiować więcej pamięci podręcznej niż posiadania pamięci RAM na komputerze.

markusN
źródło
Nie miałem pojęcia o tym przełączniku strojenia, który rzeczywiście przyspiesza proces. Dla odniesienia 3000 to 3 GB (więcej informacji trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp ) Mam kompilację NumPy z MKL w moim systemie Python, ale nadal gdalwarpmuszę robić coś więcej, ponieważ NumPy nie może być szybszy niż C wdrożenie, choć może to osiągnąć.
zetah
3000 to naprawdę 3 GB, a może 3072?
miln40,
14

Właśnie natrafiłem na to pytanie i potencjalną odpowiedź, gdy szukam czegoś innego.

gdal_merge.py używa ponownego próbkowania najbliższego sąsiada. Jeśli chcesz kontrolować zastosowane ponowne próbkowanie, powinieneś użyć gdalwarp.

źródło: trac.osgeo.org

dhewlett
źródło
5

gdal_merge.py ładuje wszystkie pliki do pamięci przed ich przetworzeniem. dlatego nie jest w stanie przetwarzać dużych plików, jeśli pamięć jest mała. patrz tutaj

joaoal
źródło