Subject: r.colors - new rules=name option not yet working
I tried the new rules=[filename] option. It generates ERROR: Unable to open rules file [filename].
Then it stops all processing until a ctrl-C is pressed. I tried a simple rules file:
1 blue
2 green
end
(I tried it with and without 'end' and got the same result)
Also, it won't even get this far from the autogenerated GUI because it conflicts with the type=[option]
argument. There needs to be a 'none' selection for the type option in the GUI header.
-------------------------------------------- Managed by Request Tracker
this bug's URL: http://intevation.de/rt/webrt?serial_num=2402
---------------------------------------------------------------------
Subject: r.colors - new rules=name option not yet working
I tried the new rules=[filename] option. It generates ERROR: Unable to
open rules file [filename]. Then it stops all processing until a
ctrl-C is pressed. I tried a simple rules file:
1 blue
2 green
end
(I tried it with and without 'end' and got the same result)
The rules file needs to be in the $GISBASE/etc/colors/ directory. I just
added a few more: terrain, bcyr, slope, and elevation. You can try
copying over the four example files from src/raster/r.colors/cmd/ as
well, some are nice.
Also, it won't even get this far from the autogenerated GUI because it
conflicts with the type=[option] argument. There needs to be a 'none'
selection for the type option in the GUI header.
The GUI and man page will be updated at some point to cover both these
issues..
Subject: r.colors - new rules=name option not yet working
I tried the new rules=[filename] option. It generates ERROR: Unable to
open rules file [filename].
Where [filename] is what? Does the file actually exist in the
$GISBASE/etc/colors directory?
Then it stops all processing until a ctrl-C is pressed.
Actually, it pauses for 5 seconds after an error, then exits. Whether
it should pause is debatable.
I tried a
simple rules file:
1 blue
2 green
end
(I tried it with and without 'end' and got the same result)
Are you expecting rules= to read a rules file from the current
directory? Because that isn't what the rules= option is meant for. If
you want it to read your own rules file, use color=rules and shell
redirection e.g.:
r.colors mapname color=rules < rulesfile
Also, it won't even get this far from the autogenerated GUI because it
conflicts with the type=[option] argument. There needs to be a 'none'
selection for the type option in the GUI header.
It needs to be a separate menu entry; exactly the same issue also
applies to the rast= option.
On Mon, May 10, 2004 at 05:30:19PM +1200, Hamish wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2402
> ---------------------------------------------------------------------
> Subject: r.colors - new rules=name option not yet working
>
> I tried the new rules=[filename] option. It generates ERROR: Unable to
> open rules file [filename]. Then it stops all processing until a
> ctrl-C is pressed. I tried a simple rules file:
>
> 1 blue
> 2 green
> end
>
> (I tried it with and without 'end' and got the same result)
The rules file needs to be in the $GISBASE/etc/colors/ directory.
I have added the path to the message. Now the user knows where
the file is searched:
r.colors N45E008.meters rules=test.rul
ERROR: Unable to open rules file test.rul in
/nfsmnt/ssi0/ssi/neteler/grass57/dist.i686-pc-linux-gnu/etc/colors/test.rul
I just added a few more: terrain, bcyr, slope, and elevation. You can try
copying over the four example files from src/raster/r.colors/cmd/ as
well, some are nice.
Fixed also in 5.7 now.
> Also, it won't even get this far from the autogenerated GUI because it
> conflicts with the type=[option] argument. There needs to be a 'none'
> selection for the type option in the GUI header.
The GUI and man page will be updated at some point to cover both these
issues..
Left to the author
On command line it's functional now in 5.7.
On Mon, May 10, 2004 at 08:08:54AM +0100, Glynn Clements wrote:
...
> Also, it won't even get this far from the autogenerated GUI because it
> conflicts with the type=[option] argument. There needs to be a 'none'
> selection for the type option in the GUI header.
It needs to be a separate menu entry; exactly the same issue also
applies to the rast= option.
What about a function which reports the names of the currently
existing files in $GISBASE/etc/colors/ ? A function which
returns the file names as comma separated list? Then
the 5.7 GUI would auto-generate a selection box, and the cmd
line version would show the names (so no further blind guessing).
> > Subject: r.colors - new rules=name option not yet working
> >
> > I tried the new rules=[filename] option. It generates ERROR: Unable to
> > open rules file [filename]. Then it stops all processing until a
> > ctrl-C is pressed. I tried a simple rules file:
> >
> > 1 blue
> > 2 green
> > end
> >
> > (I tried it with and without 'end' and got the same result)
>
> The rules file needs to be in the $GISBASE/etc/colors/ directory.
I have added the path to the message. Now the user knows where
the file is searched:
r.colors N45E008.meters rules=test.rul
ERROR: Unable to open rules file test.rul in
/nfsmnt/ssi0/ssi/neteler/grass57/dist.i686-pc-linux-gnu/etc/colors/test.rul
This is the wrong solution; a user doesn't need this information. A
better solution would be to list the set of valid options. If the list
was constructed and set as opt4->options, G_parser() would do this
automatically; however, the list could easily become quite large.
The original problem seems to stem from the user thinking that rules=
was meant for using user-supplied rule files. It isn't; color=rules
and shell redirection is the correct solution in that case. I'll fix
that problem by removing the word "file" from the option's
description, e.g.
opt4->description = "name of predefined rule set";
rules= is meant to be analogous to color=, and may well be eliminated
in future (i.e. rules= will be renamed to color=). I just didn't want
to mess up the existing color= behaviour until the new code had some
testing and the "exceptions" (i.e. color=grey.eq/grey.log/random/rules)
had been dealt with.
> > Also, it won't even get this far from the autogenerated GUI because it
> > conflicts with the type=[option] argument. There needs to be a 'none'
> > selection for the type option in the GUI header.
>
> It needs to be a separate menu entry; exactly the same issue also
> applies to the rast= option.
What about a function which reports the names of the currently
existing files in $GISBASE/etc/colors/ ? A function which
returns the file names as comma separated list?
The problem here is that the list could grow rather quickly now that
it can be extended without having to write any code.
Subject: r.colors - new rules=name option not yet working
I tried the new rules=[filename] option. It generates ERROR: Unable to
open rules file [filename]. Then it stops all processing until a
ctrl-C is pressed. I tried a simple rules file:
1 blue
2 green
end
(I tried it with and without 'end' and got the same result)
The rules file needs to be in the $GISBASE/etc/colors/ directory.
I have added the path to the message. Now the user knows where
the file is searched:
r.colors N45E008.meters rules=test.rul
ERROR: Unable to open rules file test.rul in
/nfsmnt/ssi0/ssi/neteler/grass57/dist.i686-pc-linux-gnu/etc/colors/test.rul
This is the wrong solution; a user doesn't need this information. A
better solution would be to list the set of valid options. If the list
was constructed and set as opt4->options, G_parser() would do this
automatically; however, the list could easily become quite large.
The original problem seems to stem from the user thinking that rules=
was meant for using user-supplied rule files. It isn't; color=rules
and shell redirection is the correct solution in that case.
I very much agree with Glynn, as shown in his previous message
the user supplied rule file should be done through redirection of the rules file
r.colors mapname color=rules < rulesfile
adding the rules= would be confusing (sorry for saying it this late,
I was away and could not respond when it was suggested).
Helena
I'll fix
that problem by removing the word "file" from the option's
description, e.g.
opt4->description = "name of predefined rule set";
rules= is meant to be analogous to color=, and may well be eliminated
in future (i.e. rules= will be renamed to color=). I just didn't want
to mess up the existing color= behaviour until the new code had some
testing and the "exceptions" (i.e. color=grey.eq/grey.log/random/rules)
had been dealt with.
> > > Also, it won't even get this far from the autogenerated GUI
> > > because it conflicts with the type=[option] argument. There
> > > needs to be a 'none' selection for the type option in the GUI
> > > header.
> >
> > It needs to be a separate menu entry; exactly the same issue also
> > applies to the rast= option.
>
> What about a function which reports the names of the currently
> existing files in $GISBASE/etc/colors/ ? A function which
> returns the file names as comma separated list?
The problem here is that the list could grow rather quickly now that
it can be extended without having to write any code.
I don't see this as a big problem if the default install is limited to
a dozen or so default color scales (we shouldn't be drowning the users
with many like options IMO).
If someone wants to install 200 custom rules files, they get to deal
with the consequences... same as if they installed 200 TT fonts on their
computer.
Perhaps we should add a -l flag to list available rules? Then the
default help page/parser stays clean.
