Dear GRASS users,
Please can you point me to the source code of libgrass? I would like to
use it within UMN Mapserver environment and can not find it so far.
Thanks,
Rado
--
Radoslav Bonk
European Commission - DG Joint Research Centre (JRC)
Institute of Environment and Sustainability (IES)
LM Unit - Natural Hazards
Via E. Fermi, TP 261, 210 20 Ispra (VA), ITALY
tel: 0039 0332 78 6013
fax: 0039 0332 78 6653
http://natural-hazards.jrc.it/floods
On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
Dear GRASS users,
Please can you point me to the source code of libgrass? I would like to
use it within UMN Mapserver environment and can not find it so far.
Hi Rado,
libgrass is available here (GRASS CVS):
http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/
there is a "download tarball" link at bottom.
But the recommended method is to use the GDAL/GRASS
plugin. Compilation order:
- GDAL without GRASS support (you may have to actively disable
it using the appropriate configure switches)
- GRASS 6
- GDAL/GRASS plugin
Configure scripts can be grabbed here:
http://mpa.itc.it/markus/useful/index.html
-> conf_gdal.sh
-> conf_grass61_linux.sh
-> conf_install_gdal_grass_plugin.sh
Markus
On Fri, 29 Apr 2005, Markus Neteler wrote:
On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
> Dear GRASS users,
>
> Please can you point me to the source code of libgrass? I would like to
> use it within UMN Mapserver environment and can not find it so far.Hi Rado,
libgrass is available here (GRASS CVS):
http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/
there is a "download tarball" link at bottom.But the recommended method is to use the GDAL/GRASS
plugin. Compilation order:- GDAL without GRASS support (you may have to actively disable
it using the appropriate configure switches)
- GRASS 6
- GDAL/GRASS pluginConfigure scripts can be grabbed here:
http://mpa.itc.it/markus/useful/index.html-> conf_gdal.sh
-> conf_grass61_linux.sh
-> conf_install_gdal_grass_plugin.sh
Well, after having done this, and:
$ ls -l /usr/local/lib/gdalplugins
total 36
-rwxr-xr-x 1 root root 34606 Apr 29 14:32 gdal_GRASS.so
(the script presupposes that the user running it has access to
gdalplugins)
I still can't see any access:
$ gdalinfo ~/topics/grassdata/spearfish60/PERMANENT/cellhd/geology
ERROR 4: `/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology'
not recognised as a supported file format.
GDALOpen failed - 4
`/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology' not
recognised as a supported file format.
Does GDAL look in gdalplugins by itself? Does it need ldconfig too?
Roger
Markus
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no
On Fri, Apr 29, 2005 at 02:45:21PM +0200, Roger Bivand wrote:
On Fri, 29 Apr 2005, Markus Neteler wrote:
> On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
...
> But the recommended method is to use the GDAL/GRASS
> plugin. Compilation order:
>
> - GDAL without GRASS support (you may have to actively disable
> it using the appropriate configure switches)
> - GRASS 6
> - GDAL/GRASS plugin
>
> Configure scripts can be grabbed here:
> http://mpa.itc.it/markus/useful/index.html
>
> -> conf_gdal.sh
> -> conf_grass61_linux.sh
> -> conf_install_gdal_grass_plugin.shWell, after having done this, and:
$ ls -l /usr/local/lib/gdalplugins
total 36
-rwxr-xr-x 1 root root 34606 Apr 29 14:32 gdal_GRASS.so(the script presupposes that the user running it has access to
gdalplugins)
Well, the plugin has to be installed along with GDAL. So
probably root permissions are needed.
I still can't see any access:
$ gdalinfo ~/topics/grassdata/spearfish60/PERMANENT/cellhd/geology
ERROR 4: `/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology'
not recognised as a supported file format.
OK - a couple of tests:
- which GDAL version are you using? The search patch changed.
If you have an "older" GDAL, try to move the plugin to
/usr/local/lib/ (where libgdal.so stays)
- if this works, congrats (keep in mind that /usr/[local/]lib/gdalplugins
is the new home
- if this doesn't work, move the gdal_GRASS.so back to
/usr/local/lib/gdalplugins/
- then
ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
Does it find the GRASS libraries? If not,
- either add their path to /etc/ld.so.conf
- or link the GRASS libs into /usr/local/lib (this is what I do)
Positive side-effect: also QGIS is happy
Hope this helps
Markus
On Fri, 29 Apr 2005, Markus Neteler wrote:
On Fri, Apr 29, 2005 at 02:45:21PM +0200, Roger Bivand wrote:
> On Fri, 29 Apr 2005, Markus Neteler wrote:
> > On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
...
> > But the recommended method is to use the GDAL/GRASS
> > plugin. Compilation order:
> >
> > - GDAL without GRASS support (you may have to actively disable
> > it using the appropriate configure switches)
> > - GRASS 6
> > - GDAL/GRASS plugin
> >
> > Configure scripts can be grabbed here:
> > http://mpa.itc.it/markus/useful/index.html
> >
> > -> conf_gdal.sh
> > -> conf_grass61_linux.sh
> > -> conf_install_gdal_grass_plugin.sh
>
> Well, after having done this, and:
>
> $ ls -l /usr/local/lib/gdalplugins
> total 36
> -rwxr-xr-x 1 root root 34606 Apr 29 14:32 gdal_GRASS.so
>
> (the script presupposes that the user running it has access to
> gdalplugins)Well, the plugin has to be installed along with GDAL. So
probably root permissions are needed.
Yes, but then two scripts would be needed, one for ./configure and make,
one for make install ...
> I still can't see any access:
>
> $ gdalinfo ~/topics/grassdata/spearfish60/PERMANENT/cellhd/geology
> ERROR 4: `/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology'
> not recognised as a supported file format.OK - a couple of tests:
- which GDAL version are you using? The search patch changed.
If you have an "older" GDAL, try to move the plugin to
/usr/local/lib/ (where libgdal.so stays)
1.2.6 from the tarball compiled 29 April, is this "older"?
- if this works, congrats (keep in mind that /usr/[local/]lib/gdalplugins
is the new home
It doesn't work.
- if this doesn't work, move the gdal_GRASS.so back to
/usr/local/lib/gdalplugins/- then
ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
Does it find the GRASS libraries? If not,
No, it didn't find them.
- either add their path to /etc/ld.so.conf
- or link the GRASS libs into /usr/local/lib (this is what I do)
I did this, ldd reports that they are present (after an ldconfig), but
gdalinfo still doesn't recognise the file in cellhd (neither inside nor
outside GRASS).
Do I need to re-install GDAL after having configured, built and installed
the plugin (I think not)?
I'm keeping on about this because if this is this difficult to configure
for me, then the chances of any R/GRASS interface for GRASS 6 get very
slim - there are so many hoops to jump though even on Unix/Linux (not to
mention cygwin?) that no-one will ever use it.
There do not seem to have been any downloads of the draft package from
sourceforge http://sourceforge.net/projects/r-spatial/ so far, so I've no
idea of whether any of this is actually required. GDAL and OGR provide
ways to prototype the interface cleanly. But then GDAL has to work both
ways, otherwise I can just stay with Arc ASCII grid files.
What will help is a fool-proof installation route for getting r.out.gdal
to work like v.out.ogr does - I've no idea how the GDAL programs are
supposed to find the plugin (I can understand that they know about formats
they were compiled with, but how should a plugin be regisered in GDAL if
is is built after GDAL itself?).
Trying,
Roger
Positive side-effect: also QGIS is happy
Hope this helps
Markus
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no
On Fri, Apr 29, 2005 at 06:31:20PM +0200, Roger Bivand wrote:
On Fri, 29 Apr 2005, Markus Neteler wrote:
> On Fri, Apr 29, 2005 at 02:45:21PM +0200, Roger Bivand wrote:
> > On Fri, 29 Apr 2005, Markus Neteler wrote:
> > > On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
> ...
> > > But the recommended method is to use the GDAL/GRASS
> > > plugin. Compilation order:
> > >
> > > - GDAL without GRASS support (you may have to actively disable
> > > it using the appropriate configure switches)
> > > - GRASS 6
> > > - GDAL/GRASS plugin
> > >
> > > Configure scripts can be grabbed here:
> > > http://mpa.itc.it/markus/useful/index.html
> > >
> > > -> conf_gdal.sh
> > > -> conf_grass61_linux.sh
> > > -> conf_install_gdal_grass_plugin.sh
> >
> > Well, after having done this, and:
> >
> > $ ls -l /usr/local/lib/gdalplugins
> > total 36
> > -rwxr-xr-x 1 root root 34606 Apr 29 14:32 gdal_GRASS.so
> >
> > (the script presupposes that the user running it has access to
> > gdalplugins)
>
> Well, the plugin has to be installed along with GDAL. So
> probably root permissions are needed.Yes, but then two scripts would be needed, one for ./configure and make,
one for make install ...
Yes.
I didn't intend to provide all-in-one solutions - moreover
the suggested scripts are an offer to figure out the parameters.
>
>
> > I still can't see any access:
> >
> > $ gdalinfo ~/topics/grassdata/spearfish60/PERMANENT/cellhd/geology
> > ERROR 4: `/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology'
> > not recognised as a supported file format.
>
> OK - a couple of tests:
>
> - which GDAL version are you using? The search patch changed.
> If you have an "older" GDAL, try to move the plugin to
> /usr/local/lib/ (where libgdal.so stays)
>1.2.6 from the tarball compiled 29 April, is this "older"?
The GDAL ChangeLog says:
2005-04-22 15:40 fwarmerdam
* frmts/grass/pkg/configure.in: Default for autoload path is
$prefix/lib/gdalplugins now.
Do you have 1.2.6 or 1.2.6-CVS? 1.2.6 was released in March, so it's older.
The current CVS is using the new scheme.
> - if this works, congrats (keep in mind that /usr/[local/]lib/gdalplugins
> is the new homeIt doesn't work.
So you seem to have a "new" GDAL.
> - if this doesn't work, move the gdal_GRASS.so back to
> /usr/local/lib/gdalplugins/
>
> - then
> ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
>
> Does it find the GRASS libraries? If not,No, it didn't find them.
OK, we are close:
> - either add their path to /etc/ld.so.conf
> - or link the GRASS libs into /usr/local/lib (this is what I do)I did this, ldd reports that they are present (after an ldconfig), but
gdalinfo still doesn't recognise the file in cellhd (neither inside nor
outside GRASS).
Here it will not (!) be listed as the plugin is loaded run-time:
ldd `which gdalinfo` | grep grass | wc -l
0
Correct value.
Do you get this number of GRASS libs?:
ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
6
Do I need to re-install GDAL after having configured, built and installed
the plugin (I think not)?
No.
I'm keeping on about this because if this is this difficult to configure
for me, then the chances of any R/GRASS interface for GRASS 6 get very
slim - there are so many hoops to jump though even on Unix/Linux (not to
mention cygwin?) that no-one will ever use it.There do not seem to have been any downloads of the draft package from
sourceforge http://sourceforge.net/projects/r-spatial/ so far, so I've no
I have added the link only last week to the GRASS site (unfortunately
no other developer did it). So probably nobody was aware of it.
I have downloaded it, so there must be at least 1 hit.
Testing forthcoming. In fact I'll need ot soon, so I'll spend
time on that.
idea of whether any of this is actually required. GDAL and OGR provide
ways to prototype the interface cleanly. But then GDAL has to work both
ways, otherwise I can just stay with Arc ASCII grid files.What will help is a fool-proof installation route for getting r.out.gdal
to work like v.out.ogr does
The "easy" solution is to write r.out.gdal in C. A long-standing wish...
- I've no idea how the GDAL programs are
supposed to find the plugin (I can understand that they know about formats
they were compiled with, but how should a plugin be regisered in GDAL if
is is built after GDAL itself?).
http://xserve.flids.com/pipermail/gdal-dev/2005-March/008227.html
"It is documented deep in the api ref docs at:
http://www.gdal.org/classGDALDriverManager.html#a8
"
Good luck!
Markus
On Fri, 29 Apr 2005, Markus Neteler wrote:
On Fri, Apr 29, 2005 at 06:31:20PM +0200, Roger Bivand wrote:
> On Fri, 29 Apr 2005, Markus Neteler wrote:
>
> > On Fri, Apr 29, 2005 at 02:45:21PM +0200, Roger Bivand wrote:
> > > On Fri, 29 Apr 2005, Markus Neteler wrote:
> > > > On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
> > ...
> > > > But the recommended method is to use the GDAL/GRASS
> > > > plugin. Compilation order:
> > > >
> > > > - GDAL without GRASS support (you may have to actively disable
> > > > it using the appropriate configure switches)
> > > > - GRASS 6
> > > > - GDAL/GRASS plugin
> > > >
> > > > Configure scripts can be grabbed here:
> > > > http://mpa.itc.it/markus/useful/index.html
> > > >
> > > > -> conf_gdal.sh
> > > > -> conf_grass61_linux.sh
> > > > -> conf_install_gdal_grass_plugin.sh
> > >
> > > Well, after having done this, and:
> > >
> > > $ ls -l /usr/local/lib/gdalplugins
> > > total 36
> > > -rwxr-xr-x 1 root root 34606 Apr 29 14:32 gdal_GRASS.so
> > >
> > > (the script presupposes that the user running it has access to
> > > gdalplugins)
> >
> > Well, the plugin has to be installed along with GDAL. So
> > probably root permissions are needed.
>
> Yes, but then two scripts would be needed, one for ./configure and make,
> one for make install ...Yes.
I didn't intend to provide all-in-one solutions - moreover
the suggested scripts are an offer to figure out the parameters.
Accepted.
> >
> >
> > > I still can't see any access:
> > >
> > > $ gdalinfo ~/topics/grassdata/spearfish60/PERMANENT/cellhd/geology
> > > ERROR 4: `/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology'
> > > not recognised as a supported file format.
> >
> > OK - a couple of tests:
> >
> > - which GDAL version are you using? The search patch changed.
> > If you have an "older" GDAL, try to move the plugin to
> > /usr/local/lib/ (where libgdal.so stays)
> >
>
> 1.2.6 from the tarball compiled 29 April, is this "older"?The GDAL ChangeLog says:
2005-04-22 15:40 fwarmerdam
* frmts/grass/pkg/configure.in: Default for autoload path is
$prefix/lib/gdalplugins now.Do you have 1.2.6 or 1.2.6-CVS? 1.2.6 was released in March, so it's older.
The current CVS is using the new scheme.
I have the 1.2.6 release - I find the difficulties of interfacing multiple
changing codebases from CVS too great to be worth the trouble - keeping
all but one as released restricts blunders to my own code.
> > - if this works, congrats (keep in mind that /usr/[local/]lib/gdalplugins
> > is the new home
>
> It doesn't work.So you seem to have a "new" GDAL.
> > - if this doesn't work, move the gdal_GRASS.so back to
> > /usr/local/lib/gdalplugins/
> >
> > - then
> > ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
> >
> > Does it find the GRASS libraries? If not,
>
> No, it didn't find them.OK, we are close:
> > - either add their path to /etc/ld.so.conf
> > - or link the GRASS libs into /usr/local/lib (this is what I do)
>
> I did this, ldd reports that they are present (after an ldconfig), but
> gdalinfo still doesn't recognise the file in cellhd (neither inside nor
> outside GRASS).Here it will not (!) be listed as the plugin is loaded run-time:
ldd `which gdalinfo` | grep grass | wc -l
0
Correct value.
$ ldd `which gdalinfo` | grep grass | wc -l
0
Do you get this number of GRASS libs?:
ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
6
$ ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
5
> Do I need to re-install GDAL after having configured, built and installed
> the plugin (I think not)?No.
So now on one of two RHEL 3 machines, it works, on the other not (but
maybe I need another ldconfig ...)
Thanks so far, it can be done, but it doesn't feel easy. Does r.out.gdal
work under cygwin?
> I'm keeping on about this because if this is this difficult to configure
> for me, then the chances of any R/GRASS interface for GRASS 6 get very
> slim - there are so many hoops to jump though even on Unix/Linux (not to
> mention cygwin?) that no-one will ever use it.
>
> There do not seem to have been any downloads of the draft package from
> sourceforge http://sourceforge.net/projects/r-spatial/ so far, so I've noI have added the link only last week to the GRASS site (unfortunately
no other developer did it). So probably nobody was aware of it.I have downloaded it, so there must be at least 1 hit.
Testing forthcoming. In fact I'll need ot soon, so I'll spend
time on that.
Great, (sourceforge do warn that the counter isn't reliable). An example
of the use of the spgrass6 package is on http://r-spatial.sourceforge.net,
"sp and other packages" on the navigation bar on the left. The CVS code is
the freshest, but at least now sp is released and on CRAN, so the classes
used for holding data within R are becoming stable.
> idea of whether any of this is actually required. GDAL and OGR provide
> ways to prototype the interface cleanly. But then GDAL has to work both
> ways, otherwise I can just stay with Arc ASCII grid files.
>
> What will help is a fool-proof installation route for getting r.out.gdal
> to work like v.out.ogr doesThe "easy" solution is to write r.out.gdal in C. A long-standing wish...
Well, yes and no, because faster machines and discs are making scripted
loose coupling less of a problem time-wise. One problem I see with the
present script is that r.out.gdal seems to ignore the current region:
GRASS 6.0.0 (spearfish57):~ > g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928010
south: 4913700
west: 589980
east: 609000
nsres: 30
ewres: 30
rows: 477
cols: 634
GRASS 6.0.0 (spearfish57):~ > r.out.gdal soils type=Byte output=tmp/soils.tiff
Writing format: GTiff
Writing type: Byte
Input file size is 950, 700
0...10...20...30...40...50...60...70...80...90...100 - done.
GRASS 6.0.0 (spearfish57):~ > gdalinfo tmp/soils.tiff | grep "^Size"
Size is 950, 700
This differs from, for example, r.out.arc, which is what the draft
interface is using now. Is the only answer to use another operation to
resample first, then output through r.out.gdal - by the way, the same
applies to using rgdal within R to read from GRASS directly?
Thanks for your patience!
Roger
> - I've no idea how the GDAL programs are
> supposed to find the plugin (I can understand that they know about formats
> they were compiled with, but how should a plugin be regisered in GDAL if
> is is built after GDAL itself?).http://xserve.flids.com/pipermail/gdal-dev/2005-March/008227.html
"It is documented deep in the api ref docs at:
http://www.gdal.org/classGDALDriverManager.html#a8
"Good luck!
Markus
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no
On Sat, Apr 30, 2005 at 11:03:32AM +0200, Roger Bivand wrote:
...
I have the 1.2.6 release - I find the difficulties of interfacing multiple
changing codebases from CVS too great to be worth the trouble - keeping
all but one as released restricts blunders to my own code.
Just a naive question:
Why do you need the GDAL/GRASS plugin for the R interface?
To test if R-gdal is an alternative to read GRASS data?
...
> Do you get this number of GRASS libs?:
> ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
> 6$ ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
5
I have
ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
libgrass_I.so => /usr/local/lib/libgrass_I.so (0x4001f000)
libgrass_vask.so => /usr/local/lib/libgrass_vask.so (0x4002f000)
libgrass_gmath.so => /usr/local/lib/libgrass_gmath.so (0x40035000)
libgrass_gis.so => /usr/local/lib/libgrass_gis.so (0x4003b000)
libgrass_datetime.so => /usr/local/lib/libgrass_datetime.so (0x400c0000)
libgrass_gproj.so => /usr/local/lib/libgrass_gproj.so (0x400c8000)
> > Do I need to re-install GDAL after having configured, built and installed
> > the plugin (I think not)?
>
> No.So now on one of two RHEL 3 machines, it works, on the other not (but
maybe I need another ldconfig ...)
I am working on RH7, RHEL 3 and Mdk10.0. Works everywhere.
What is your "other" machine?
Thanks so far, it can be done, but it doesn't feel easy.
Suggestions to improve things are always welcome.
Does r.out.gdal work under cygwin?
Never tested, I have no idea. It should 
> > I'm keeping on about this because if this is this difficult to configure
> > for me, then the chances of any R/GRASS interface for GRASS 6 get very
> > slim - there are so many hoops to jump though even on Unix/Linux (not to
> > mention cygwin?) that no-one will ever use it.
> >
> > There do not seem to have been any downloads of the draft package from
> > sourceforge http://sourceforge.net/projects/r-spatial/ so far, so I've no
>
> I have added the link only last week to the GRASS site (unfortunately
> no other developer did it). So probably nobody was aware of it.
>
> I have downloaded it, so there must be at least 1 hit.
> Testing forthcoming. In fact I'll need ot soon, so I'll spend
> time on that.Great, (sourceforge do warn that the counter isn't reliable). An example
of the use of the spgrass6 package is on http://r-spatial.sourceforge.net,
"sp and other packages" on the navigation bar on the left. The CVS code is
the freshest, but at least now sp is released and on CRAN, so the classes
used for holding data within R are becoming stable.>
> > idea of whether any of this is actually required. GDAL and OGR provide
> > ways to prototype the interface cleanly. But then GDAL has to work both
> > ways, otherwise I can just stay with Arc ASCII grid files.
> >
> > What will help is a fool-proof installation route for getting r.out.gdal
> > to work like v.out.ogr does
>
> The "easy" solution is to write r.out.gdal in C. A long-standing wish...
>Well, yes and no, because faster machines and discs are making scripted
loose coupling less of a problem time-wise. One problem I see with the
present script is that r.out.gdal seems to ignore the current region:GRASS 6.0.0 (spearfish57):~ > g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928010
south: 4913700
west: 589980
east: 609000
nsres: 30
ewres: 30
rows: 477
cols: 634
GRASS 6.0.0 (spearfish57):~ > r.out.gdal soils type=Byte output=tmp/soils.tiff
Writing format: GTiff
Writing type: Byte
Input file size is 950, 700
0...10...20...30...40...50...60...70...80...90...100 - done.
GRASS 6.0.0 (spearfish57):~ > gdalinfo tmp/soils.tiff | grep "^Size"
Size is 950, 700
Yes, a known problem. This depends on the behaviour of the plugin
which only sees the map but not the current region settings.
Maybe a change there is useful:
if in a GRASS session, then respect region, else read full map.
This differs from, for example, r.out.arc, which is what the draft
interface is using now. Is the only answer to use another operation to
resample first, then output through r.out.gdal - by the way, the same
applies to using rgdal within R to read from GRASS directly?
I think so as it is using the same approach.
A C implementation of r.out.gdal would certainly solve the problem.
Thanks for your patience!
You are welcome!
Markus
On Sat, 30 Apr 2005, Markus Neteler wrote:
On Sat, Apr 30, 2005 at 11:03:32AM +0200, Roger Bivand wrote:
...
> I have the 1.2.6 release - I find the difficulties of interfacing multiple
> changing codebases from CVS too great to be worth the trouble - keeping
> all but one as released restricts blunders to my own code.Just a naive question:
Why do you need the GDAL/GRASS plugin for the R interface?
To test if R-gdal is an alternative to read GRASS data?
Yes, because maintaining a single code base is always better than
multiple, the bugs get found faster! Just as r.out.gdal reads the GRASS
raster database, rgdal in R could do the same, but more or less straight
into R. The current disadvantages are the region question, and how to pass
category labels (am I right that for GDAL, data are just numbers?).
...
> > Do you get this number of GRASS libs?:
> > ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
> > 6
>
> $ ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
> 5I have
ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
libgrass_I.so => /usr/local/lib/libgrass_I.so (0x4001f000)
libgrass_vask.so => /usr/local/lib/libgrass_vask.so (0x4002f000)
libgrass_gmath.so => /usr/local/lib/libgrass_gmath.so (0x40035000)
libgrass_gis.so => /usr/local/lib/libgrass_gis.so (0x4003b000)
libgrass_datetime.so => /usr/local/lib/libgrass_datetime.so (0x400c0000)
libgrass_gproj.so => /usr/local/lib/libgrass_gproj.so (0x400c8000)
The one I don't see is libgrass_gproj.so. My GRASS is the 6.0.0 release.
> > > Do I need to re-install GDAL after having configured, built and installed
> > > the plugin (I think not)?
> >
> > No.
>
> So now on one of two RHEL 3 machines, it works, on the other not (but
> maybe I need another ldconfig ...)I am working on RH7, RHEL 3 and Mdk10.0. Works everywhere.
What is your "other" machine?
Both are RHEL 3, I think with the same PROJ.4, GDAL, R, and GRASS, but as
I said, I think it's just coincidence.
> Thanks so far, it can be done, but it doesn't feel easy.
Suggestions to improve things are always welcome.
> Does r.out.gdal work under cygwin?
Never tested, I have no idea. It should
> > > I'm keeping on about this because if this is this difficult to configure
> > > for me, then the chances of any R/GRASS interface for GRASS 6 get very
> > > slim - there are so many hoops to jump though even on Unix/Linux (not to
> > > mention cygwin?) that no-one will ever use it.
> > >
> > > There do not seem to have been any downloads of the draft package from
> > > sourceforge http://sourceforge.net/projects/r-spatial/ so far, so I've no
> >
> > I have added the link only last week to the GRASS site (unfortunately
> > no other developer did it). So probably nobody was aware of it.
> >
> > I have downloaded it, so there must be at least 1 hit.
> > Testing forthcoming. In fact I'll need ot soon, so I'll spend
> > time on that.
>
> Great, (sourceforge do warn that the counter isn't reliable). An example
> of the use of the spgrass6 package is on http://r-spatial.sourceforge.net,
> "sp and other packages" on the navigation bar on the left. The CVS code is
> the freshest, but at least now sp is released and on CRAN, so the classes
> used for holding data within R are becoming stable.
>
> >
> > > idea of whether any of this is actually required. GDAL and OGR provide
> > > ways to prototype the interface cleanly. But then GDAL has to work both
> > > ways, otherwise I can just stay with Arc ASCII grid files.
> > >
> > > What will help is a fool-proof installation route for getting r.out.gdal
> > > to work like v.out.ogr does
> >
> > The "easy" solution is to write r.out.gdal in C. A long-standing wish...
> >
>
> Well, yes and no, because faster machines and discs are making scripted
> loose coupling less of a problem time-wise. One problem I see with the
> present script is that r.out.gdal seems to ignore the current region:
>
> GRASS 6.0.0 (spearfish57):~ > g.region -p
> projection: 1 (UTM)
> zone: 13
> datum: nad27
> ellipsoid: clark66
> north: 4928010
> south: 4913700
> west: 589980
> east: 609000
> nsres: 30
> ewres: 30
> rows: 477
> cols: 634
> GRASS 6.0.0 (spearfish57):~ > r.out.gdal soils type=Byte output=tmp/soils.tiff
> Writing format: GTiff
> Writing type: Byte
> Input file size is 950, 700
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> GRASS 6.0.0 (spearfish57):~ > gdalinfo tmp/soils.tiff | grep "^Size"
> Size is 950, 700Yes, a known problem. This depends on the behaviour of the plugin
which only sees the map but not the current region settings.
Maybe a change there is useful:
if in a GRASS session, then respect region, else read full map.
For me this is a scripting question on the R side - issue a system() call
from R to make a copy in GRASS with the correct region, read that, and
delete, so it is doable.
Roger
> This differs from, for example, r.out.arc, which is what the draft
> interface is using now. Is the only answer to use another operation to
> resample first, then output through r.out.gdal - by the way, the same
> applies to using rgdal within R to read from GRASS directly?I think so as it is using the same approach.
A C implementation of r.out.gdal would certainly solve the problem.
> Thanks for your patience!
You are welcome!
Markus
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no
On Sat, Apr 30, 2005 at 11:03:32AM +0200, Roger Bivand wrote:
...
Thanks so far, it can be done, but it doesn't feel easy.
Forgot to mention that RPMs are ready, also Debian:
Suse:
http://www.gdf-hannover.de/software/suse/9.1/RPMS/
Mandrake
http://www.gdf-hannover.de/software/mandrake/10.1/RPMS/
Debian:
http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl
Markus
On Sun, 1 May 2005, Markus Neteler wrote:
On Sat, Apr 30, 2005 at 11:03:32AM +0200, Roger Bivand wrote:
...
> Thanks so far, it can be done, but it doesn't feel easy.
Doing things in the correct order on RHEL 3 works:
GDAL: ./configure, make, su -> make install, ldconfig
plugin: as in Markus' script (but after a fresh GDAL install, the plugin
seems to want to be rebuilt).
Now happy!
Roger
Forgot to mention that RPMs are ready, also Debian:
Suse:
http://www.gdf-hannover.de/software/suse/9.1/RPMS/Mandrake
http://www.gdf-hannover.de/software/mandrake/10.1/RPMS/Debian:
http://pkg-grass.alioth.debian.org/cgi-bin/wiki.plMarkus
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no