Re: [GRASS-user] Best format for exporting raster data

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 31/08/10 16:56, Sylvain Maillard wrote:
> Perhaps can you add an extra loop in your scripts for processing your data:
> 1 - extract the tarball
> 2 - import the raster in R
> 3 - and then delete the temporary uncompressed mapset.

Yes - that would be the "crude force" approach. In my case, it would
very likely take more time, as there are MANY more layers in the .tar.gz
then I use.
I am now thinking about extracting all files with "fire" in  them and to
use this subset as a mapset - I will see if it works.

It would be nice, if grass would be able to deal with on-the-fly
decompression - not from a .tar.gz file, but from gz compressed files.

Cheers,

Rainer


> it will take a little bit more space but just for one mapset at a time,
> and I don't thing the process will be much slower than to access the
> files directly into the compressed tarball ...
> 
> you can also buy more hard drive :D
> 
> if you make some benchmark test between different solution I will be
> interreted in the results, I'm also working on a huge amound of raster
> data within GRASS and R ...

I'll do - although I don't think I will do benchmarks at that time.

Cheers,

Rainer


> 
> regards,
> Sylvain Maillard
> 
> Doctorant en Sciences de l'Environnement
> Laboratoire Chimie Provence - UMR 6264 / Université de Provence
> la Tour du Valat - Centre de recherche pour la conservation des zones
> humides méditerranéennes
> Le Sambuc
> 13200 Arles
> France
> tél:04.90.97.29.79
> fax:04.90.97.20.19
> www.tourduvalat.org 
> 
> 
> 
> 2010/8/31 Rainer M Krug mailto:r.m.k...@gmail.com>>
> 
> On 31/08/10 16:38, Markus Neteler wrote:
>> On Tue, Aug 31, 2010 at 4:13 PM, Rainer M Krug  > wrote:
>> ...
 I would leave it in GRASS and use the R-GRASS interface and/or the
 GDAL-GRASS plugin. See the Wiki for details.
>>>
>>> I am doing that already - but I don't think that works when I
> have the
>>> grass mapset compressed as a .tar.gz?
> 
>> I found "archivemount" which apparently lets you
>> mount a possibly compressed tarball as a filesystem:
> 
>> http://en.wikipedia.org/wiki/Archivemount
>> http://www.linux.com/archive/feature/132196
> 
> Sounds interesting - I'll look into that.
> 
> Thanks,
> 
> Rainer
> 
> 
>> Cheers
>> Markus
> 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/grass-user

- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Tel:+33 - (0)9 53 10 27 44
Cell:   +27 - (0)8 39 47 90 42
Fax (SA):   +27 - (0)8 65 16 27 82
Fax (D) :   +49 - (0)3 21 21 25 22 44
Fax (FR):   +33 - (0)9 58 10 27 44
email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx+C5QACgkQoYgNqgF2egoSOwCeLJPZ4WGaem4o8k+lvDpT5QiG
l4gAnRe9trZfFaD+STl7yByUXA3IYiXS
=+YiD
-END PGP SIGNATURE-
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Best format for exporting raster data

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/09/10 10:15, Rainer M Krug wrote:
> On 31/08/10 16:56, Sylvain Maillard wrote:
>> Perhaps can you add an extra loop in your scripts for processing your data:
>> 1 - extract the tarball
>> 2 - import the raster in R
>> 3 - and then delete the temporary uncompressed mapset.
> 
> Yes - that would be the "crude force" approach. In my case, it would
> very likely take more time, as there are MANY more layers in the .tar.gz
> then I use.
> I am now thinking about extracting all files with "fire" in  them and to
> use this subset as a mapset - I will see if it works.
> 
> It would be nice, if grass would be able to deal with on-the-fly
> decompression - not from a .tar.gz file, but from gz compressed files.
> 
> Cheers,
> 
> Rainer
> 
> 
>> it will take a little bit more space but just for one mapset at a time,
>> and I don't thing the process will be much slower than to access the
>> files directly into the compressed tarball ...
> 
>> you can also buy more hard drive :D
> 
>> if you make some benchmark test between different solution I will be
>> interreted in the results, I'm also working on a huge amound of raster
>> data within GRASS and R ...
> 
> I'll do - although I don't think I will do benchmarks at that time.

