As with GRASS 5.7, I've been doing considerable testing of GRASS 5.3. Overall, it is highly stable and works very well. Here are a couple of minor items that perhaps could be fixed before it is released as stable.
1. v.transform does not operate correctly, at least under Mac OSX. It requires an ASCII vector file as input, looks in the dig_ASCII folder, but will not recognize an ASCII vector file unless it is put (manually and incorrectly) into the dig folder. It produces an incomplete output file (header and attributes, but no vectors). This was a problem on an earlier release; I have tried this on the the 12 January CVS snapshot and it is still a problem.
2. A small annoying item with r.colors under tcltk. If you check the 'rules' box, nothing happens. It **should** go to a terminal screen and allow you to enter a set of color rules. This is what happens if you use r.color via the terminal command line.
3. v.in.dxf doesn't work correctly with at least some dxf files with attributes. It does nothing if attributes are attached. I've only tried this with dxf files produced by MapInfo, so that may be the problem. If anyone has some insight, they might look into it.
# 3 is also a problem under 5.0.x; I don't know if #1 & 2 are also inherited from 5.0. So far, that's pretty much it that I've run into that doesn't work as advertised. All told, that is extremely good.
_____________________________
C. Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
2. A small annoying item with r.colors under tcltk. If you check the
'rules' box, nothing happens. It **should** go to a terminal screen and
allow you to enter a set of color rules. This is what happens if you
use r.color via the terminal command line.
Whether or not to use an xterm is set on a per-module basis; it isn't
possible to only use one when certain options are used. So, we need to
enable the use of an xterm always.
Also, the tcltkgrass interface doesn't support the use of the rast=
option.
On Friday 16 January 2004 17:13, Michael Barton wrote:
As with GRASS 5.7, I've been doing considerable testing of GRASS 5.3.
Overall, it is highly stable and works very well. Here are a couple of
minor items that perhaps could be fixed before it is released as stable.
1. v.transform does not operate correctly, at least under Mac OSX. It
requires an ASCII vector file as input, looks in the dig_ASCII folder,
but will not recognize an ASCII vector file unless it is put (manually
and incorrectly) into the dig folder. It produces an incomplete output
file (header and attributes, but no vectors). This was a problem on an
earlier release; I have tried this on the the 12 January CVS snapshot
and it is still a problem.
v.transform was rewritten to read and write vector binary file.
> 2. A small annoying item with r.colors under tcltk. If you check the
>
> 'rules' box, nothing happens. It **should** go to a terminal screen
> and allow you to enter a set of color rules. This is what happens if
> you use r.color via the terminal command line.
Whether or not to use an xterm is set on a per-module basis; it isn't
possible to only use one when certain options are used. So, we need to
enable the use of an xterm always.
For now I just removed the "color=rules" option from the menu. There
should be a message displayed telling the user they can use the command
line if they want to do something more complicated, but I don't know how
to do that..
Also, the tcltkgrass interface doesn't support the use of the rast=
option.
Thanks. This will be an improvement to the menu. Thinking about it, is it possible to do a r.colors ... colors=rules from the tcltk menu if it is a separate menu selection (i.e., with its own dialog)?
Michael Barton
On Wednesday, January 28, 2004, at 07:43 PM, Hamish wrote:
2. A small annoying item with r.colors under tcltk. If you check the
'rules' box, nothing happens. It **should** go to a terminal screen
and allow you to enter a set of color rules. This is what happens if
you use r.color via the terminal command line.
Whether or not to use an xterm is set on a per-module basis; it isn't
possible to only use one when certain options are used. So, we need to
enable the use of an xterm always.
For now I just removed the "color=rules" option from the menu. There
should be a message displayed telling the user they can use the command
line if they want to do something more complicated, but I don't know how
to do that..
Also, the tcltkgrass interface doesn't support the use of the rast=
option.
Added. Also added some missing color= options.
Hamish
____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
> For now I just removed the "color=rules" option from the menu. There
> should be a message displayed telling the user they can use the command
> line if they want to do something more complicated, but I don't know
> how
> to do that..
Thanks. This will be an improvement to the menu. Thinking about it, is
it possible to do a r.colors ... colors=rules from the tcltk menu if it
is a separate menu selection (i.e., with its own dialog)?
Yes. There are already separate entries for "v.support option=build"
and "v.support option=edit".
The following module file should suffice:
interface_build {
{r.colors color=rules} 1
{Creates/Modifies the color table from a list of rules.}
{entry map {Raster map:} 0 raster}
{separator grey 1}
{checkbox -w {Don't overwrite existing color table.} "" -w}
{checkbox -q {Run quietly.} "" -q}
}