Gdal Dataset.ReadAsArray () plante Python

J'utilise Python 2.6.5 (32 bits) avec Numpy 1.3 et Gdal 1.9.1 installés sur Windows 7 64 bits. J'essaie de lire un ensemble de données raster de 800 Mo Imagine (.img) dans un tableau Numpy pour faire de l'algèbre raster, mais dès que j'exécute le code suivant, Python.exe se bloque.

from osgeo import gdal

g = gdal.Open(r'path\to\dataset', gdal.GA_Readonly)
b = g.GetRasterBand(1)
data = b.ReadAsArray()

Python.exe se bloque lors de l' b.ReadAsArray()appel. J'ai fait des recherches sur Google et j'ai trouvé des articles datés de Gdal 1.6 qui mentionnaient ce problème avec Windows 7 64 bits, mais ils ont également mentionné qu'il avait été corrigé dans les dernières versions de développement à l'époque.

Quelqu'un d'autre a-t-il eu ce problème? Des solutions?

MISE À JOUR:

J'ai décidé de déboguer le code dans PyDev pour essayer de déterminer où il échoue. D'après ce que je peux dire (toujours pas de message d'erreur), il échoue à la ligne 22 de gdal_array.py.

_mod = imp.load_module('_gdal_array', fp, pathname, description)

Lorsque j'entre dans la ligne de code ci-dessus, cela m'amène dans le module init .py de numpy. Quand j'arrive à la fin du numpy. __ init __ .py module, il revient à la ligne de code ci-dessus. Ensuite, lorsque je clique sur le bouton Étape vers, qui devrait m'amener à la ligne suivante dans gdal_array.py, le script se termine sans aucun message d'erreur ou quoi que ce soit.

MISE À JOUR # 2:

J'ai désinstallé GDAL 1.9.1 et installé GDAL 1.6.1 à partir de Python Cheeseshop et des binaires Windows d'OSGeo. Avait toujours le même problème.

— Brian
source

J'avais ce problème. Utilisez-vous les liaisons gdal python de Tamas sur gis.internals? Si c'est le cas, déplacez vos ajouts vers votre CHEMIN vers l'avant. Une autre bibliothèque me causait des problèmes.

— Jay Laura

Je crois que j'ai téléchargé de ses internes. J'essaierai d'ajuster mon chemin lorsque j'entrerai au bureau demain. Merci pour le conseil.

— Brian

Si cela ne fonctionne pas, je suis récemment passé à l'utilisation de ces packages - lfd.uci.edu/~gohlke/pythonlibs

— Jay Laura

J'ai essayé de déplacer des choses dans mon chemin d'accès système (variable d'environnement PATH dans Windows) sans succès. J'ai également désinstallé ma version de GDAL et installé la version de GDAL sur le lien que vous avez fourni et j'avais toujours le même problème.

— Brian

Hmmm .... la version à laquelle j'ai lié n'était que les liaisons, donc vous devez toujours avoir le noyau GDAL de Tamas. Si les autres appels ont bien fonctionné, cela fonctionne très bien. Trois choses à essayer qui sont des plans longs (par ordre de «longévité». 1) Mettez à jour votre version de Numpy. 2) gdal_translate à gtiff et essayez le code sur cette image. 3) ajoutez ReadAsArray () avec .astype (numpy.float32). L'image est-elle publique? Je peux le tester sur ma machine. Pouvez-vous publier la trace de la pile si aucun de ces éléments ne fonctionne?

— Jay Laura

Réponses:

Comme de nombreux commentateurs le soupçonnaient, c'était un problème avec mon installation. Apparemment, je ne portais pas assez d'attention à l'installation de GDAL et des liaisons Python.

J'ai installé GDAL Core et les plugins (dll's) de gisinternals.com, mais je n'ai pas pensé à installer les liaisons Python à partir de là aussi. Les liaisons Python que j'ai installées provenaient d'un site différent (je ne me souviens plus lequel à ce stade).

Lorsque j'ai réinstallé GDAL et les liaisons Python à partir de gisinternals.com, j'ai réussi à lire ReadAsArray.

Merci à tous ceux qui ont commenté et répondu et je m'excuse pour mon ignorance.

— Brian
source

Il est possible que ce soit un problème de mémoire. Lorsque vous utilisez ReadAsArray, il met les données en mémoire, et bien que 800 Mo ne soient pas massifs, ils ne sont pas minuscules non plus. Avez-vous essayé de lire le tableau par blocs?

data = b.ReadAsArray(x_offset, y_offset, x_size, y_size)

Vous devriez pouvoir parcourir le tableau et le traiter en bloc à la fois, mais selon le traitement que vous effectuez, vous devriez probablement chercher à lire dans les zones avec chevauchement pour éviter les effets de bord.

— om_henners
source

J'ai essayé d'utiliser des morceaux. J'ai essayé data = b.ReadAsArray(0,0, 500, 500)avec le même résultat.

— Brian

Hmm. Je suppose que vous avez essayé d'autres formats d'image? Y avait-il également un message d'erreur spécifique?

— om_henners

Je n'ai pas encore essayé d'autres formats. il n'y avait pas de message d'erreur, juste un popup qui disait "python.exe a cessé de fonctionner".

— Brian

J'ai converti le fichier .img en GeoTIFF ce matin et j'ai réessayé. Pas de chance.

— Brian

Existe-t-il un moyen de mapper en mémoire le fichier depuis gdal?

— CMCDragonkai

Désolé, je suis en retard à cette fête, mais votre problème de base est que Python 32 bits ne peut pas stocker de très grands rasters en mémoire. Vous pouvez lire votre grand raster en mémoire par morceaux de petite taille, mais vous êtes alors assez limité en termes de ce que vous pouvez traiter efficacement sans lecture / écriture extrêmement inefficace / fréquente sur le disque.

Ce que je fais à la place (qui sacrifie une certaine efficacité en raison de la lecture / écriture sur le disque) est d'appeler ( via l'encapsulage EXE ) la version gisinternals.com 64 bits de la méthode gdal dont vous avez besoin. Soyez prudent avec l'utilisation du module de sous-processus de python dans une boucle (c'est-à-dire que vous voudrez / devrez peut-être appeler un sous-processus séquentiellement ) car vous risquez de générer par inadvertance trop de threads ouverts pour votre boîte Windows et d'obtenir des avertissements inquiétants du système. Vous sacrifiez un peu dans la manière de lire / écrire sur le disque avec cette approche gdal, mais votre efficacité de traitement ne diminue que (c'est-à-dire par rapport à un calcul rapide en mémoire , si votre box / bibliothèque peut le supporter) d'environ un facteur ou dix.

— ksed
source