Good night,
I have applied bugfixes to r.los and r.buffer to make
them write NULL instead of ZERO.
Hope that's fine with everybody,
Markus
PS: Do we need to keep r.describe? Or is r.stats sufficient?
We have had some discussion about this with Markus but I am curious to
hear from others:
Where do you put your GRASS database on your system (say you expect it
to have 10-20GB)
here are some options that we have seen:
/usr/local/share/grassdata
/opt/grassdata
/usr2/grassdata
/data/grassdata
/home/paul/grassdata
Is there any reason why some of these options may be bad?
Would it be different for a desktop at home and for a networked computer
(e.g. under NFS)
(assuming that at home there is a single user of that database and at
work many people
are using the database)
Any other ideas what the "correct" place/partition should be for a big
GRASS database?
thank you for any input,
Helena
Helena Mitasova writes:
> >
>
> We have had some discussion about this with Markus but I am curious to
> hear from others:
>
> Where do you put your GRASS database on your system (say you expect it
> to have 10-20GB)
It would seem that according to the Filesystem Hierarchy Standard,
(http://www.pathname.com/fhs/2.0/fhs-toc.html), that a GRASS database
belongs in /var. The /var directory is used for read-write "variable
data files". System administrators are likely already expecting the
/var directory to be large and potentially growing so it makes sense
for GRASS data files.
Current/Historical practice, (as measured by 28 packages on my Debian
system), would put this in:
/var/lib/grass5
but the standard says that /var/lib is on its way out and that new
packages should use /var/state instead. So:
/var/state/grass5
(My current Debian system has exactly one package using the
/var/state/<package_name> convention so far).
Note that I also changed from "grassdata" to "grass5" so that it
adheres precisely to the "/var/state/<package_name>" convention.
Some of the reasons some of the other proposed options might be "bad"
include the fact that directories such as /usr might be mounted
read-only. Directories such as /data, /usr2 are not standard and
therefore might be confusing. And the /opt directory is typically used
for installation of package binaries rather than data files.
Finally, /home/<user>/grassdata, might be a perfectly reasonable setup
for single-user as opposed to system data.
So, there you have my two bits.
-Carl
We've found that placement of large GRASS databases works rather nicely
in most of the places that you've mentioned below.
Helena Mitasova wrote:
We have had some discussion about this with Markus but I am curious to
hear from others:Where do you put your GRASS database on your system (say you expect it
to have 10-20GB)here are some options that we have seen:
/usr/local/share/grassdata
/opt/grassdata
/usr2/grassdata
/data/grassdata
/home/paul/grassdata
Is there any reason why some of these options may be bad?
Would it be different for a desktop at home and for a networked computer
(e.g. under NFS)
(assuming that at home there is a single user of that database and at
work many people
are using the database)
Any other ideas what the "correct" place/partition should be for a big
GRASS database?thank you for any input,
Helena
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
--
-Juhana Nieminen, MSc.----------------------------------------------
Division of Environmental Biology,GIS Laboratory
P.O.Box 44 (Jyrangontie 2) tel: +358-9-191 50054
FIN-00014 University of Helsinki fax: +358-9-191 50048
Finland http://ginkgo.pc.helsinki.fi
On Thu, 29 Nov 2001, Helena Mitasova wrote:
>
We have had some discussion about this with Markus but I am curious to
hear from others:Where do you put your GRASS database on your system (say you expect it
to have 10-20GB)
Helena,
I work on a small network of desktop computers, with grass installed on
one of the desktops. It's on the only desktop situated to provide for
external access through the firewall. I need all of the members of my
workgroup to have simultaneous access to in-progress work.
I created a grass super-user named "gis" and a group also named gis. I
installed the grass data base as /home/gis/grassdata and modified the
security system in grass so that access to the data base was controlled by
membership in the gis group. Further, I changed the locking system so
that multiple users were allowed simultaneous access to the same location.
Simultaneous access to the same mapset awaits changes in the way that
grass handles some settings--current region, for example.
My modifications haven't been extensively tested and I know of at least
one problem, but otherwise they work pretty well.
Roger Miller
Lee Wilson and Associates.
On Thu, 29 Nov 2001, Helena Mitasova wrote:
Where do you put your GRASS database on your system (say you expect it
to have 10-20GB)here are some options that we have seen:
/usr/local/share/grassdata
/opt/grassdata
/usr2/grassdata
/data/grassdata
/home/paul/grassdata
If you have space on a particular partition or file system, use it. On our
network, I have an nfs-exported/mounted drive named /mnt/usr4/. One of the
filesystems on that drive is projects/. Under that I have data organized by
state and specific project.
Non-project-specific data (that is, data not being used for a currently
active project) lives in /mnt/usr3/spatial-data/. Works well for us.
I know of another installation where maps for a specific project are
distributed among different partitions and filesystems. Symbolic links are
created to put the appropriate maps in one "place" for a specific project or
analysis.
Is there any reason why some of these options may be bad?
No.
Would it be different for a desktop at home and for a networked computer
(e.g. under NFS) (assuming that at home there is a single user of that
database and at work many people are using the database) Any other ideas
what the "correct" place/partition should be for a big GRASS database?
There's nothing in the HFS or LSB about data directories. IMO, your
question is analagous to asking about the better editor: emacs or vi. You'll
get passionate responses on all three sides of the question.
Some SysAdmins like to have all system data on a separate partition; e.g.,
/data1, /data2 so it can be backed up as a unit. All processed words, spread
sheets, graphics and what-have-you are on those partitions. I tend to keep
my non-spatial data in /home/rshepard/data/. Under this I have
subdirectories for different types: wpdocs/, spreadsheets/, plots/, etc.
Accounting data is in the accounting filesystem.
What I want to see in the next version of GRASS is the ability to have
data anywhere and access it either as the pwd or by specifying the path in
the startup screen. No more $GISBASE, LOCATION and MAPSET. Think of how
LyX/LaTeX, GRI or any other application finds its data and that's how I
believe GRASS should work.
thank you for any input,
Any time. 
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com