Skip to content

spgrass causes segfault

2 messages · Dominik.Cullmann at Forst.bwl.de, Roger Bivand

Original
Dominik.Cullmann at Forst.bwl.de
# 
Dear Roger,
thanks a lot for your immedate help!
I had given that information at the end of the original mail but I'll repeat it, see below.
This works:
Loading required package: spgrass6
Loading required package: sp
Loading required package: rgdal
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 1.5.4, released 2009/01/07
Path to GDAL shared files: /usr/share/gdal15
Loaded PROJ.4 runtime: Rel. 4.6.0, 21 Dec 2007
Path to PROJ.4 shared files: (autodetected)
Loading required package: XML
GRASS GIS interface loaded with GRASS version: 6.4.0RC5
and location: spearfish60
R version 2.9.1 (2009-06-26)
i486-pc-linux-gnu

locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] spgrass6_0.6-6 XML_2.5-3      rgdal_0.6-9    sp_0.9-43

loaded via a namespace (and not attached):
[1] grid_2.9.1      lattice_0.17-25
/home/data/grass/spearfish60/PERMANENT/.tmp/f060/geology has GDAL driver GTiff
and has 140 rows and 190 columns
Well, gdalinfo seems to work fine: 

101:~/$ gdalinfo /home/data/grass/spearfish60/PERMANENT/cellhd/geology
Driver: GRASS/GRASS Database Rasters (5.7+)
Files: /home/data/grass/spearfish60/PERMANENT/cellhd/geology
Size is 190, 140
Coordinate System is `'
Origin = (590000.000000000000000,4928000.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Corner Coordinates:
Upper Left  (  590000.000, 4928000.000)
Lower Left  (  590000.000, 4914000.000)
Upper Right (  609000.000, 4928000.000)
Lower Right (  609000.000, 4914000.000)
Center      (  599500.000, 4921000.000)
Band 1 Block=190x1 Type=Byte, ColorInterp=Palette
  Min=1.000 Max=9.000
  NoData Value=0
  Metadata:
    COLOR_TABLE_RULES_COUNT=0
  Color Table (RGB with 10 entries)
    0: 197,129,125,255
    1: 107,250,75,255
    2: 226,83,250,255
    3: 246,222,188,255
    4: 123,225,27,255
    5: 134,190,1,255
    6: 48,86,221,255
    7: 113,70,15,255
    8: 102,134,101,255
    9: 89,135,169,255
The example I gave was on the 'geology' raster from the spearfish60 data set.
I had given installation details at the end of the original mail: 

104:~/$ cat /etc/debian_version
5.0.2
105:~/$ uname -a
Linux f060 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 i686 GNU/Linux
106:~/$ dpkg -l |grep gdal
ii  gdal-bin                             1.5.4-2    Geospatial Data Abstraction Library - Utility programs
ii  libgdal1-1.5.0                       1.5.4-2    Geospatial Data Abstraction Library
ii  libgdal1-1.5.0-grass                 1.5.2-1    GRASS extension for the Geospatial Data Abstraction Library
ii  libgdal1-dev                         1.5.4-2    Geospatial Data Abstraction Library - Development files
115:~/$ dpkg -l |grep "Cartographic projection"
ii  proj                                 4.6.0-2    Cartographic projection filter and library
...
oh, and I'm using grass version 6.4.0RC5 which I compiled after
configuring via
CFLAGS="-g -Wall" ./configure   --with-opengl=no --with-tcltk-libs=/usr.lib --with-tcltk-includes='/usr/include/tcl8.4/ /usr/include/tk/' --with-tcltk-libs='/usr/lib/tcl8.4/' --with-odbc=yes --with-fftw-libs='/usr/include' -with-gdal='/usr/bin/gdal-config' --with-postgres=yes  --with-postgres-includes='/usr/include/postgresql/' --enable-largefile --with-lapack=yes --with-blas=yes
Yes, it does. Thanks again,
Dominik
----------------------------------------------
Andreas Dominik Cullmann
Forstliche Versuchs- und Forschungsanstalt 
Wonnhalde 4 
79100 Freiburg 
Tel. +49 761 4018 204 
Email: dominik.cullmann at forst.bwl.de <mailto:dominik.cullmann at forst.bwl.de> 
Homepage: www.fva-bw.de <http://www.fva-bw.de>
Roger Bivand
#
On Thu, 23 Jul 2009, Dominik.Cullmann at Forst.bwl.de wrote:

            

      
      
      
    

        
Good, some progress.

            

      
      
      
    

        
There is a newer rgdal, but I don't think that it will affect the raster 
interface.

            

      
      
      
    

        
So it does read the metadata, so the problem must be in the data itself. 
Is it possible that you have binary GDAL 1.5.4, the binary GDAL GRASS 
plugin from GDAL 1.5.2 (so built against an oldish Debian GRASS), and 
GRASS not binary, but built from source, as you detail below, with 
--enable-largefile (which may or may not make a difference). This means 
that the plugin looks for GRASS, and finds some ABI compoments that work, 
but others that fail? The GDAL plugin were not build against your local 
GRASS, and are trying to use its shared objects (*.so files).

To straighten things out, you'd need either to install the binary GRASS 
that matches the plugin exactly, or install GDAL twice from source, first 
configuring without GRASS, then building GRASS, finally rebuilding GDAL 
pointing at the new GRASS to build the plugin. It could be simpler, 
really. Using plugin=FALSE saves the pain, although the raster plugin does 
move data faster in some settings, and the vector one does when there are 
few attributes.

Roger