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/