[GRASS5] bug reports for GRASS 5.7

[Radim Blazek]

On Monday 05 April 2004 18:01, Michael Barton wrote:
> > 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).

It sounds reasonable.

> >> 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. )

I have changed the order of options in v.select and v.overlay, 
all option's description changes I leave for English+GIS speaking contributors.

Radim