Où ce décalage raster est-il introduit dans la boîte à outils de traitement QGIS?

J'utilise la boîte à outils de traitement (génial!) Dans QGIS 2.0 pour reclasser certaines valeurs NoData dans un raster de -9999 à 0, mais à un moment donné du processus, un décalage d'environ 0,2 degré est introduit dans la couche de sortie.

J'utilise l'outil "Reclassifier (Simple)" (je crois que cela fait partie de SAGA), avec quelques paramètres assez basiques:

reclassifier les paramètres

. . . et où le raster en entrée était situé correctement par rapport à cette grille hexadécimale:

raster en entrée

. . . le raster en sortie est heurté au sud-est par deux cellules hexadécimales, soit environ 0,2 degré:

entrez la description de l'image ici

L'origine d'entrée est -180, 83,623. . . mais l'origine de sortie est -179.05,83.05. Normalement, je suppose que c'est le résultat d'une conversion WGS84 défectueuse, mais l'entrée, la sortie et le projet sont tous EPSG: 4326.

D'où vient ce décalage d'origine, et vaut-il la peine de déposer un ticket SAGA ou est-ce juste quelque chose que j'ai négligé?

Mise à jour Le journal de processus indique qu'une transformation est effectuée sur l'origine d'entrée:

Transformation x' = -179.999989 + x * 0.100000 + y * 0.000000
Transformation y' = 83.623125 + x * 0.000000 + y * -0.100000

puis quelques lignes plus tard, les nouveaux paramètres apparaissent, maintenant incorrects:

Grid system: 0.1; 3600x 1735y; -179.949989x -89.826875y

— Bill Morris
source

vous devez tester l'outil SAGA natif à l'aide de l'interface graphique ou de la CLI et voir si vous obtenez le même résultat.

— Giovanni Manghi

Trop d'impasses d'erreur de ces documents d'installation sur ma machine - je ne suis pas intéressé à effacer ma configuration GDAL / PROJ actuelle juste pour tester SAGA nativement.

— Bill Morris

Si vous utilisez SAGA dans QGIS, SAGA est déjà installé sur votre machine.

— Giovanni Manghi

Après plus de 2 heures de travail sur les documents, je n'ai pas la moindre idée de COMMENT LANCER LA GUI DANS OSX. La documentation rappelle R de toutes les mauvaises manières. Aucune variation sur "saga" (-gis, -gui, etc.) ne produit quoi que ce soit sur la ligne de commande, et la compilation à partir de la source renvoie des erreurs complètement inutiles. Merci au ciel miséricordieux (les développeurs principaux, c'est-à-dire) que ce désordre soit maintenant accessible aux humains dans une barre latérale QGIS. J'espère sincèrement que SAGA n'est pas ce qui change l'origine de ma sortie raster, car je ne pourrai jamais la déboguer.

— Bill Morris

Êtes-vous capable de lancer la saga avec la saga_guicommande à la place?

— SaultDon

Votre décalage est de 1/2 pixel (0,1 degré).

Longitude:

-179,999989 - -179,949989 = 0,05

La latitude est moins évidente car une grille est référencée en haut à gauche, l'autre en bas à gauche:

83,623125 - (1735 * 0,1) - -89,826875 = 0,05

Je suppose que cela est lié au problème RasterPixelIsPoint ou RasterPixelIsArea:

http://www.remotesensing.org/geotiff/faq.html#PixelIsPoint

Utilisez-vous gdal 1.7 ou 1.8?

— Marc Pfister
source

À l'échelle du système, j'ai GDAL 1.10.1; pour une raison quelconque, je ne parviens pas à obtenir la console python QGIS pour signaler la version utilisée là

— Bill Morris

il semble bien plus de 1/2 pixel sur l'image.

— radouxju

C'est le cas, mais la taille des pixels est également désactivée. Voici le gdalinfo pour

— Bill Morris

Ah, en voyant gdalinfo, il semble que le décalage soit de .95 et -0.5731265. Le décalage de 1/2 pixel ci-dessus est probablement une conversion de zone en point correcte. Votre raster d'origine a des limites étranges, peut-être qu'ils bousillent la conversion.

— Marc Pfister

Bon point. Bizarre que ça pende du bord du monde d'un degré. Le raster est le résultat d'une conversion de vecteur; laissez-moi voir si je peux refaire cette conversion avec des limites correctes.

— Bill Morris