I am trying archivemounter and it has some interesting benchmarks on the
website http://www.linux.com/archive/feature/132196

Cheers,

Rainer

> 
> Cheers,
> 
> Rainer
> 
> 
> 
>> regards,
>> Sylvain Maillard
> 
>> Doctorant en Sciences de l'Environnement
>> Laboratoire Chimie Provence - UMR 6264 / Université de Provence
>> la Tour du Valat - Centre de recherche pour la conservation des zones
>> humides méditerranéennes
>> Le Sambuc
>> 13200 Arles
>> France
>> tél:04.90.97.29.79
>> fax:04.90.97.20.19
>> www.tourduvalat.org 
> 
> 
> 
>> 2010/8/31 Rainer M Krug mailto:r.m.k...@gmail.com>>
> 
>> On 31/08/10 16:38, Markus Neteler wrote:
>>> On Tue, Aug 31, 2010 at 4:13 PM, Rainer M Krug > > wrote:
>>> ...
> I would leave it in GRASS and use the R-GRASS interface and/or the
> GDAL-GRASS plugin. See the Wiki for details.

 I am doing that already - but I don't think that works when I
>> have the
 grass mapset compressed as a .tar.gz?
> 
>>> I found "archivemount" which apparently lets you
>>> mount a possibly compressed tarball as a filesystem:
> 
>>> http://en.wikipedia.org/wiki/Archivemount
>>> http://www.linux.com/archive/feature/132196
> 
>> Sounds interesting - I'll look into that.
> 
>> Thanks,
> 
>> Rainer
> 
> 
>>> Cheers
>>> Markus
> 
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 

- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Tel:+33 - (0)9 53 10 27 44
Cell:   +27 - (0)8 39 47 90 42
Fax (SA):   +27 - (0)8 65 16 27 82
Fax (D) :   +49 - (0)3 21 21 25 22 44
Fax (FR):   +33 - (0)9 58 10 27 44
email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx+D7kACgkQoYgNqgF2egrYKwCfSRRC23jZdwv8S30jrtFFp2hu
0X4AoIIbHJ/ZccwilSmaTcM7YJCa6tDZ
=P1+t
-END PGP SIGNATURE-
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Best format for exporting raster data

[Markus Metz]

Rainer M Krug wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi
>
> I am creating a huge amount of raster layers during my simulations, and
> I would like to archive then to enable further analysis. At the moment I
> am leaving them in the grass database and compress the whole mapset into
> a tar.gz file. But this is rather cumbersome, if I want to extract some
> selected layers and analyse them further (my analysis is done in R).
> Therefore I would like to export the created layers while the simulation
> is running and to delete them from the grass database.
> My question: what is the best format for this?
> It should :
> - - contain all the information contained in the raster layer in the grass
> mapset
> - - be readable by at least gdal
> - - be preferably compressed (but I can compress them after export)
>
> At the moment I am using for a similar purpose the esri asc grid, but I
> am somehow critical about the fact that it uses a text representation of
> my data with limited decimals, therefore probably loosing information
> compared with the grass file.
>
> Are Binary fiels a better option (in the manual it states "Exports", not
> "converts" as in the esri ascii grid) and can I read them from R or gdal?
>
Raster data (the actual data grids) are already compressed in GRASS,
nothing much to gain there to compress already compressed data. You
can try to set GRASS_INT_ZLIB [1] and check if this gives better
compression than the default RLE for CELL maps.

Generally, the recommended export format is GeoTIFF which supports
various internal compression methods. A high compression ratio is
achieved with LZW and DEFLATE.

Not all packages using gdal support all gdal features, DEFLATE in
particular is often not supported by packages using their own modified
gdal version (does not apply to packages using an external gdal
library, e.g. GRASS, R, QGIS).

Markus M

[1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] syntax for setting GRASS_PNGFILE from Python script

[Martin Landa]

Hi,

2010/8/31 Damian M :
> GRASS_PNGFILE=mywaycoolmap.png
> export GRASS_PNGFILE
>
> What is the proper syntax for setting this in Python?
>
> I have tried something like:
>
> def jpgMap():
>    #SET PNG OUTPUT FILE NAME
>    grass.run_command("g.gisenv", set="GRASS_PNGFILE=testName.png")

