Any developers who are working with importing/exporting
native ArcInfo Grid binary files might be interested in these
pages:
http://gdal.velocet.ca/projects/aigrid/index.html
cheers,
-matt
On Tue, 12 Oct 1999, Matt.Wilkie wrote:
Any developers who are working with importing/exporting
native ArcInfo Grid binary files might be interested in these
pages:
Matt, et al.:
On a similar note, I found today some ARC/Info GRD files in .e00 format
for one of my projects. Why I hadn't translated them before, I don't know.
Anyway, a few years ago I wrote a short C program which converts the
exported grid file to an ASCII file with x, y and z coodinate tuples. The
program runs in DOS.
It occurred to me that I should port this little utility to linux. It will
be the first C program of my own which I'll try to compile. I've no idea
what gcc options I want, so I need to read the man page. Anyway, when I have
this ported, I'll make it available to anyone who could use it. As far as
I'm concerned, it could be part of a data format translation module in
GRASS. Although I copyrighted the program, I made it freely available to
MapInfo users and anyone else who wanted it. Might as well do the same in
this environment.
But, because I have to have to get this project work done ASAP, I'll wimp
out and run the translater in dosemu. 
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
Making environmentally-responsible mining happen. (SM)
--------------------------------
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
Rich Shepard wrote:
On Tue, 12 Oct 1999, Matt.Wilkie wrote:
> Any developers who are working with importing/exporting
> native ArcInfo Grid binary files might be interested in these
> pages:Matt, et al.:
On a similar note, I found today some ARC/Info GRD files in .e00 format
for one of my projects. Why I hadn't translated them before, I don't know.
If your GRD file has integer values, you can directly import it to
Grass with m.in.e00.
If the cells of your GRD file contain floating values, hmmm...
work is in progress
--
Michel Wurtz ENGEES - CEREG
1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97
Dear grass comunity,
Yesterday for the first time since I use grass, I have been
faced with an interesting question:
can different users work on the same mapset ?
So I tried, I played with unix privileges moved mapsets changed user
and group etc. etc. and discovered that finally THE ANSWER IS NO !!!
at lest not in grass5beta3 on alinux RH6.0 (posix compliant) platform.
Well, this is a little bit strange. Why shouldn't be possible in a
multi user environment such as unix to use the same mapset under
different usernames (maybe in the same group) ?
This could be very usefull especially for large projects whit many
people involved in.
The problem is in a GRASS GIS library call G__mapset_permissions,
that looks like:
int G__mapset_permissions (char *mapset)
{
char path[256];
struct stat info;
G__file_name (path,"","",mapset);
if (stat (path, &info) != 0)
return -1;
if (info.st_uid != getuid())
return 0;
if (info.st_uid != geteuid())
return 0;
return 1;
}
Simple, everytime that a call access mapsets data a check is done
for the userid of the mapsets file to be equal to that of real and
effective ids of the invoking process. So if I own a mapset I can
work on it, if I do not own it I cannot regardeless of the unix
mapsets files privileges.
I have only one question, why ? I do not understand this idea.
Ok so I went forward and changed a little bit the code. But if we
release this constraint by for example commenting the last two ifs
in the call, we will have to check for access permission to the mapsets.
This is done at start time in gis_set. I've done some work on that
and modified the gis_set and the g.access programs.
Anyhow at this stage I do not think it is a good idea to post my bugfixes,
that are to be considered much more as tournarounds. A sound understanding
of the global grass structure and clear objectives on how to manage mapset
permissions are needed in order to produce a proper code.
So here I just want to point out that THIS IS AN IMPORTANT ISSUE. Clearly
if somebody is interested in having my patch I can send it. But I would first
like to understand the developping strategy beneath the G__mapset_permissions
call.
Comments are welcome
LP
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
Universita' di Padova TEL: +390498275527 -------
------------------------- FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--
Luca Palmeri wrote:
The problem is in a GRASS GIS library call G__mapset_permissions,
I've once read (in grass doc ?) that you can share a location.
Each user has its own mapset, and the PERMANENT Mapset is shared
and read-only for the non-owners (you must use xxx@PERMANENT to
access them). I don't remember if you can read other mapsets in
the same way.
I didn't test this yet...
--
Michel Wurtz ENGEES - CEREG
1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97
Michel Wurtz - ENGEES/CEREG wrote:
I’ve once read (in grass doc ?) that you can share a location.
Each user has its own mapset, and the PERMANENT Mapset is shared
and read-only for the non-owners (you must use xxx@PERMANENT to
access them). I don’t remember if you can read other mapsets in
the same way.
It depends from the mapset privileges, but you are never allowed to modify them.
Ok now I understand. Each user has his own mapset and can work only on that.
My concern was on using multiple grass shells on different mapsets at the
same time from different machines in NFS. Given that grass do not allow the same
user to run multiple session I was thinking that one solution was to use
different users in the same location, all accessing to the same mapsets.
Ok it is clear now
thanks.
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
Universita' di Padova TEL: +390498275527 -------
------------------------- FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--
Hi Luca
Maybe too trivial, but if you put the data in mapset PERMANENT,
different users can access the data.
Seppo Kaitala
Luca Palmeri wrote:
Dear grass comunity,
Yesterday for the first time since I use grass, I have been
faced with an interesting question:
can different users work on the same mapset ?
So I tried, I played with unix privileges moved mapsets changed user
and group etc. etc. and discovered that finally THE ANSWER IS NO !!!
at lest not in grass5beta3 on alinux RH6.0 (posix compliant) platform.
Well, this is a little bit strange. Why shouldn't be possible in a
multi user environment such as unix to use the same mapset under
different usernames (maybe in the same group) ?
This could be very usefull especially for large projects whit many
people involved in.
The problem is in a GRASS GIS library call G__mapset_permissions,
that looks like:
int G__mapset_permissions (char *mapset)
{
char path[256];
struct stat info;G__file_name (path,"","",mapset);
if (stat (path, &info) != 0)
return -1;if (info.st_uid != getuid())
return 0;
if (info.st_uid != geteuid())
return 0;return 1;
}Simple, everytime that a call access mapsets data a check is done
for the userid of the mapsets file to be equal to that of real and
effective ids of the invoking process. So if I own a mapset I can
work on it, if I do not own it I cannot regardeless of the unix
mapsets files privileges.
I have only one question, why ? I do not understand this idea.
Ok so I went forward and changed a little bit the code. But if we
release this constraint by for example commenting the last two ifs
in the call, we will have to check for access permission to the mapsets.
This is done at start time in gis_set. I've done some work on that
and modified the gis_set and the g.access programs.
Anyhow at this stage I do not think it is a good idea to post my bugfixes,
that are to be considered much more as tournarounds. A sound understanding
of the global grass structure and clear objectives on how to manage mapset
permissions are needed in order to produce a proper code.
So here I just want to point out that THIS IS AN IMPORTANT ISSUE. Clearly
if somebody is interested in having my patch I can send it. But I would first
like to understand the developping strategy beneath the G__mapset_permissions
call.
Comments are welcome
LP
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
Universita' di Padova TEL: +390498275527 -------
------------------------- FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--
Seppo Kaitala wrote:
Hi Luca
Maybe too trivial, but if you put the data in mapset PERMANENT,
different users can access the data.Seppo Kaitala
Ok, but nobody other than the owner of the PERM data can modify it. The problem
was to find a way for different users to work with (i.e. read and modify) the same
mapset. In my very special case I solved the problem by rewriting a simplified
GIS.sh and modifing slightly the G__mapset_permissions libes call.
LP
Luca Palmeri wrote:
>
> Dear grass comunity,
>
> Yesterday for the first time since I use grass, I have been
>
> faced with an interesting question:
>
> can different users work on the same mapset ?
>
> So I tried, I played with unix privileges moved mapsets changed user
>
> and group etc. etc. and discovered that finally THE ANSWER IS NO !!!
>
> at lest not in grass5beta3 on alinux RH6.0 (posix compliant) platform.
>
> Well, this is a little bit strange. Why shouldn't be possible in a
>
> multi user environment such as unix to use the same mapset under
>
> different usernames (maybe in the same group) ?
>
> This could be very usefull especially for large projects whit many
>
> people involved in.
>
> The problem is in a GRASS GIS library call G__mapset_permissions,
>
> that looks like:
>
> int G__mapset_permissions (char *mapset)
> {
> char path[256];
> struct stat info;
>
> G__file_name (path,"","",mapset);
>
> if (stat (path, &info) != 0)
> return -1;
>
> if (info.st_uid != getuid())
> return 0;
> if (info.st_uid != geteuid())
> return 0;
>
> return 1;
> }
>
> Simple, everytime that a call access mapsets data a check is done
>
> for the userid of the mapsets file to be equal to that of real and
>
> effective ids of the invoking process. So if I own a mapset I can
>
> work on it, if I do not own it I cannot regardeless of the unix
>
> mapsets files privileges.
>
> I have only one question, why ? I do not understand this idea.
>
> Ok so I went forward and changed a little bit the code. But if we
>
> release this constraint by for example commenting the last two ifs
>
> in the call, we will have to check for access permission to the mapsets.
>
> This is done at start time in gis_set. I've done some work on that
>
> and modified the gis_set and the g.access programs.
>
> Anyhow at this stage I do not think it is a good idea to post my bugfixes,
>
> that are to be considered much more as tournarounds. A sound understanding
>
> of the global grass structure and clear objectives on how to manage mapset
>
> permissions are needed in order to produce a proper code.
>
> So here I just want to point out that THIS IS AN IMPORTANT ISSUE. Clearly
>
> if somebody is interested in having my patch I can send it. But I would first
>
> like to understand the developping strategy beneath the G__mapset_permissions
>
> call.
>
> Comments are welcome
>
> LP
>
> --> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
> Universita' di Padova TEL: +390498275527 -------
> ------------------------- FAX: +390498275528 -------
> --> Think holistic @ the end of the 2nd millenium <--
>
>
--
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
Universita' di Padova TEL: +390498275527 -------
------------------------- FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--
On Fri, 15 Oct 1999, Luca Palmeri wrote:
Seppo Kaitala wrote:
> Hi Luca
>
> Maybe too trivial, but if you put the data in mapset PERMANENT,
> different users can access the data.
>
> Seppo KaitalaOk, but nobody other than the owner of the PERM data can modify it. The
problem
was to find a way for different users to work with (i.e. read and modify)
the same mapset.
I disagree. In most cases, it is well as it is: different co-workers can
put their common stuff in PERMANENT, but each one would modify his/her
own mapsets only. Otherwise, it could be a mess, as you could be using
a raster at time t, and then be using a different raster at time t+1
without actually knowing it because somebody else had modified it prior
to let you know (and not to tell about the risk of errors, like
having two users giving the same name to two different rasters...). With a
bit of organization, each one can
move to PERMANENT the information to be shared, i.e., at the end of the
day and after discusing with the rest of the team.
Agus
Hi Luca
Maybe too trivial, but if you put the data in mapset PERMANENT,
different users can access the data.
Seppo Kaitala
Luca Palmeri wrote:
Dear grass comunity,
Yesterday for the first time since I use grass, I have been
faced with an interesting question:
can different users work on the same mapset ?
So I tried, I played with unix privileges moved mapsets changed user
and group etc. etc. and discovered that finally THE ANSWER IS NO !!!
at lest not in grass5beta3 on alinux RH6.0 (posix compliant) platform.
Well, this is a little bit strange. Why shouldn't be possible in a
multi user environment such as unix to use the same mapset under
different usernames (maybe in the same group) ?
This could be very usefull especially for large projects whit many
people involved in.
The problem is in a GRASS GIS library call G__mapset_permissions,
that looks like:
int G__mapset_permissions (char *mapset)
{
char path[256];
struct stat info;G__file_name (path,"","",mapset);
if (stat (path, &info) != 0)
return -1;if (info.st_uid != getuid())
return 0;
if (info.st_uid != geteuid())
return 0;return 1;
}Simple, everytime that a call access mapsets data a check is done
for the userid of the mapsets file to be equal to that of real and
effective ids of the invoking process. So if I own a mapset I can
work on it, if I do not own it I cannot regardeless of the unix
mapsets files privileges.
I have only one question, why ? I do not understand this idea.
Ok so I went forward and changed a little bit the code. But if we
release this constraint by for example commenting the last two ifs
in the call, we will have to check for access permission to the mapsets.
This is done at start time in gis_set. I've done some work on that
and modified the gis_set and the g.access programs.
Anyhow at this stage I do not think it is a good idea to post my bugfixes,
that are to be considered much more as tournarounds. A sound understanding
of the global grass structure and clear objectives on how to manage mapset
permissions are needed in order to produce a proper code.
So here I just want to point out that THIS IS AN IMPORTANT ISSUE. Clearly
if somebody is interested in having my patch I can send it. But I would first
like to understand the developping strategy beneath the G__mapset_permissions
call.
Comments are welcome
LP
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
Universita' di Padova TEL: +390498275527 -------
------------------------- FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--
Agustin Lobo wrote:
On Fri, 15 Oct 1999, Luca Palmeri wrote:
I disagree. In most cases, it is well as it is: different co-workers can
put their common stuff in PERMANENT, but each one would modify his/her
own mapsets only.
Agus, I perfectly agree with you. It wasn't my intention to purpose to adopt
my
method of managing mapset privileges for the official GRASS distribution. To
be clear I quote my self:
Luca Palmeri wrote:
My concern was on using multiple grass shells on different mapsets at the
same time from different machines in NFS.
I was only looking for a quick (and now I understand, also dirt) solution for
achieving this.
And I found that releasing a little bit the constraints on mapset privileges
helped me
in doing that.
I repeat, this is my very special case. I am assuming that I know very well
what I will do
on the dataset.
Ok finally I have to agree on the fact that probably the way it is in GRASS,
is
the best way to manage mapsets privileges in order to avoid all the risks you
cited in your mail, specially for wide working groups. I have been a little
bit too
nivety in opening such a question.
Anyway thanks to everybody in the list for the usefull discussion.
LP
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
Universita' di Padova TEL: +390498275527 -------
------------------------- FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--