Patch for GDAL-GRASS plugin for GRASS 7

[Markus Neteler]

I have patched GDAL to compile against GRASS 7 (attached). However, the removal of the no longer existing libraries should be conditionalized to still permit the compilation against GRASS 6. I just dunno how to implement that (no autoconf guru).

[Markus Neteler]

patch to compile GDAL-GRASS plugin against GRASS 7

[Even Rouault]

In r16813 I've commited a version that enables building against GRASS 7 and older versions as well.

Grass enhancement request : it would be cool if GRASS had a grass-config script.

[hamish]

Replying to rouault:

In r16813 I've commited a version that enables building against GRASS 7 and older versions as well.

is this still functional? ISTR we recently got a report that changes in grass trunk (7) had broken it.

Grass enhancement request : it would be cool if GRASS had a grass-config script.

here's the ticket for that wish:

​https://trac.osgeo.org/grass/ticket/596

Hamish

[Even Rouault]

r20157 /trunk/gdal/ (6 files in 3 dirs): Update GDAL and OGR GRASS drivers to compile against GRASS 7.0SVN (it compiles, but autotest gdrivers/grass.py and ogr/ogr_grass.py fail). Backward compatibility with GRASS 6.X preserved (#2953)

[wolf]

Patch to use grass-config from ​https://trac.osgeo.org/grass/ticket/596

[wolf]

Added a patch to use grass-config from ​https://trac.osgeo.org/grass/ticket/596. Works on trunk.

[dylan]

I have tried both patches to GDAL trunk (as of r23215) and neither can be applied cleanly (failed hunks). Is the strategy for getting GRASS7 support in GDAL enabled with the "--with-grass" flag when compiling GDAL, or with the grass-gdal plugin? I cannot get the grass-gdal plugin to compile after removing all grass6 files, and installing grass7. I have updated my ld.so.conf to reflect these changes, but still get:

./configure --with-grass=/usr/local/grass-7.0.svn/
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for ranlib... ranlib
checking for g++ -shared ... yes
checking for gdal-config... /usr/local/bin/gdal-config
using /usr/local/lib/gdalplugins as GDAL shared library autoload directory
checking for G_asprintf in -lgrass_gis... no
configure: error: --with-grass=/usr/local/grass-7.0.svn/ requested, but libraries not found!

[Even Rouault]

I think the grass-gdal plugin is the way to go, but there hasn't been any activity recently, so it might not work either as grass7 must be still a moving target I imagine. CC'ing Martin Landa who has declared the GRASS driver as area of interest ;-)

[kalxas]

Hi all,

Any progress on this issue? Has anyone had success building against current grass7 trunk?

Regards, Angelos

[Even Rouault]

Reopening the ticket. Any volunteer ?

[pvanbosgeo]

Hi, any development in this regard? GRASS 7.0 seems fairly stable for most work, so it would be great if the grass-gdal plugin could be made compatible with grass 7.0. I can't program, but I would be happy to test.

[Markus Neteler]

I just tried with GRASS 7.svn and this part went through properly:

[neteler@north gdal-1.9]$ ./configure --with-grass=/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/
...
checking for PostgreSQL... no
checking for G_asprintf in -lgrass_gis... yes
checking for ffopen in -lcfitsio... no
...
GDAL is now configured for x86_64-unknown-linux-gnu
...
  GRASS support:             grass57+
...

Essential (in fact small) updates are:

• /usr/bin/ld: cannot find -lgrass_vect --> the GRASS7 name is 'grass_vector'
• /usr/bin/ld: cannot find -lgrass_I --> the GRASS7 name is 'grass_imagery'
• /usr/bin/ld: cannot find -lgrass_vask --> no longer exists in GRASS7

This would require to be conditionalized in the Makefile upon the GRASS version.

[martinl]

Replying to rouault:

I think the grass-gdal plugin is the way to go, but there hasn't been any activity recently, so it might not work either as grass7 must be still a moving target I imagine. CC'ing Martin Landa who has declared the GRASS driver as area of interest ;-)

that's right, sorry I am super-busy with other important stuff. I will do my best to look at this issue too.