GRASS_PNGFILE is a shell environment variable, not a GRASS gisenv
variable [1]. To set environment variable use e.g. os.putenv()

os.putenv('GRASS_PNGFILE', 'test.png')

Martin

[1] http://grass.osgeo.org/grass64/manuals/html64_user/variables.html

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] g.extension not working

[Daniel Victoria]

I just issued "make install" and installed grass65 at
/usr/local/grass-6.5.svn. Now, g.extension tries to install
r.stream.order but complains about permissions. Taking ownership of
the install dir fixes the problem. So, what would be the "correct" way
to use g.extension, run grass as root or take ownership of the install
dir?

Cheers
Daniel

On Wed, Sep 1, 2010 at 2:39 AM, Markus Neteler  wrote:
> Yes, that's the reason then (same here).
>  We need to add a condition to skip the install ste in this case.
>
> Markus
>
> On 9/1/10, Daniel Victoria  wrote:
>> I do have /usr/bin/install installed. I run Ubuntu and coreutils is
>> the latest version.
>>
>> One small quirk though. I compiled Grass 6.5svn running make but I did
>> not install it (make install). I'm running it straigh from the build
>> directory (start script at ./bin.i686-pc-linux-gnu and binaries at
>> ./dist.i686-pc-linux-gnu). Could that be related?
>>
>> Thanks
>> Daniel
>>
>> On Tue, Aug 31, 2010 at 10:01 PM, Hamish  wrote:
>>> Daniel wrote:
 Ok, g.extension works and downloads svn addons
>>>
>>> great! thanks for the confirmation.
>>>
 but r.stream.extract compilation fails.
>>> ...
 Bellow is the r.stream.order compilation log error.
>>> ...
 make[1]: Leaving directory
>>>
>>> ok, so actually it built ok, but fails during installation:
>>>
 Installing r.stream.order...
>>> ...
 /usr/bin/install: cannot stat
>>>
>>> aka the "install" program is not installed.
>>>
>>> No idea what provides that on your linux distro, on Debian and Ubuntu
>>> it comes in the "coreutils" package.
>>>
>>>
>>> Hamish
>>>
>>>
>>>
>>>
>>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Raster resolution problems

[Hanlie Pretorius]

Hi,

I'm using GRASS6.4SVN on Windows XP.

I want to import TRMM precipitation data into a GRASS projected
(Transverse Mercator) location. I have previously successfully import
this data to a GCS (WGS84) location using the procedure at
http://grass.osgeo.org/wiki/Import_XYZ.

My problem is the grid resolution. The TRMM grid consists of 0.25°
squares, but projected they have different sizes. Here is the output
from v.report (area in km2) for a vector layer with the TRMM grid
squares, projected into the Transverse Mercator location:

-
cat|LabelX|LabelY|LblOffsetX|LblOffsetY|Label|gRow|gColumn|RowCol|area
5|28.25|-28.75|-20|-20|28.25677.428350142518
11|28.5|-28.5|-20|-20|28.5678.961903132767
6|28.25|-28.5|-20|-20|28.25679.002141385312
1|28|-28.5|-20|-20|28679.062503849138
12|28.5|-28.25|-20|-20|28.5680.522519692921
7|28.25|-28.25|-20|-20|28.25680.563040996854
2|28|-28.25|-20|-20|28680.623828116383
13|28.5|-28|-20|-20|28.5682.070220966439
8|28.25|-28|-20|-20|28.25682.111024322052
3|28|-28|-20|-20|28682.172234597964
14|28.5|-27.75|-20|-20|28.5683.604982570918
9|28.25|-27.75|-20|-20|28.25683.646066944101
4|28|-27.75|-20|-20|28683.70769882544
15|28.5|-27.5|-20|-20|28.5685.126780361735
10|28.25|-27.5|-20|-20|28.25685.168144684034
-

The projected grid 'squares' vary in size from 677km2 to 685km2. So
how am I supposed to set the resolution of the region when I do the
import?

