[GRASS5] [bug #2829] (grass) v.to.db: remove an option and am suddenly out of range

[Maciek Sieczka]

On pon, 2005-12-12 at 23:46 +0200, Wolf Bergenheim wrote:
> On 12/12/05 13:52, Maciek Sieczka via RT wrote:
> > This bug still applies.
> > 
> [SNIPP]
> > 
> > COMBINATION OF BOTH DOESN'T WORK:
> > 
> 
> Hi,
> 
> Maciek are you implying that this should be implemented?

I think I missenderstood original Dan's report. I thought Dan implied
that v.to.db accepts multiple "option" separated with comas in general,
but fails only for some combinations. That's what I deduced from Dan's:

$ v.to.db -p map=largeCat opt=cat,area,length,count,coor
63 categories read from map
0 records selected from table
0 categories read from map exist in selection from table
0 categories read from map don't exist in selection from table
0 records updated/inserted
0 update/insert errors
$ v.to.db -p map=largeCat opt=cat,length,count,coor
Error: value <cat,length,count,coor> out of range for parameter <option>
       Legal range: cat,area,length,count,coor,query


However, I RTM and understood "option" accepts only single parameters...

So now I see Dan's point is rather that he finds it surprising that
"opt=cat,area,length,count,coor" works and "opt=cat,length,count,coor"
doesn't, while actually both should not work at all. Dan, is that what
you mean?

Anyway, I can't reproduce this particular behaviour Dan is reporting.
Any set of multiple "option" I provide, "v.to.db -p" fails for me. Since
Dan's report comes from 5.7 era, maybe it is simply fixed now?

> so what exactly?

My missunderstanding was accelarated by what v.to.db reports to the
user, see the following:


$ v.to.db -p map=pkt column=cat opt=cat,count

Error: value <cat,count> out of range for parameter <option>
       Legal range:
cat,area,compact,perimeter,length,count,coor,sides,query


It is hard to understand how "value <cat,count>" is "out of range" for
"cat,area,compact,perimeter,length,count,coor,sides,query". But OK, my
fault, I should have read the manual first.


> if so what exactly?

Now, having explained myself (I hope), my opinion is that "v.to.db -p"
should should either work with more than one "option", or fail then with
an understandable information for the user. The latter would be easier
to implement I guess, and the first is not really necessary.

>  If a user issues many options to v.select,

Why v.select? Talking of v.to.db.

>  then at least the the  user also has to supply the columns where the data should be added.
> Right?

I (Dan originally too) am using the -p switch, just to print the output,
not to populate it to a table.

>  Do you think v.to.db should simply use the column names equal to
> the options? That could be a convenient default.

That might be good. Some Grass modules which require creating a new
column in the table do it themselves (eg. r.to.vect, v.to.points), some
leave it to the user (v.distance, v.sample). I wish this could be
unified for all Grass modules:
1. If the user doesn't specify the column name a column with a
reasonable default name is created and populated.
2. The possibility to override column name by user is preserved.


> Dan: What did you expect to happen when you issued the command
> "v.to.db -p map=largeCat opt=cat,length,count,coor"?

Maciek


--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.epf.pl/