"Linda Moet" <lindam@gwnsys.ca> writes:
To help get you going, here are some random thoughts on what has to happen
to make GRASS accessible over the Internet:
2) In order for a web user to access a mapset, they must own it. (There
was a discussion on the list a short while ago about sharing mapsets and why
it isn't possible - only the owner of a mapset can access it.)
More precisely, in order for a user to execute any Grass command, they must
possess their own mapset. This is actually an unnecessary restriction in those
cases where users simply want read-only access to some common dataset. Most d.*
and g.* commands, for example, do not write anything to the mapset, and this
tends to be the province of r.* commands. There would be some merit in
re-programming Grass so that individual mapsets are only constructed upon
demand. This would require some minor tinkering around with the gis libraries,
and would involve making Grass store the user's WIND in an alternative location
(like .grassrc). Another possible extension for the enthusiast would be to make
Grass write to the client rather than to the server.
--
Conn V Copas
Information Technology Division
Defence Science and Technology Organisation
PO Box 1500
Salisbury tel: +61 (0)8 825 95349
SA 5108 fax: +61 (0)8 825 95589
Australia e-mail: Conn.Copas@dsto.defence.gov.au
------------------------------------------------------
On Tue, 9 Nov 1999, Conn Copas wrote:
There would be some merit in
re-programming Grass so that individual mapsets are only constructed upon
demand. This would require some minor tinkering around with the gis libraries,
and would involve making Grass store the user's WIND in an alternative location
(like .grassrc).
Another possible extension for the enthusiast would be to make
Grass write to the client rather than to the server.
I agree with this sugestion.
Agus
Dear DEC Alpha users,
Prior to tackling a new installation I'd be grateful if anybody who has
gone through the installation process on a DEC Alpha runing Digital UNIX v.
4.0F (or similar) would be willing to share any tricks needed or warnings I
should be aware of, or point me toward any FAQ archive where these issues
may well have been covered already.
Thanks for your time,
Roderick
_____________________________________________________________________
Roderick Brown Tele: (Int+ 61 3) 9344-9868
School of Earth Sciences Dept.: (Int+ 61 3) 9344-7675
The University of Melbourne Facsimile: (Int+ 61 3) 9344-7761
Parkville, 3052 Home Telephone: (Int+ 61 3) 9397-8848
Australia Email: r.brown@earthsci.unimelb.edu.au
______________________________________________________________________
Roderick Brown wrote:
Dear DEC Alpha users,
Prior to tackling a new installation I'd be grateful if anybody who has
gone through the installation process on a DEC Alpha runing Digital UNIX v.
4.0F (or similar) would be willing to share any tricks needed or warnings I
should be aware of, or point me toward any FAQ archive where these issues
may well have been covered already.
Thanks for your time,
Roderick
Hi Rod,
I have installed GRASS on DU alpha. The current distribution
(GRASS 5.0 beta5a) is still somehow difficult to install on DUalpha. Things
should change with the next distribution that will be soon available. If you
need it urgently I can send you a set of patches that may be usefull for the
istallation of beta5a.
Any how feel free to mail me if you have any questions or problems.
For further resources on GRASS & DUalpha you can go to the pages of Bill
Hughes at
http://grasshopper.grasshoppernet.com/~bhughes/
bye
LP
_____________________________________________________________________
Roderick Brown Tele: (Int+ 61 3) 9344-9868
School of Earth Sciences Dept.: (Int+ 61 3) 9344-7675
The University of Melbourne Facsimile: (Int+ 61 3) 9344-7761
Parkville, 3052 Home Telephone: (Int+ 61 3) 9397-8848
Australia Email: r.brown@earthsci.unimelb.edu.au
______________________________________________________________________
--
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
Universita' di Padova TEL: +390498275527 -------
------------------------- FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--
> 2) In order for a web user to access a mapset, they must own it. (There
> was a discussion on the list a short while ago about sharing mapsets and why
> it isn't possible - only the owner of a mapset can access it.)
More precisely, in order for a user to execute any Grass command, they must
possess their own mapset. This is actually an unnecessary restriction in those
cases where users simply want read-only access to some common dataset. Most d.*
and g.* commands, for example, do not write anything to the mapset, and this
tends to be the province of r.* commands. There would be some merit in
re-programming Grass so that individual mapsets are only constructed upon
demand. This would require some minor tinkering around with the gis libraries,
and would involve making Grass store the user's WIND in an alternative location
(like .grassrc). Another possible extension for the enthusiast would be to make
Grass write to the client rather than to the server.
Of course you are right. Thanks for clarifying. As I mentioned in my
original post, I have made a lot of mistakes, and tinkering with mapsets
was one of them. Even though my sample CGI script did nothing but
return the output of the g.list command for raster files in the
spearfish location (a read-only operation, as you mention), I got the
following errors when I set the MAPSET to:
1) (nothing at all)
ERROR: MAPSET not set
2) lindam (even with permissions set to 777!)
ERROR: MAPSET lindam - permission denied
3) PERMANENT
ERROR: MAPSET PERMANENT - permission denied
4) wwwgrass (owned by user nobody)
No errors - this works!
Your suggestions make a lot of sense for applications where there would
be users who only query the GIS, not modify it (GRASS-on-the-Web being a
prime example). Maybe someday I will acquire enough programming
know-how to contribute to the effort. =+)
-Linda