(I previously tried to reproject the TRMM data from the GCS location
to the Transverse Mercator location, but then I ran into the same
problem - resolution.

Any ideas?

Thanks
Hanlie
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: syntax for setting GRASS_PNGFILE from Python script

[Damian M]

Martin,

Thanks!  Much appreciated.

-Damian


-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/syntax-for-setting-GRASS-PNGFILE-from-Python-script-tp5484418p5487870.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Best format for exporting raster data

[Glynn Clements]

Rainer M Krug wrote:

> It would be nice, if grass would be able to deal with on-the-fly
> decompression - not from a .tar.gz file, but from gz compressed files.

GRASS rasters are already compressed by default, either using RLE or
zlib compression (OTOH, the null bitmap isn't compressed; that will
cease to be an issue if we embed nulls into the raster data).

But GRASS doesn't generally read data from files per se, but from
either the GRASS "database" or from GDAL (and the former might
eventually go away if we can get "native" GRASS support into GDAL).

The main issue with on-the-fly decompression using general-purpose
formats is that rasters aren't guaranteed to be read sequentially,
while compression algorithms require sequential access.

Similarly, while there exist filesystems which can mount archives, tar
files (and especially compressed tar files) are a poor choice, as they
are designed for sequential access. ZIP/RAR are more suited to such
tasks.

Ultimately, I don't think that this situation is common enough to be
worth doing anything about. If you want to access archived data, you
just unpack the archives first (or use an archive format which can be
mounted).

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] syntax for setting GRASS_PNGFILE from Python script

[Glynn Clements]

Martin Landa wrote:

> > GRASS_PNGFILE=mywaycoolmap.png
> > export GRASS_PNGFILE
> >
> > What is the proper syntax for setting this in Python?
> >
> > I have tried something like:
> >
> > def jpgMap():
> >    #SET PNG OUTPUT FILE NAME
> >    grass.run_command("g.gisenv", set="GRASS_PNGFILE=testName.png")
> 
> GRASS_PNGFILE is a shell environment variable, not a GRASS gisenv
> variable [1]. To set environment variable use e.g. os.putenv()
> 
> os.putenv('GRASS_PNGFILE', 'test.png')

If you want to set an environment variable for the duration of a
script, the preferred mechanism is to modify the os.environ array,
i.e.:
os.environ['GRASS_PNGFILE'] = 'test.png'

Modifying os.environ will call os.putenv() if it is available (it
doesn't exist on all platforms supported by Python), but calling
os.putenv() doesn't modify os.environ, so calling os.putenv() will
result in os.environ and the actual environment used by subprocesses
getting out of sync.

If you want to set an environment variable for specific commands, use
the "env" parameter to run_command() etc to pass an updated
environment, e.g.:

environ = os.environ.copy()
environ['GRASS_PNGFILE'] = 'test.png'

grass.run_command(..., env = environ)

This approach should be used if you will be running different commands
with different environment settings. Changing os.environ then
reverting it after the command completes is error-prone and should not
be used. Only modify os.environ if the changes will be "permanent"
(i.e. for the duration of the script).

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] g.extension not working

[Markus Metz]

Daniel Victoria wrote:
> I just issued "make install" and installed grass65 at
> /usr/local/grass-6.5.svn. Now, g.extension tries to install
> r.stream.order but complains about permissions. Taking ownership of
> the install dir fixes the problem. So, what would be the "correct" way
> to use g.extension, run grass as root or take ownership of the install
> dir?
>
Maybe you could just ignore the install-related error messages and
check if r.stream.order is available when you are running grass
"straight from the build directory (start script at
./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu)"

In this case, i.e. running grass from the build directory, you could
download any addon to the appropriate directory, run make and it
should be available (not sure about manuals though, which are
important...) when running grass from the build directory.

Otherwise, if you installed grass as root (make install as root), you
most probably also have to install addons as root.

HTH,

Markus M

> Cheers
> Daniel
>
> Markus Neteler wrote:
>> Yes, that's the reason then (same here).
>>  We need to add a condition to skip the install ste in this case.
>>
>> Markus
>>
>> Daniel Victoria wrote:
>>> I do have /usr/bin/install installed. I run Ubuntu and coreutils is
>>> the latest version.
>>>
>>> One small quirk though. I compiled Grass 6.5svn running make but I did
>>> not install it (make install). I'm running it straigh from the build
>>> directory (start script at ./bin.i686-pc-linux-gnu and binaries at
>>> ./dist.i686-pc-linux-gnu). Could that be related?
>>>
>>> Thanks
>>> Daniel
>>>
>>> Hamish wrote:
 Daniel wrote:
