Thu, Dec 9 2004
06:47:55
|
|
Request created by jidanni@jidanni.org
|
|
Return-Path |
<jidanni@jidanni.org>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
To |
grass-bugs@intevation.de
|
Subject |
v.to.db: remove an option and am suddenly out of range
|
From |
Dan Jacobson <jidanni@jidanni.org>
|
Date |
Thu, 09 Dec 2004 10:14:15 +0800
|
Message-ID |
<87y8g85ibs.fsf@jidanni.org>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
X-Spam-Status |
No, hits=-4.4 tagged_above=-999.0 required=3.0 tests=BAYES_00, DATE_IN_PAST_03_06, HTML_MESSAGE
|
X-Spam-Level |
|
I remove an option and am suddenly out of range, 5.7.0:
$ 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
|
|
Mon, Dec 12 2005
12:52:52
|
|
Mail sent by msieczka
|
|
This bug still applies.
THIS WORKS:
$ v.to.db -p map=pkt column=cat opt=count
cat|count
1|1
1 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=pkt column=cat opt=cat
cat
1
1 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
COMBINATION OF BOTH DOESN'T WORK:
$ 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
|
|
Mon, Dec 12 2005
12:52:59
|
|
Area changed to grass6 by msieczka
|
|
Mon, Dec 12 2005
22:47:40
|
|
Mail sent by wolf+grass@bergenheim.net
|
|
Return-Path |
<wolf+grass@bergenheim.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<439DEFD0.50202@bergenheim.net>
|
Date |
Mon, 12 Dec 2005 23:46:56 +0200
|
From |
Wolf Bergenheim <wolf+grass@bergenheim.net>
|
User-Agent |
Debian Thunderbird 1.0.7 (X11/20051018)
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
jidanni@jidanni.org, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2829] (grass) v.to.db: remove an option and am suddenly out of range
|
References |
<20051212115252.A2CF9101F06@lists.intevation.de>
|
In-Reply-To |
<20051212115252.A2CF9101F06@lists.intevation.de>
|
Content-Type |
text/plain; charset=ISO-8859-15
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
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? If so what
exactly? If a user issues many options to v.select, then at least the
the user also has to supply the columns where the data should be added.
Right? Do you think v.to.db should simply use the column names equal to
the options? That could be a convenient default.
Dan: What did you expect to happen when you issued the command
"v.to.db -p map=largeCat opt=cat,length,count,coor"?
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
|
|
Tue, Dec 13 2005
10:40:18
|
|
Mail sent by werchowyna@epf.pl
|
|
Return-Path |
<werchowyna@epf.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Subject |
Re: [GRASS5] [bug #2829] (grass) v.to.db: remove an option and am suddenly out of range
|
From |
Maciek Sieczka <werchowyna@epf.pl>
|
To |
Wolf Bergenheim <wolf+grass@bergenheim.net>
|
Cc |
Maciek Sieczka via RT <grass-bugs@intevation.de>, jidanni@jidanni.org, grass5@grass.itc.it
|
In-Reply-To |
<439DEFD0.50202@bergenheim.net>
|
References |
<20051212115252.A2CF9101F06@lists.intevation.de> <439DEFD0.50202@bergenheim.net>
|
Content-Type |
text/plain
|
Date |
Tue, 13 Dec 2005 10:40:06 +0100
|
Message-Id |
<1134466806.8907.59.camel@localhost.localdomain>
|
Mime-Version |
1.0
|
X-Mailer |
Evolution 2.2.1.1
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.8 tagged_above=-999.0 required=3.0 tests=BAYES_00, HTML_MESSAGE
|
X-Spam-Level |
|
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/
|
|
Tue, Dec 13 2005
11:05:17
|
|
Mail sent by radim.blazek@gmail.com
|
|
Return-Path |
<radim.blazek@gmail.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
DomainKey-Signature |
a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rHLMVqtQesflJcPbpSp5qzINuZ5E8BFXMXglfshD3qX4fSWCyaSK1h6QfzKgSHTGkkWGgAlq2KB4l2cdQCeK7JCoiUbe56wvuTurB7AgOtY5HNdwOLEUKxY62QEqSOwQlQlRgcTKlN5po3NxjkbMHzH847mkwYK3175aZwU8hfM=
|
Message-ID |
<340505ef0512130205k2a37cd34v75f9577acd6e82e6@mail.gmail.com>
|
Date |
Tue, 13 Dec 2005 11:05:13 +0100
|
From |
Radim Blazek <radim.blazek@gmail.com>
|
To |
Maciek Sieczka <werchowyna@epf.pl>
|
Subject |
Re: [GRASS5] [bug #2829] (grass) v.to.db: remove an option and am suddenly out of range
|
Cc |
Wolf Bergenheim <wolf+grass@bergenheim.net>, Maciek Sieczka via RT <grass-bugs@intevation.de>, jidanni@jidanni.org, grass5@grass.itc.it
|
In-Reply-To |
<1134466806.8907.59.camel@localhost.localdomain>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=ISO-8859-1
|
Content-Transfer-Encoding |
quoted-printable
|
Content-Disposition |
inline
|
References |
<20051212115252.A2CF9101F06@lists.intevation.de> <439DEFD0.50202@bergenheim.net> <1134466806.8907.59.camel@localhost.localdomain>
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On 12/13/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> > 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).
That is OK. There are 2 different groups of modules.
1) r.to.vect,v.to.points... create a new vector
2) v.distance, v.sample.. modify existing vector
> 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.
That would be bad in my opinion, because if user forgets to give
a column name the module can modify his data. It sounds too Windows like,
I mean it automaticaly does something what you dont want.
I suggest to add a new flag (e.g. -c) to create a new column
(specified by user) if it does not exist.
I consider the inconsistency between those 2 groups of
commands as a problem. Most GRASS vector modules read input
and write output. Only the modules updating tables (v.to.db, v.distance,
v.what.rast) modify existing vector. If a user specifies wrong column name
he can demage his data.
Radim
|
|
Tue, Dec 13 2005
11:39:26
|
|
Mail sent by werchowyna@epf.pl
|
|
Return-Path |
<werchowyna@epf.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Subject |
Re: [GRASS5] [bug #2829] (grass) v.to.db: remove an option and am suddenly out of range
|
From |
Maciek Sieczka <werchowyna@epf.pl>
|
To |
Radim Blazek <radim.blazek@gmail.com>
|
Cc |
Wolf Bergenheim <wolf+grass@bergenheim.net>, Maciek Sieczka via RT <grass-bugs@intevation.de>, jidanni@jidanni.org, grass5@grass.itc.it
|
In-Reply-To |
<340505ef0512130205k2a37cd34v75f9577acd6e82e6@mail.gmail.com>
|
References |
<20051212115252.A2CF9101F06@lists.intevation.de> <439DEFD0.50202@bergenheim.net> <1134466806.8907.59.camel@localhost.localdomain> <340505ef0512130205k2a37cd34v75f9577acd6e82e6@mail.gmail.com>
|
Content-Type |
text/plain
|
Date |
Tue, 13 Dec 2005 11:39:21 +0100
|
Message-Id |
<1134470361.10555.14.camel@localhost.localdomain>
|
Mime-Version |
1.0
|
X-Mailer |
Evolution 2.2.1.1
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On wto, 2005-12-13 at 11:05 +0100, Radim Blazek wrote:
> On 12/13/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> > 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.
>
> That would be bad in my opinion, because if user forgets to give
> a column name the module can modify his data. It sounds too Windows like,
> I mean it automaticaly does something what you dont want.
>
> I suggest to add a new flag (e.g. -c) to create a new column
> (specified by user) if it does not exist.
You are right. That would be the best solution.
Maciek
--------------------
W polskim Internecie są setki milionów stron. My przekazujemy Tobie tylko najlepsze
z nich!
http://katalog.epf.pl/
|
|
Tue, Dec 13 2005
14:37:20
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 14 Dec 2005 02:37:05 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka <werchowyna@epf.pl>
|
Cc |
grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #2829] (grass) v.to.db: remove an option and am suddenly out of range
|
Message-Id |
<20051214023705.5930845e.hamish_nospam@yahoo.com>
|
In-Reply-To |
<1134466806.8907.59.camel@localhost.localdomain>
|
References |
<20051212115252.A2CF9101F06@lists.intevation.de> <439DEFD0.50202@bergenheim.net> <1134466806.8907.59.camel@localhost.localdomain>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> 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?
(Without checking,) it only wants one opt, but if you pass it the entire
string it gets past the parser check, which is the (possible) error.
the parser is told to check against
"cat,area,length,count,coor"
if an exact match, it thinks it is ok (maybe correct in some cases).
otherwise it splits up the list and checks each value. gets complicated
with e.g. v.clean which can take multiple options.
If multiple answers are ok, need to match the number of selected options
to number of column names given, check for duplicates, etc..
Hamish
|
|
Tue, Dec 13 2005
14:39:30
|
|
Mail sent by wolf+grass@bergenheim.net
|
|
Return-Path |
<wolf+grass@bergenheim.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<439ECEE5.4070107@bergenheim.net>
|
Date |
Tue, 13 Dec 2005 15:38:45 +0200
|
From |
Wolf Bergenheim <wolf+grass@bergenheim.net>
|
User-Agent |
Debian Thunderbird 1.0.7 (X11/20051018)
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
To |
Maciek Sieczka <werchowyna@epf.pl>
|
Cc |
grass-bugs@intevation.de, jidanni@jidanni.org
|
Subject |
Re: [GRASS5] [bug #2829] (grass) v.to.db: remove an option and am suddenly out of range
|
References |
<20051212115252.A2CF9101F06@lists.intevation.de> <439DEFD0.50202@bergenheim.net> <1134466806.8907.59.camel@localhost.localdomain>
|
In-Reply-To |
<1134466806.8907.59.camel@localhost.localdomain>
|
Content-Type |
text/plain; charset=ISO-8859-15
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.8 tagged_above=-999.0 required=3.0 tests=BAYES_00, HTML_MESSAGE
|
X-Spam-Level |
|
On 13/12/05 11:40, Maciek Sieczka wrote:
>
> 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?
>
Might be. Current code does not allow multiple option parameters. I
think that the function G_parser is the one responsible for the
confusing error message.
>
>>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.
>
Agreed. The error message is defenately confusing. THat could be
improved, or then documented more clearly.
>
>> If a user issues many options to v.select,
>
>
> Why v.select? Talking of v.to.db.
>
er.. I was probably working with v.select when I wrote the email. I
meant 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.
>
Yes, but I think that the behaviour of option should be regardless of -p
flag. So we are potentially updating. And I didn't notice the -p flag.
>
>> 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.
>
I agree with Radim, the -c flag could be used, and also issue a warning.
But thene there are the v.to.db options that use 2 or 3 columns (coor,
start, end). Should these default to start_x start_y etc, or do you
think that these options should not be combined? how should the list of
rows be interpeted if these are allowed to be combined? Or would it be
simply too confusing? THinking more about the problem, I think that
combining options in v.to.db is simply too complex, if the case that you
explicitly request column names. Perhaps if column is given then only
allow one option?
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
|
|
Thu, Sep 21 2006
14:29:25
|
|
Subject changed to v.to.db: the option is parsed wrong if all oprions are listed by msieczka
|
|
Thu, Sep 21 2006
14:29:38
|
|
Subject changed to v.to.db: the 'option' is parsed wrong if all oprions are listed by msieczka
|
|
Thu, Sep 21 2006
17:09:24
|
|
Subject changed to v.to.db: the 'option' is parsed wrong if multiple 'option's are given in particular order by msieczka
|
|
Thu, Sep 21 2006
17:10:54
|
|
Mail sent by msieczka
|
|
Markus,
As you have just fixed one parser error in the v.to.db, do you mind if I
trigger your attention to another long-standing one?
If all the valid 'options', or specific combinations of them, are listed in a
row, v.to.db accepts it *if they come in the same order as the are listed in
the Description*.
spearfish60
For example - this works while it should not:
$ v.to.db -p map=landuse
option=cat,area,compact,perimeter,length,count,coor,start,end,sides,query
type=centroid col=col1
8 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
I can remove an option from the end of the comma-separated list and from the
beginnig, and this will still work:
$ v.to.db -p map=landuse
option=area,compact,perimeter,length,count,coor,start,end,sides type=centroid
col=col1
And this too:
v.to.db -p map=landuse option=perimeter,length,count,coor type=centroid col=col1
But if I take out one somewhere in the middle *so that the order they are
listed in Description IS NOT PRESERVED*, v.to.db returns an error like it should:
$ v.to.db -p map=landuse option=perimeter,length,coor type=centroid col=col1
Error: value <perimeter,length,coor> out of range for parameter <option>
Legal range:
cat,area,compact,perimeter,length,count,coor,start,end,sides,query
Maciek
|
|