Le portail francophone de la géomatique

trés interessant merci d'en faire profiter tout le monde

Bonsoir,
Je trouve très sympa de partager cette documentation.
Je suis sûr que cela sera très utile (en attendant les éventuelles corrections)
Merci

BM

Joli travail en effet !

Quelques remarques :
* concernant la capture d'écran page 11 avec les couleurs funky, il serait intéressant si tu peux reproduire avec une image la plus petite possible de la poster quelque part avec les commandes exactes utilisées pour reproduire ce phénomène. Ca peut être un bug. Ou alors s'il y a une valeur nodata renseignée sur le raster en entrée, il faut savoir que gdalwarp opère bande par bande. Ce qui fait que si nodata=255, la composante bleue d'un pixel valant (0,255,0) sera considéré comme transparente. C'est un comportement connu. Je ne sais pas si c'est le cas dans ton exemple ou autre chose.
* utilisation de LARGE_OK=YES. Comme indiqué en annexe, il y a des problèmes de licence potentiels. Ce serait peut être bien d'alerter les lecteurs dès la 1ère mention page 6, pour ceux qui ne lisent pas jusqu'au bout ;-)
* chapitre 5 (manipulation de gros fichiers) : je pense qu'il serait bon de préciser que beaucoup des bizarreries que tu constates (j'admire ton courage d'avoir testé tout ça!) sont vraiment spécifiques à l'ECW qu'il soit en entrée ou en sortie (le cumul des 2 ne doit pas aider!). Les manipulations d'un fichier TIFF de 5 GO ne nécessitent en principe pas de toucher à la valeur par défaut de GDAL_CACHEMAX (qui est bien de 40 Mo en effet : cf http://trac.osgeo.org/gdal/wiki/ConfigOptions page assez récente du wiki -> tu peux donc enlever le "semble être fixée" par "est fixée" page 21). En tout cas ça ne devrait pas entraîner d'erreur. L'augmenter ne sert qu'à jouer pour le tuning des perfos. Quand l'ECW entre dans la boucle, son propre cache se cumule avec celui de GDAL. Ainsi on voit bien dans tes résultats où tu joues sur GDAL_CACHEMAX (800, 300, 50) que l'utilisation mémoire totale est environ 500 MB supérieure, ce qui est effectivement la valeur par défaut du cache de la lib ECW comme ta machine a 2 GB de RAM (valeur par défaut de GDAL_ECW_CACHE_MAXMEM = 1/4 de la RAM totale). Globalement, je pense que tu pourrais résumer que la consommation mémoire du processus ne devrait pas dépasser GDAL_CACHEMAX + GDAL_ECW_CACHE_MAXMEM (exprimés dans les mêmes unités). (A part les résultats que tu constates dans le paragraphe Explication des tests page 22 que je n'arrive pas à justifier.)

Merci ! Et merci Even pour tes corrections.

Je vais modifier tout ça, mais avant je vais te faire carrément un petit .doc sur les tests. Parce que c'est trop compliqué (trop de résultats différents pour trop de commandes différentes) pour que je te fasse ça ici. Par contre je ne peux pas reproduire toutes les situations que je veux avec une image toute petite, donc je refais mes tests sur le même jeu de données, assez important, et je fonctionnerai par capture d'écran.

Je vais essayer d'être clair mais c'est pas gagné, moi-même parfois je m'embrouille dans mes tests


Ted, tu as essayé de faire enregistrer la cible sous ? Il faut peut-être un plug-in adobe que tu n'as pas pour visualiser directement dans un navigateur. Mais si tu le télécharges, tu devrais pouvoir l'ouvrir (enfin si tu as acrobat d'installé bien sûr).

Sam,

En p3 et p16 tu préconises l'utilisation de -projwin, mais tu peux également utiliser -srcwin si ton fichier est géoréf.
Tu utiliseras les coordonnées pixels (moins précises que, mais parfois moins lourde que d'aller dans Circé...).
En p8 tu signales l'utilisation d'un fichier TXT, mais tu peux également lancer la commande comme suit :

ainsi, il mettra dans le VRT tous les tiff présents dans le répertoire de travail.

Très intéressant et utile ton récapitulatif.

Encore merci

Even, le zip contenant les captures et le .doc :

http://up.sur-la-toile.com/iz6F

Dernière modification par Sam_Dalembert (Fri 19 March 2010 11:43)

On est ok!

a+

Petite remarque qui peut avoir son importance : pour "l'astuce" concernant l'extraction d'un ECW à partir d'un ECW (en passant par un VRT), le VRT en question doit obligatoirement être créé avec gdalwarp. S'il est créé avec gdal_translate, ça ne fonctionnera pas.

Version 1.2 : http://up.sur-la-toile.com/izgJ

Bonjour, et merci beaucoup pour votre réponse ! Alors pour répondre dans l'ordre :

- oui c'est vrai qu'en y réfléchissant métrique/centimétrique ça correspond beaucoup mieux aux observations
- je dois dire que certaines options utilisées (dans les commandes décrites sur le site), je ne les ai rencontrées nulle part ailleurs, donc, ne savant pas trop à quoi elles correspondaient, comment les utiliser...en effet, l'option -rc permet d'éviter ces décalages. C'est quand même une option très importante, mais je n'ai pas vu souvent les gens l'utiliser, bizarre. Par contre c'est beaucoup plus long, il va falloir que je fasse des tests, mais sur le seul fichier que j'ai fait, ça passe de 1min20 à plus de 5min !
- oui, en effet c'est probablement mieux de forcer à garder exactement la même résolution
- ça je crois que c'est pareil, il me semble m'être heurté à cette erreur. En dehors du raster, gdal_translate ne veut pas extraire. Je ne sais pas s'il y a une solution, je n'en ai jamais entendu parler en tous cas.

Je vais modifier tout ça

Dernière modification par Sam_Dalembert (Wed 24 March 2010 14:32)

Oui oui, je ne dis pas que c'est pas normal, je souligne juste que c'est beaucoup plus long et que -selon moi- ça peut inciter à faire un choix.
Je viens d'essayer avec un fichier 8 fois plus gros, le facteur reste à peu près le même. Donc on peut prudemment conclure que le temps de sortie du fichier est environ 3 à 4 fois plus long... Je pense que ça peut jouer quand même, sachant que l'altération avec le ré-échantillonnage par défaut reste quand même acceptable (tant qu'on ne descend pas en-dessous de l'échelle optimale de visualisation, on ne voit pas de défaut).

Dernière modification par Sam_Dalembert (Wed 24 March 2010 14:50)

Bonjour,

En effet, IGNMap utilise un rééchantillonnage bicubique, afin d'obtenir la même qualité que pour des reprojections réalisées directement par l'IGN (c'est le même bicubique).
Je ne pense pas que l'on puisse vraiment aller beaucoup plus vite que ce qui est fait actuellement en bicubique. De ce point de vue, IGNMap est même plutôt rapide.

Cordialement,
Gilles Martinoty

Salut SAm,

p36 de ton pdf pour l'erreur gdal_retile (#13) tu as mis

ça ne pas plutôt ça

?
j'ai testé et ça fonctionne uniquement avec

Même si avec la prochaine version, ce problème sera normalement corrigé!

a+

Effectivement la régression sur gdal_retile sera corrigée par GDAL 1.7.2

Vous pouvez directement récupérer la version corrigée du script ici : http://trac.osgeo.org/gdal/browser/bran … format=raw

C'est l'avantage du Python, pas besoin de recompiler !

Ha ? Je veux bien une explication scientifique du rapport entre le rééchantillonage utilisé et le nombre de couleurs de l'image. Ça me parait fortement étrange. Que le rééchantillonage dégrade plus ou moins la qualité de l'image certes, et que donc suivant la qualité initiale de l'image ça se voie plus ou moins certes, mais pour moi ce n'est pas lié à la profondeur de couleur directement.

vincent

Version 3.2: http://up.sur-la-toile.com/izGL

Ajout d'une petite astuce page 8 et 9 pour permettre l'identification par GDAL des codes ERMapper pour les zones CC et éviter la génération d'un XML.