I am writing some scripts, but I can't make them work with the @mapset
in the rasters names. any special trick?
there is one script attached.
thanks
Carlos
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
On Mon, 2007-07-02 at 22:15 +0100, Carlos "Guâno" Grohmann wrote:
Helo all,
I am writing some scripts, but I can't make them work with the @mapset
in the rasters names. any special trick?
there is one script attached.
Hello Carlos,
in g.findfile documentation it says, that the mapset has to be set using
its own option, and then it will look in that mapset for the file. The
case 'map1@mapset1' should be done:
g.findfile element=cell mapset=mapset1 file=map1
whereas your script seems to do:
g.findfile element=cell file='map1@mapset1'
In the latter case, I guess the g.findfile only looks in the current
mapset, and even thought there might be a file called 'map1' there
probably isn't a file called 'map1@mapset1'. I guess you probably need
to parse the 'map' option of your script and separate the mapname from
the mapsetname.
if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut
-f2 -d=` ] ; then
g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting."
exit 1
fi
by
slope=$GIS_OPT_SLOPE
eval `g.findfile element=cell file=$slope`
if [ -z "$name" ] ; then
g.message -e "Map <$slope> not found! Aborting."
exit 1
fi
and now it works fine.
thanks
Carlos
On 7/2/07, Harri Kiiskinen <harkiisk@utu.fi> wrote:
On Mon, 2007-07-02 at 22:15 +0100, Carlos "Guâno" Grohmann wrote:
> Helo all,
>
> I am writing some scripts, but I can't make them work with the @mapset
> in the rasters names. any special trick?
>
> there is one script attached.
Hello Carlos,
in g.findfile documentation it says, that the mapset has to be set using
its own option, and then it will look in that mapset for the file. The
case 'map1@mapset1' should be done:
g.findfile element=cell mapset=mapset1 file=map1
whereas your script seems to do:
g.findfile element=cell file='map1@mapset1'
In the latter case, I guess the g.findfile only looks in the current
mapset, and even thought there might be a file called 'map1' there
probably isn't a file called 'map1@mapset1'. I guess you probably need
to parse the 'map' option of your script and separate the mapname from
the mapsetname.
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut
-f2 -d=` ] ; then
g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting."
exit 1
fi
by
slope=$GIS_OPT_SLOPE
eval `g.findfile element=cell file=$slope`
if [ -z "$name" ] ; then
g.message -e "Map <$slope> not found! Aborting."
exit 1
fi
and now it works fine.
Why do you actually need to use g.findfile? In most cases, you should
just pass the map name directly to the command, and let the command
handle the checking.
Also, if you use g.parser and the options have the appropriate
"gisprompt" setting, g.parser will perform the relevant checks, so
there's no need to repeat them.
On 7/3/07, Glynn Clements <glynn@gclements.plus.com> wrote:
"Carlos \"Guâno\" Grohmann" wrote:
> I went look in r.shade.relief, so I changed
>
> if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut
> -f2 -d=` ] ; then
> g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting."
> exit 1
> fi
>
> by
> slope=$GIS_OPT_SLOPE
>
> eval `g.findfile element=cell file=$slope`
> if [ -z "$name" ] ; then
> g.message -e "Map <$slope> not found! Aborting."
> exit 1
> fi
>
> and now it works fine.
Why do you actually need to use g.findfile? In most cases, you should
just pass the map name directly to the command, and let the command
handle the checking.
Also, if you use g.parser and the options have the appropriate
"gisprompt" setting, g.parser will perform the relevant checks, so
there's no need to repeat them.
--
Glynn Clements <glynn@gclements.plus.com>
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
I said it worked but I shouldn't.
the @mapset is not a problem when the maps are used by some command,
like r.mapcalc, bu it is a problem because the default output map (if
you don't give a name) will be based on the input, like:
input : in_map
output : in_map_roughness_3x3
so I need to get rid of the @mapset, or else it will be set to
in_map@mapset_roughness_3x3
and r.mapcalc will fail.
Carlos
On 7/3/07, Carlos Guâno Grohmann <carlos.grohmann@gmail.com> wrote:
I just copied the stuff from r.shaded.relief..
On 7/3/07, Glynn Clements <glynn@gclements.plus.com> wrote:
>
> "Carlos \"Guâno\" Grohmann" wrote:
>
> > I went look in r.shade.relief, so I changed
> >
> > if [ -z `g.findfile elem=cell file="$GIS_OPT_SLOPE" | grep ^file | cut
> > -f2 -d=` ] ; then
> > g.message -e "<$GIS_OPT_SLOPE> does not exist! Aborting."
> > exit 1
> > fi
> >
> > by
> > slope=$GIS_OPT_SLOPE
> >
> > eval `g.findfile element=cell file=$slope`
> > if [ -z "$name" ] ; then
> > g.message -e "Map <$slope> not found! Aborting."
> > exit 1
> > fi
> >
> > and now it works fine.
>
> Why do you actually need to use g.findfile? In most cases, you should
> just pass the map name directly to the command, and let the command
> handle the checking.
>
> Also, if you use g.parser and the options have the appropriate
> "gisprompt" setting, g.parser will perform the relevant checks, so
> there's no need to repeat them.
>
> --
> Glynn Clements <glynn@gclements.plus.com>
>
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
Why do you actually need to use g.findfile? In most cases, you should
just pass the map name directly to the command, and let the command
handle the checking.
It's better to check if the output exists in the initial stage of my
script, than to let it run for an hour and then fail with an error that
the output already exists in the end.
Why do you actually need to use g.findfile? In most cases, you should
just pass the map name directly to the command, and let the command
handle the checking.
It's better to check if the output exists
Oops! Sorry, I missed the fact that you are talking about the *input*.
GRASS always handled well the non-existance of input, for me. Only
output name needs to be controlled in the script to avoid running long
scripts for nothing.
the @mapset is not a problem when the maps are used by some command,
like r.mapcalc, bu it is a problem because the default output map (if
you don't give a name) will be based on the input, like:
input : in_map
output : in_map_roughness_3x3
so I need to get rid of the @mapset, or else it will be set to
On 7/4/07, Hamish <hamish_nospam@yahoo.com> wrote:
Carlos \ wrote:
> the @mapset is not a problem when the maps are used by some command,
> like r.mapcalc, bu it is a problem because the default output map (if
> you don't give a name) will be based on the input, like:
> input : in_map
> output : in_map_roughness_3x3
>
> so I need to get rid of the @mapset, or else it will be set to
>
> in_map@mapset_roughness_3x3
>
> and r.mapcalc will fail.
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
> the @mapset is not a problem when the maps are used by some command,
> like r.mapcalc, bu it is a problem because the default output map (if
> you don't give a name) will be based on the input, like:
> input : in_map
> output : in_map_roughness_3x3
>
> so I need to get rid of the @mapset, or else it will be set to
>
> in_map@mapset_roughness_3x3
>
> and r.mapcalc will fail.
> Why do you actually need to use g.findfile? In most cases, you should
> just pass the map name directly to the command, and let the command
> handle the checking.
It's better to check if the output exists in the initial stage of my
script, than to let it run for an hour and then fail with an error that
the output already exists in the end.
If the output map is specified by an option whose "gisprompt" setting
includes "new", g.parser will automatically ensure that it doesn't
exist unless --o[verwrite] is given or $GRASS_OVERWRITE == 1.
Also, if --o is passed to the script, GRASS_OVERWRITE will be set
automatically, so any commands invoked from the script will overwrite
output maps.
Why do you actually need to use g.findfile? In most cases, you should
just pass the map name directly to the command, and let the command
handle the checking.
It's better to check if the output exists in the initial stage of my
script, than to let it run for an hour and then fail with an error that
the output already exists in the end.
If the output map is specified by an option whose "gisprompt" setting
includes "new", g.parser will automatically ensure that it doesn't
exist unless --o[verwrite] is given or $GRASS_OVERWRITE == 1.
You are correct. The reason that this has not worked for me like that
is that I've been using "gisprompt: new,dig,vector" instead of
"gisprompt: new,vector,vector".
I must have copied this "gisprompt: new,dig,vector" from some GRASS 5
script and sticked to that. None of the scripts in 6.3 uses it. Is this
not supposed to be recognised by g.parser indeed? There isn't any error
message that this is incorrect. Should there be one?
Grepping through the GRASS 6.3 source code I can see that v.surf.rst
still uses the old syntax in main.c twice. Should that be fixed?
>>> Why do you actually need to use g.findfile? In most cases, you should
>>> just pass the map name directly to the command, and let the command
>>> handle the checking.
>> It's better to check if the output exists in the initial stage of my
>> script, than to let it run for an hour and then fail with an error that
>> the output already exists in the end.
>
> If the output map is specified by an option whose "gisprompt" setting
> includes "new", g.parser will automatically ensure that it doesn't
> exist unless --o[verwrite] is given or $GRASS_OVERWRITE == 1.
You are correct. The reason that this has not worked for me like that
is that I've been using "gisprompt: new,dig,vector" instead of
"gisprompt: new,vector,vector".
I must have copied this "gisprompt: new,dig,vector" from some GRASS 5
script and sticked to that. None of the scripts in 6.3 uses it. Is this
not supposed to be recognised by g.parser indeed? There isn't any error
message that this is incorrect. Should there be one?
g.parser is just a front-end to G_parser(). The syntax of "valid"
options is essentially whatever G_parser() accepts. In turn,
G_parser() silently ignores any gisprompt keys which it doesn't
understand.
Grepping through the GRASS 6.3 source code I can see that v.surf.rst
still uses the old syntax in main.c twice. Should that be fixed?