Ich habe eine R-Funktion geschrieben, die gdal_calc.py aufruft, um den pixelweisen Mindestwert über ein RasterStack (Reihe von Eingabe-Rasterdateien) zu berechnen. Ich habe das gemacht, weil es viel schneller ist als raster::min für große Raster. Die Funktion eignet sich für bis zu 23 Dateien, löst jedoch bei der Übergabe von 24 oder mehr eine Warnung aus und gibt ein mit Nullen aufgefülltes Ausgabe-Raster zurück.
Da R gerade einen Systemaufruf an python gdal_calc.py vorbereitet, ist diese Frage nicht spezifisch für R und ich ermutige Python / Numpy-Fans weiter zu lesen.
Hier ist die Funktion. Die Struktur des eventuellen Aufrufs gdal_calc wird in der Warnmeldung angezeigt, die von der problematischen Verwendung am Ende dieses Beitrags ausgegeben wird.
Und hier ist ein Dummy-Raster, geschrieben in 'test.tif' im aktuellen Arbeitsverzeichnis. Der Einfachheit halber und um zu zeigen, dass das Problem nicht auf ein eigenartiges einzelnes Raster zurückzuführen ist, übergebe ich die gleiche Eingabedatei mehrmals an gdal_calc, anstatt eine Anzahl verschiedener Dateien zu übergeben.
Die Funktion funktioniert gut für 23 Eingabedateien:
%Vor%... aber nicht für ≥ 24:
%Vor%Die Rückverfolgung, die bei der Ausführung des letzteren direkt vom Terminal gegeben ist, ist:
%Vor% Auch hier läuft das, was ich erwartet hatte, als ich den Verweis auf X entfernt habe.
Ich verwende Python 3.3.5 , gdal 1.11.1 und numpy 1.9.1 auf Win 10 x64.
Warum könnte das passieren?
Das Problem, mit dem Sie konfrontiert wurden, war, dass die X Variable aus dem calc Eingang mit der Variablen kollidierte, die von einer Schleife in der doit Funktion erstellt wurde:
Es scheint, dass dies bereits von den gdal-Entwicklern behoben wurde (in noch nicht veröffentlichtem Code). Es ist jetzt eval s der calc -Eingabe in einem privaten Namespace (einem Dictionary) und nicht im lokalen Namespace der Funktion, sodass die Variable X aus der Schleife nicht mit dem X -Wert der Eingabe in Konflikt steht noch mehr.