[hamish]

Replying to neteler:

This would require to be conditionalized in the Makefile upon the GRASS version.

i.e. in include/grass/version.h test against GRASS_VERSION_MAJOR == 6 (or 7).

Hamish

[kalxas]

FYI, I am getting requests for gdal support for grass7 in openSUSE.

​https://bugzilla.novell.com/show_bug.cgi?id=723890

[martinl]

Compilation issues fixed in r26318 + r26320. Martin

[sbl]

Replying to martinl:

Compilation issues fixed in r26318 + r26320. Martin

I just tried to compile GDAL (rev 26701) against GRASS 7 (rev 58438) on Ubunut Server 12.04 with unfortunately various results. It seems that the gdal-grass-plugin did not receive any updates since 2007 (latest version on ​http://download.osgeo.org/gdal/ is 1.4.3, last modified 05-Aug-2007). So I rebuild GDAL after compiling GRASS 7 (instead of using the plugin). After that, gdalinfo --formats gave:

Supported Formats:
  GRASS (ro):

No vesion information was given.

gdal_translate with GRASS raster datasets as input worked, but gave warning:

 Warning 1: GRASS warning: GISBASE enviroment variable was not set, using:
  /usr/local/grass-7.0.svn

However, raster2pgsql from PostGIS 2.1.2 gave error messages when I try to feed GRASS raster:

Segmentation fault (core dumped)" 

After I removed "/usr/local/grass-6.4.4svn/lib" from /etc/ld.so.conf error messages changed to:

ERROR 1: libgrass_I.so: cannot open shared object file: No such file or directory
*** glibc detected *** raster2pgsql: corrupted double-linked list: 
0x00000000012e59f0 ***

To me it looks like GDAL is using a mixture of GRASS 6 and GRASS 7, becaus it said it was using GRASS 7 GISBASE but was looking for libgrass_I.so (wich is GRASS 6 specific I think?). See also: ​http://lists.osgeo.org/pipermail/grass-dev/2013-December/066608.html for discussion on grass-dev mailinglist.

[larrysh]

Hi,

I would be interested in helping on getting this functioning, now that the GRASS 7 beta1 is out.

The patches attached here are outdated, but it looks like there is GRASS support in 1.10 already, just not in the plugin, yet.

[Even Rouault]

The potential changes are to be done in frmts/grass/grassdataset.cpp, GDAL's configure.in (root of source tree) and plugin configure.in in frmts/grass/pkg

[martinl]

Replying to rouault:

The potential changes are to be done in frmts/grass/grassdataset.cpp, GDAL's configure.in (root of source tree) and plugin configure.in in frmts/grass/pkg

The configure script should detect GRASS 7 already correctly

 GRASS support:             grass70+

On the rest I will try take a look ASAP.

[martinl]

Replying to sbl:

gdal_translate with GRASS raster datasets as input worked, but gave warning:

 Warning 1: GRASS warning: GISBASE enviroment variable was not set, using:
  /usr/local/grass-7.0.svn

that's absolutely OK, it's just a warning that GDAL will use the version of GRASS which was used when building GDAL. If you want to use different version of GRASS, you can define it by GISBASE variable. Anyway this warning is probably misleading. The driver should probably check if GRASS_GISBASE exists on local machine and if not found than fail with error message: "Default GISBASE (%s) not found, you need to define GISBASE environmental variable which points to your GRASS installation". What do you think?

[sbl]

Replying to martinl:

Replying to sbl:

gdal_translate with GRASS raster datasets as input worked, but gave warning:

 Warning 1: GRASS warning: GISBASE enviroment variable was not set, using:
  /usr/local/grass-7.0.svn

that's absolutely OK, it's just a warning that GDAL will use the version of GRASS which was used when building GDAL. If you want to use different version of GRASS, you can define it by GISBASE variable. Anyway this warning is probably misleading. The driver should probably check if GRASS_GISBASE exists on local machine and if not found than fail with error message: "Default GISBASE (%s) not found, you need to define GISBASE environmental variable which points to your GRASS installation". What do you think?