> Ok, g.extension works and downloads svn addons

 great! thanks for the confirmation.

> but r.stream.extract compilation fails.
 ...
> Bellow is the r.stream.order compilation log error.
 ...
> make[1]: Leaving directory

 ok, so actually it built ok, but fails during installation:

> Installing r.stream.order...
 ...
> /usr/bin/install: cannot stat

 aka the "install" program is not installed.

 No idea what provides that on your linux distro, on Debian and Ubuntu
 it comes in the "coreutils" package.


 Hamish

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] g.extension not working

[Markus Neteler]

On Wed, Sep 1, 2010 at 8:52 PM, Markus Metz
 wrote:
> Daniel Victoria wrote:
>> I just issued "make install" and installed grass65 at
>> /usr/local/grass-6.5.svn. Now, g.extension tries to install
>> r.stream.order but complains about permissions. Taking ownership of
>> the install dir fixes the problem. So, what would be the "correct" way
>> to use g.extension, run grass as root or take ownership of the install
>> dir?
>>
> Maybe you could just ignore the install-related error messages and
> check if r.stream.order is available when you are running grass
> "straight from the build directory (start script at
> ./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu)"
>
> In this case, i.e. running grass from the build directory, you could
> download any addon to the appropriate directory, run make and it
> should be available (not sure about manuals though, which are
> important...) when running grass from the build directory.
>
> Otherwise, if you installed grass as root (make install as root), you
> most probably also have to install addons as root.

Perhaps we need to add some sudo magic...?

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] g.extension not working

[Markus Metz]

Markus Neteler:
> Markus Metz:
>> Daniel Victoria wrote:
>>> I just issued "make install" and installed grass65 at
>>> /usr/local/grass-6.5.svn. Now, g.extension tries to install
>>> r.stream.order but complains about permissions. Taking ownership of
>>> the install dir fixes the problem. So, what would be the "correct" way
>>> to use g.extension, run grass as root or take ownership of the install
>>> dir?
>>>
>> Maybe you could just ignore the install-related error messages and
>> check if r.stream.order is available when you are running grass
>> "straight from the build directory (start script at
>> ./bin.i686-pc-linux-gnu and binaries at ./dist.i686-pc-linux-gnu)"
>>
>> In this case, i.e. running grass from the build directory, you could
>> download any addon to the appropriate directory, run make and it
>> should be available (not sure about manuals though, which are
>> important...) when running grass from the build directory.
>>
>> Otherwise, if you installed grass as root (make install as root), you
>> most probably also have to install addons as root.
>
> Perhaps we need to add some sudo magic...?
>
Probably yes. The standard situation might be that a user installs
from a repository grass and grass-devel (or simliar) which usually
requires root privileges. In turm g.extension will require root
priviliges. Right?

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Finding the value of a point in a raster map

[vbkhp]

Hi,

I am writing a r.mapcalc instruction, and I would like to find the value of a 
point in the map (other than the point that the window is currently at). 
More precisely, in a raster dem I would like to calculate the difference 
between the height of one point and the rest of the map. I appreciate if any 
one can help.

Thanks,
Ahmad



  ___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] g.extension not working

[Hamish]

> > Otherwise, if you installed grass as root (make install as root), you
> > most probably also have to install addons as root.
Markus Neteler wrote:
> Perhaps we need to add some sudo magic...?

will that work with MSys? (does g.extension work at all with standalone
WinGrass?)

addons should really be installed to $GRASS_ADDON_PATH, right? not $GISBASE
(typically that will be read-only if GRASS came from a package; GISBASE is
the default for prefix= currently).

maybe have a test at the start of the script to see if GRASS_ADDON_PATH
exists and if it does use that as the default for prefix= instead of GISBASE? 
(n.b. $GRASS_ADDON_PATH/ replaces to $GISBASE/bin, not $GISBASE/)

either way, the short term solution seems to be another paragraph in the
help page to explain all this.


Hamish

ps- I suspect 'svn commit' uploaded a bit more than you planned in this one:
  https://trac.osgeo.org/grass/changeset/43379



  
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user