Vitesse de divers formats de données raster

J'ai du mal à localiser une discussion ou une analyse comparative comparative de différents formats de fichier raster (par exemple, pour une utilisation dans l'analyse de données dans R). Quelqu'un a-t-il une idée de la raison pour laquelle des formats particuliers peuvent être plus rapides ou plus lents? Ou les différences devraient-elles être minimes?

Plus précisément, je suis intéressé à savoir si la conversion d'un raster (par exemple, un fichier GEOTIFF) en un format différent (par exemple, un netCDF) est jamais utile dans le but d'accélérer la lecture / écriture et d'autres opérations.

Voici un ancien article de blog qui examine la taille du fichier et le temps d'accès aux formats. Je n'ai pas étudié la vitesse d'écriture, seulement le temps d'accès. Je dirais qu'ils seraient probablement directement liés, mais ne pourraient pas en témoigner.

Résumé de l'article: Il semble que Packbits vous donne les meilleurs temps d'accès (au détriment de l'espace disque), tandis que Deflate vous donne des temps d'accès intermédiaires / lents pour les fichiers intermédiaires / petits. De plus, vous pouvez tester les temps d'accès de manière plus empirique en créant des miniatures de différentes tailles et en chronométrant le temps nécessaire. Exemple de commande:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

En supposant que la seule chose pertinente pour R dans ce cas est la rapidité avec laquelle il peut lire les données du fichier, comme tout autre processus, cela devrait vous donner une bonne indication.

Pour les opérations de lecture / écriture , vous pouvez tester la vitesse de ces opérations à l'aide de system.time (). Voici quelques résultats du chargement d'un fichier DEM en R (package Raster) traduit en quatre formats (ASCII, IMG et TIF sans compression et dégonflage). Par exemple, sur un raster de ~ 26 Mo:

> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
 user  system elapsed 
 0.154   0.002   0.157 

«Elapsed» donne le temps total (en secondes) pris pour l'opération. Exécution des opérations 10 fois chacune et examen du temps moyen écoulé:

              mean   diff
ASC         0.2237 0.3317
IMG         0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none    0.1495 0.0000
tif-pack    0.1513 0.0118

TIFF sans compression est le plus rapide ... suivi de très près par Deflate (0,1% plus lent) et TIFF-Packbits (1,8% plus lent), puis IMG (3,2% plus lent) et ASC (33% plus lent). (C'est sur un Macbook Pro 2,4 GHz avec un SSD, donc des opérations de disque rapides)

Il s'agit simplement de charger les fichiers, pas de les manipuler.

Peut-être que ce n'est vraiment pas une question de savoir quel format d'image raster a de meilleurs repères d'ouverture - plutôt quels formats d'image raster sont les formats de source raster les plus efficaces pour l'ouverture et la lecture en entrée dans un tableau numérique R. Et par la suite - quel est le format de sortie le plus efficace de R en supposant que vous renvoyez les résultats au raster.

Quoi qu'il en soit, si vous travaillez avec raster dans R, vous utiliserez probablement les packages rgdal et R ncdf pour compléter ce qui est contenu dans le package r raster . En s'appuyant principalement sur commande gdalwarp . Besoin de déterminer les dépendances de format pour faire votre choix raster. Vous trouverez une bonne couverture sur SO et divers forums / blogs / wiki OSGEO et R.

Mais comme il s'agit d'un forum SIG où l'utilisation de Python est relativement ascendante, je noterai qu'il y a des avantages à travailler avec des données raster dans un tableau numpy Python, avec une dépendance similaire sur les bibliothèques gdal pour le chargement, la conversion et l'exportation de raster. Certaines personnes trouvent la gestion de la mémoire et la structure du code en Python préférables au R natif - jetez peut-être un coup d'œil à RPy2 ou PypeR, car l'un ou l' autre peut être approprié pour votre utilisation d'analyse.

Une grande question est de savoir si vous allez lire l'intégralité du raster du fichier dans la mémoire avant de le traiter, ou si le fichier est si volumineux que vous le traiterez de manière incrémentielle ou traiterez un sous-ensemble du fichier global.

Si vous chargez tout cela en mémoire, vous effectuerez principalement un accès séquentiel, et le format le plus rapide sera un basculement entre le stockage brut et compressé (en fonction de choses comme la vitesse de votre processeur par rapport au disque). Tous les formats de fichiers binaires seront probablement assez proches (ASCII sera plus lent).

Si vous avez besoin de traiter un sous-ensemble d'un fichier très volumineux, un format qui regroupe le sous-ensemble que vous souhaitez rapprocher peut être plus rapide - par exemple: des tuiles ou un format qui peut calculer des décalages. Parfois, les approches non compressées gagnent ici car il peut être trivial de calculer où une partie donnée de l'image réside dans le fichier, surtout si vous n'avez besoin que d'une partie d'une très grande ligne, mais la compression peut être effectuée de manière granulaire qui fonctionne bien pour certains modèles d'accès.

Désolé, mais vous devrez probablement comparer vos performances en fonction de votre modèle d'accès, plutôt que d'obtenir une solution unique. Cela peut bien sûr dépendre non seulement du format de fichier et des facteurs ci-dessus, mais aussi des pilotes de ce format et de votre logiciel.

La façon dont vous pensez à ces types de problèmes dépend de la façon dont votre application accède à votre fichier, par rapport à la façon dont les données sont présentées dans votre fichier. L'idée est que si vous pouvez accéder à vos données de manière séquentielle, ce sera beaucoup plus efficace que si vous y accédez de manière aléatoire.

GeoTIFF est une collection d '"images" 2D ou tableaux. NetCDF est un stockage à usage général pour les tableaux multidimensionnels. Mais si vous stockez les tableaux de la même manière dans netCDF que dans GeoTIFF, vous obtiendrez plus ou moins les mêmes performances.

On peut également réorganiser les données dans netCDF, donc en principe pourrait optimiser pour vos modèles de lecture. Je suppose que la plupart des applications SIG sont optimisées pour la mise en page GeoTIFF 2D, donc il n'y a pas grand-chose à gagner en réorganisant.

Enfin, je dis que cela n'a vraiment d'importance que lorsque vous avez de très gros fichiers, au moins des dizaines de mégaoctets.

J'ai lu quelques pages à ce sujet il y a plusieurs années et j'ai depuis utilisé tiff avec compression packbits, carrelé avec un en-tête geotiff, et je suis content.

article de l'équipe arcpad

wiki

Mais après avoir lu ce qui suit, je reconsidérerai et utiliserai peut-être la variété de dégonflage.

Site Arcpad

De nombreux packages utilisent GDAL sous le capot, par exemple, rgdal, QGIS, GRASS, etc. Si j'utilisais l'un de ces packages, je penserais à convertir mes images en vrt. J'ai souvent vu qu'il était recommandé que lorsque vous devez utiliser deux commandes GDAL, le fichier intermédiaire devrait être un fichier vrt car la surcharge de lecture est minimale (par exemple, http://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html ). Cela ressemble à votre flux de travail: convertir une fois et lire plusieurs fois. Peut-être que vrt serait approprié.

[Modifier: lien ajusté]