Hi,
while d.vect is able to provide in the wxGUI the list of available
columns other modules are yet unable (v.db.univar, v.*).
I wonder where the trick to implement is 
Markus
Hi,
2011/9/27 Markus Neteler <neteler@osgeo.org>:
while d.vect is able to provide in the wxGUI the list of available
columns other modules are yet unable (v.db.univar, v.*).
it should work for almost all vector modules (please report modules,
where it doesn't work).
There is a bug in v.db.univar - option <table> wrongly defines
gisprompt for vector. Fixed in r48508.
BTW, I would expect from this module options like `map` and `layer`,
not `table`, `driver` and `database`. Modules `v.db.` should come with
`map` option, or I am wrong?
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Tue, Sep 27, 2011 at 11:26 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/9/27 Markus Neteler <neteler@osgeo.org>:
while d.vect is able to provide in the wxGUI the list of available
columns other modules are yet unable (v.db.univar, v.*).it should work for almost all vector modules (please report modules,
where it doesn't work).There is a bug in v.db.univar - option <table> wrongly defines
gisprompt for vector. Fixed in r48508.BTW, I would expect from this module options like `map` and `layer`,
not `table`, `driver` and `database`. Modules `v.db.` should come with
`map` option, or I am wrong?
I agree. v.db.univar should have options 'map' and 'layer', not
'table', 'driver', and 'database'. Otherwise it would need to be
called db.univar, not v.db.univar.
Markus M
Markus Metz wrote:
I agree. v.db.univar should have options 'map' and 'layer', not
'table', 'driver', and 'database'. Otherwise it would need to be
called db.univar, not v.db.univar.
since there is already a v.univar module like that, renaming to db.univar
seems like the path to take.
Hamish
ps- any objections to renaming g.transform to m.* in trunk? (2nd call)
2011/9/28 Hamish <hamish_b@yahoo.com>:
ps- any objections to renaming g.transform to m.* in trunk? (2nd call)
no. Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
2011/9/28 Hamish <hamish_b@yahoo.com>:
Markus Metz wrote:
I agree. v.db.univar should have options 'map' and 'layer', not
'table', 'driver', and 'database'. Otherwise it would need to be
called db.univar, not v.db.univar.since there is already a v.univar module like that, renaming to db.univar
seems like the path to take.
seems to be. Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Wed, Sep 28, 2011 at 11:13 AM, Martin Landa <landa.martin@gmail.com> wrote:
2011/9/28 Hamish <hamish_b@yahoo.com>:
Markus Metz wrote:
I agree. v.db.univar should have options 'map' and 'layer', not
'table', 'driver', and 'database'. Otherwise it would need to be
called db.univar, not v.db.univar.since there is already a v.univar module like that, renaming to db.univar
seems like the path to take.seems to be. Martin
+1, makes sense to me
I was considering if the interface should be changed, but db.univar
with table, driver, database options is more versatile than a
v.db.univar with map, layer options would be.
Markus M