Menu

#187 Grid file could not be opened.

v2.1.0
closed
nobody
None
1
2014-04-18
2014-04-16
No

The problem is that the *.sgrd files are NOT loaded. The subject of this forum topic "Grid file could not be opened" is exactly what SAGA is printing out as an error every time I am trying to load a grid file.

I imported a geotiff and saved it as a sgrd files 4 files are created:

MaxRate_april_june.mgrd 21 KB
MaxRate_april_june.prj 512 B
MaxRate_april_june.sdat 11.2MB
MaxRate_april_june.sgrd 142 B

I cannot load any of the saved grids. Everything else seems to work. Unfortunately the error is too cryptic to reveal the cause.

I listed all the files that were generated so that you know that I have all the necessary files and that the problem is at load time.
Is there a log file where I can find a more useful debugging message that will help with understanding why the grid file is not loaded?

I tried a pre-compiled version 2.0.8 and I tried a 2.1.2 compiled by me. The behaviour is identical.

I am on Linux 64 bit. The compilation finished with no error and everything else seems to work fine. The files were saved with v2.1.2 compiled locally.

Discussion

  • Volker Wichmann

    Volker Wichmann - 2014-04-17

    Hi,

    loading native SAGA grids should be no problem - so I expect that something is wrong with your own build (as you write that the files were saved with a version you build on your own).

    Difficult to tell what the real problem is without the possibility to have a look at the data. Could you please attach such a dataset to this ticket, or, if this is not possible, provide at least the content of the .sgrd file (this is the header file, you can open it with an editor) here.

     
  • Volker Wichmann

    Volker Wichmann - 2014-04-17

    Ok, thanks - I just had a look at the header file, it is completely corrupted:

    N   = M
    D   = C
    U   = 
    D   = 0
    D   = D
    B   = F
    P   = 628523.5841051601
    P   = 4829427.6644320711
    C   = 1366
    C   = 1073
    C   = 5.0008131203
    Z   = 1.000000
    N   = nan
    T   = F
    

    An error-free header looks like this:

    NAME               = test
    DESCRIPTION        = 
    UNIT               = 
    DATAFILE_OFFSET    = 0
    DATAFORMAT         = FLOAT
    BYTEORDER_BIG      = FALSE
    POSITION_XMIN      = 592698.4631590466
    POSITION_YMIN      = 5288859.3582372423
    CELLCOUNT_X        = 3494
    CELLCOUNT_Y        = 1772
    CELLSIZE           = 0.5000000000
    Z_FACTOR           = 1.000000
    NODATA_VALUE       = -99999.000000
    TOPTOBOTTOM        = FALSE
    

    So there is something wrong with your own build, I would expect it to be an unicode issue. Note that SAGA runs without problems on Linux 64bit, so it must be something with your build configuration. Did you build against wxWidgets 3.0?

     
  • Bogdan Hlevca

    Bogdan Hlevca - 2014-04-17

    yes, I build it against wxWidgets 3.0, which I also build myself because it is not provided yet for Suse 13.1.

    Do you think that the problem is wxWidgets of SAGA itself?

    I attached the configure script for wxWidgets. Basically I enabled everything and left out STL as Saga would not compile with that due to wide character conversion issues.

    Saga was configured with ./configure -enable-python

     
  • Volker Wichmann

    Volker Wichmann - 2014-04-17

    Huh, didn't look at your wxWidgets configure call in detail, but this should be enough (and --enable-unicode is missing in your call):

    ./configure --enable-unicode
    

    Nevertheless, the CodeLite project provides wxWidgets packages for OpenSuse 13.1, so maybe it is easier to use these:

    http://codelite.org/LiteEditor/WxWidgets30Binaries#toc1

     
  • Bogdan Hlevca

    Bogdan Hlevca - 2014-04-17

    I though that the --enable-unicode is useless as stated in the compile from source section on the SAGA website ( for 2.1.0 and up) . I compile the trunk code.

    In addition get this warning when I run configure with that option:

    configure: WARNING: unrecognized options: --enable-unicode

     
  • Volker Wichmann

    Volker Wichmann - 2014-04-17

    We are talking about the configure call of wxWidgets and not of SAGA. With SAGA 2.1.0 and newer, the --enable-unicode flag has been removed as we always built with unicode. But SAGA requires a wxWidgets build with unicode enabled. So please try to add --enable-unicode to your wxWidgets configure call or use the available packages.

     
  • Bogdan Hlevca

    Bogdan Hlevca - 2014-04-17

    Oh, I though you were talking about the line I wrote about the SAGA config.
    I will add that option in the wxWidgets config. It would be nice if you can add some compile instructions for wxWidgets that are mandatory for SAGA and also add the link to pre-compiled binaries for wxWidgets

    I'll let you know how it goes. Thanks

     
  • Bogdan Hlevca

    Bogdan Hlevca - 2014-04-17

    I recompiled wxWidgets witl --enable-unicode and it did not work either. Actually, the configure script has only the --disable-unicode option. I assume that the default is unicode enabled. Therefore, I don't think this is it.

    I downloaded the libs from your link and recompiled saga and now it works, so obviously the wx libs are at fault. I am wondering what is wrong with the libs I compiled, what is SAGA expecting there and I have not enabled or maybe I shouldn't have enabled?

     
  • Volker Wichmann

    Volker Wichmann - 2014-04-18

    Good to hear that it is working with the pre-built wxWidgets packages. Regarding the configure call of wxWidgets I am not sure - the last time I built wxWidgets myself I had to use the --enable-unicode flag, but this was with wx 2.9.4 - seems like it is now the default with wx 3.0. So I would expect that just running ./configure would be sufficient.

     
  • Volker Wichmann

    Volker Wichmann - 2014-04-18
    • status: open --> closed
     

Anonymous
Anonymous

Add attachments
Cancel