Details Ticket 2829


Comment | Reply | Take | Resolve


Serial Number 2829
Subject v.to.db: the 'option' is parsed wrong if multiple 'option's are given in particular order
Area grass6
Queue grass
Requestors jidanni@jidanni.org
Owner none
Status open
Last User Contact Thu Sep 21 17:10:54 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu Sep 21 17:10:54 2006 (2 yr ago)
Created Thu Dec 9 06:47:55 2004 (4 yr ago)

Transaction History Ticket 2829


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
Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request