[GRASS5] bug reports for GRASS 5.7

[Michael Barton]

Radim,

Thanks for the reply and clarification on the issues I reported below. 
You asked a few questions and I reply below.
On Monday, April 5, 2004, at 02:24  AM, Radim Blazek wrote:

> On Friday 02 April 2004 20:48, Michael Barton wrote:
>> **********************************
>>
>> v.reclass
>>
>> Is there no access to interactive rule-based reclassification? Is 
>> using
>> a file the only option?
>
> Yes.

This is too bad. The rules file is fine, but interactive 
reclassification is very nice for EDA and analysis.

>
>> The command seems to require either a rules
>> file or 'specifying a column'. But it is unclear what happens if you
>> specify a column. I did so and the module ran, saying it had created a
>> new reclassification, but there seems no specification for what is
>> reclassified. I'm not sure if this is a bug, but it is not running as 
>> I
>> might normally expect it to.
>
> Values from that column are used as new categories, the column must be 
> integer.

OK. Now I understand what is happening

> I have updated description.

This will be helpful to others too.

>
>> **********************************
>> s.in.ascii
>> Actually imports ascii files to vector points (not "sites"). Also, it
>> ignores any values after the xy(z) dimensions. That is, no attributes
>> imported. This is not a bug per se, but it seems that a way to input 
>> an
>> ascii file with xyz dimensions, plus attributes is a good thing to
>> have. The name should be changed perhaps. (v.points.in.ascii?)
>
> s.in/out.ascii modules are there only for tests of sites library which 
> in fact
> reads/writes vectors. Both s.in/out.ascii will be removed once all 
> modules
> using sites are rewritten to vectors.
>
> I agree that a module which can import ascii points is useful.
> v.in.ascii output= can import x|y[|z]|cat from stdin.
> We can add attributes, but tell me how to define column names and 
> types.
> It could be the part of SQL statement for create table?

Just put them in GRASS 5.7 native dbf format. The original s.in.ascii 
parser could identify integers (cat), floating point numbers 
(dimensions and fp attributes), and strings (or at least it is supposed 
to). Why not do a simple parse into integer, fp numbers, and strings. 
There could be a checkbox (flag) to ask the user if the first line of 
the file represents column names. If unchecked, the column names are 
just called var1, var2,... (or more sophicated, int1, int2...fp1, 
fp2,...strng1, strng2...).

As with the original s.in.ascii, dates will end up as strings. However, 
one can work with the table after the fact once it is in. Of course, it 
could be more clever, do an initial parsing and ask the user to specify 
field types, but I don't know if that is worth the trouble (it requires 
an interactive interface of course).

>
>> **********************************
>>
>> v.digit still won't accept commands for its background from the 
>> startup
>> GUI dialog. Here is the error.
>>
>> v.digit map=national_forest bgcmd=d.rast map=public_private -n
>> Map does not exist.
>> New empty map created.
>> Illegal vector map name <national_forest,public_private>. Character 
>> <,>
>> not allowed.
>> ERROR: Map name not SQL compliant.
>>
>> This WILL work from the command line (but not GUI dialog) if written
>> like this
>> v.digit map=national_forest bgcmd='d.rast map=public_private' -n
>
> I guess that TclTk 'open' function separates parameters by spaces and
> ignores quoting.

This is probably what is causing problems with SQL statements from the 
autogenerated GUI's also. Is it fixable?

>> **********************************
>>
>> v.select
>> The input buttons do not update to show current location and mapset. I
>> don't know where they get their input. They were showing a location I
>> was working a session or 2 ago.
>
> GRASS variables are read when the GUI is started, you have to close 
> and reopen
> GUI if mapset is changed.

This module was closed. I started GRASS 5.7 fresh. When I opened 
v.select for the first time after starting GRASS 5.7, the browse 
buttons were looking in a different location and mapset.

>
>> Also, the check boxes are confusing.
>> They don't indicate which vector file they are referring to.
>
> Because parameter name is not used, description must be extended.
> How to identify both vectors? 'a','b' or 'A', 'B' or '1.','2.' or ???

It is not the file entry boxes, but the check boxes are a problem. 
(However, I like 1 and 2 better than a and b. )

Currently, the GUI opens with the following format

<map a entry>
<map b entry>
<checkboxes for map a>
<checkboxes for map b>

However, there is nothing to indicate that the checkboxes go with map a 
and b respectively. Either need to clarify this in the checkbox 
description and/or put the checkboxes under the appropriate map entry.

<map a entry>
<checkboxes for map a>
<map b entry>
<checkboxes for  map b>



>
>> **********************************
>>
>> r.proj
>> Needs browse buttons to find raster maps
>
> Database and location are not known, so it is impossible to browse 
> maps.

How about the new file,file,file button specification???

Thanks again for responding so promptly.

Michael

______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671