8

I'm using the (awesome!) processing toolbox in QGIS 2.0 to reclassify some NoData values in a raster from -9999 to 0, but at some point in the process there's an offset of about 0.2 degrees being introduced to the output layer.

I'm using the "Reclassify (Simple)" tool (I believe it's part of SAGA), with some pretty basic parameters:

reclassify parameters

. . . and where the input raster was situated correctly in comparison to this hex grid:

input raster

. . . the output raster is bumped southeast by two hex cells, or about 0.2 degrees:

enter image description here

The input origin is -180, 83.623 . . . but the output origin is -179.05,83.05. Normally I would assume this is the result of a faulty WGS84 conversion, but the input, output and project are all EPSG:4326.

Where is this origin offset coming from, and is it worth filing a SAGA ticket or is it just something I overlooked?

Update The process log indicates a transformation is performed on the input origin:

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

and then a few lines later the new parameters show up, now incorrect:

Grid system: 0.1; 3600x 1735y; -179.949989x -89.826875y
  • 1
    you should test the native SAGA tool using the GUI or the CLI and see if you get the same result. – Giovanni Manghi Dec 31 '13 at 16:46
  • 1
    Too many error dead ends from these install docs on my machine - I'm not interested in wiping my current GDAL/PROJ configuration just to test SAGA natively. – Bill Morris Dec 31 '13 at 17:18
  • 1
    If you are using SAGA in QGIS then SAGA is already installed in your machine. – Giovanni Manghi Jan 1 '14 at 7:51
  • After more than 2 hours of poring over the docs, I have not the faintest idea of HOW TO LAUNCH THE GUI IN OSX. The documentation is reminiscent of R in all the bad ways. No variation on "saga" (-gis,-gui, etc.) produces anything at the command line, and compiling from source returns completely unhelpful errors. Thank the merciful heavens (core devs, that is) that this mess is now accessible by humans in a QGIS sidebar. I sincerely hope that SAGA is not what's changing my raster output origin, because I will never be able to debug it. – Bill Morris Jan 8 '14 at 22:47
  • Are you able to launch saga with saga_gui command instead? – SaultDon Jan 9 '14 at 1:51
1
+50

Your offset is 1/2 a pixel (0.1 degrees).

Longitude:

-179.999989 - -179.949989 = 0.05

Latitude is less obvious because one grid is referenced from top left, the other from bottom left:

83.623125 - (1735 * 0.1) - -89.826875 = 0.05

I'm guessing this relates to the RasterPixelIsPoint or RasterPixelIsArea problem:

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

Are you using gdal 1.7 or 1.8?

  • System-wide I've got GDAL 1.10.1; for whatever reason I can't get the QGIS python console to report the version used there – Bill Morris Jan 16 '14 at 20:37
  • it looks far more than 1/2 pixel on the image. – radouxju Jan 16 '14 at 21:05
  • It is, but pixel size is off too. Here's the gdalinfo for both the input and output tiffs – Bill Morris Jan 16 '14 at 21:48
  • Ah, seeing the gdalinfo it looks like the shift is .95 and -0.5731265. The 1/2 pixel shift above is probably a correct area to point conversion. Your original raster has some odd bounds, maybe they're screwing up the conversion. – Marc Pfister Jan 16 '14 at 22:15
  • Good point. Odd that it's hanging off the edge of the world by a degree. The raster is the result of a conversion from vector; let me see if I can redo that conversion with correct bounds. – Bill Morris Jan 17 '14 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.