Opened 8 years ago

Closed 7 years ago

#527 closed defect (fixed)

Broken io_gdal raster import in SAGA LTR package shipped with OSGeo4W

Reported by: lutra Owned by: osgeo4w-dev@…
Priority: major Component: Package
Version: Keywords:
Cc:

Description

1) In OSGeo4w installer the option for SAGA LTR says "2.3.1", but once installed "saga_cmd" says 2.3.2, which is weird per se as SAGA 2.3.2 does not exist:

https://sourceforge.net/projects/saga-gis/files/SAGA%20-%202.3/

2) if launching SAGA GUI of this SAGA installation it apparently seems all ok, but for instance it misses the "Import > GDAL/OGR" tools which are available in any older and newer (or even the same) versions downloaded from SAGA site. This could be related to the next point, that is the more important

3) In this OSGEo4W SAGA LTR install the raster import operation (done with the "io_gdal" module) produces a WRONG raster, where 1 are replaced with NULLs. This DOES NOT happen in any older and newer (or even the same) versions downloaded from SAGA site. This is of course a deal breaker for Processing because it calls io_gdal any time a SAGA raster tool is used

You can test with this input

https://cld.pt/dl/download/6ac21f8c-0244-45a5-823e-6047bb99b208/bacias_lee_2014_2018_17_Binary.tif

and this command

saga_cmd io_gdal 0 -TRANSFORM 1 -RESAMPLING 0 -GRIDS "imported_raster.sgrd" -FILES "bacias_lee_2014_2018_17_Binary.tif"

Change History (6)

comment:1 by jef, 8 years ago

  1. saga_api.h:132 from the 2.3 LTS branch labels it 2.3.2.
  2. Import/Export > GDAL/OGR shows up in the GUI here (started through the shortcut or saga_gui-ltr.bat).
  3. Not sure what to expect from bacias_lee_2014_2018_17_Binary.tif. Looks ok in the SAGA GUI (except it shows colored in 2.3 and b/w in 2.1). Running the command produces a sgrd that apparently corresponds to the tif version.

comment:3 by PedroNGV, 8 years ago

Hi Jurgen,

Please test the sample file like this, running SAGA - Raster Calculator:

The purpose of this exercise is to pass the original raster to integer. When I do this in SAGA 2.3.2, pixels with value 1, go to nodata.

Using SAGA 2.3.2 GUI, I get the correct result (value 1). Same with SAGA 2.1.2.

So,

  • On Linux, with SAGA 2.3.1 (Processing / GUI), it works well;
  • On OSGeo4W, with SAGA 2.1.2 (Processing / GUI), it works well;
  • On OSGeo4W, with SAGA 2.3.2 (GUI), it works well;
  • On OSGeo4W, with SAGA 2.3.2 (Processing), it transforms the pixels with value 1, to nodata.

The problem seems to be on the import:

saga_cmd io_gdal 0 -TRANSFORM 1 -RESAMPLING 0 -GRIDS "C:\Users\PEDROV~1\AppData\Local\Temp\processing90929a3e1d31404aa51feebd7c521934\ec68105add63416faad3d24810a830a5\baciaslee2014201817Binary.sgrd" -FILES "D:\bacias_lee_2014_2018_17_Binary.tif"

since the temporary file baciaslee2014201817Binary.sdat have the pixels with value 1 transformed to nodata.

This occurs both on QGIS/Processing and on osgeo4w shell.

comment:4 by jef, 7 years ago

saga-ltr-2.3.2-1 should fix it.

comment:5 by PedroNGV, 7 years ago

I confirm Jurgen, it's solved now!

Thank you very much!!!

comment:6 by jef, 7 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.