[GRASS5] db.columns and v.info -c

GRASS GIS GRASS GIS developer
1

Hi

I'm wondering if functionality of db.columns and v.info -c shouldn't be
merged into one command. Maybe extend db.columns to report types (other
info? say: number of records per column, check if null records
present/absent, number of null records?) and remove "-c" from v.info?

Maciek

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

2

On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:

Hi

I'm wondering if functionality of db.columns and v.info -c shouldn't be
merged into one command. Maybe extend db.columns to report types (other
info? say: number of records per column, check if null records
present/absent, number of null records?) and remove "-c" from v.info?

Maciek

How do you want to merge v. and db. commands?
One works on vector and the other on table.

Radim

3

On wto, 2005-11-22 at 10:31 +0100, Radim Blazek wrote:

On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> Hi
>
> I'm wondering if functionality of db.columns and v.info -c shouldn't be
> merged into one command. Maybe extend db.columns to report types (other
> info? say: number of records per column, check if null records
> present/absent, number of null records?) and remove "-c" from v.info?
>
> Maciek

How do you want to merge v. and db. commands?

Isn't v.info -c an example?

One works on vector and the other on table.

v.info -c works on a table

Maciek

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

4

On Tue, Nov 22, 2005 at 02:53:43PM +0100, Maciek Sieczka wrote:

On wto, 2005-11-22 at 10:31 +0100, Radim Blazek wrote:
> On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> > Hi
> >
> > I'm wondering if functionality of db.columns and v.info -c shouldn't be
> > merged into one command. Maybe extend db.columns to report types (other
> > info? say: number of records per column, check if null records
> > present/absent, number of null records?) and remove "-c" from v.info?
> >
> > Maciek
>
> How do you want to merge v. and db. commands?

Isn't v.info -c an example?

No: it shows the columns of a table *connected* to a
vector map.
But you can have many tables not connected to vector maps
in your database. The v.* commands do not see them, but
the db.* commands do see them.

> One works on vector and the other on table.
v.info -c works on a table

Yes, but only on a table connected to a certain
vector map.

Markus

5

On wto, 2005-11-22 at 15:23 +0100, Markus Neteler wrote:

On Tue, Nov 22, 2005 at 02:53:43PM +0100, Maciek Sieczka wrote:
> On wto, 2005-11-22 at 10:31 +0100, Radim Blazek wrote:
> > On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> > > Hi
> > >
> > > I'm wondering if functionality of db.columns and v.info -c shouldn't be
> > > merged into one command. Maybe extend db.columns to report types (other
> > > info? say: number of records per column, check if null records
> > > present/absent, number of null records?) and remove "-c" from v.info?
> > >
> > > Maciek
> >
> > How do you want to merge v. and db. commands?
>
> Isn't v.info -c an example?

No: it shows the columns of a table *connected* to a
vector map.

I know.

But you can have many tables not connected to vector maps
in your database. The v.* commands do not see them, but
the db.* commands do see them.

> > One works on vector and the other on table.
> v.info -c works on a table

Yes, but only on a table connected to a certain
vector map.

I'm affraid I wasn't explicit enough in my fisrt post. Other words then.

Is it necessary to maintain "v.info -c" when db.columns, in conjnction
with "v.db.connect -p", provides the same functionality?

In order to know what table my_vector is connected to I do "v.db.connect
-p my_vector", then db.columns on the resulting table name to learn
about it's columns (using v.db.connect for learning the name of
connected table is pretty intuitive, as it is used also for connecting
and distonecing tables, should be no problems here for newbies).

Currently both "v.info -c" and db.columns print the column name -
doubled functionality. Only v.info -c prints the column type tough.
Instead of maintaing both commands, wouldn't it be better to implement
printing the column type in db.columns (or make it print even more
information besides coulmn name and type) and get rid of "-c" in v.info?

I'm rising this because:
1. I believe that a user will first seek for a command which can
describe a table I) among the db.* commands II) v.db.* III) v.* (v.info
would be the last reasonable place to look for it if I were a newbie,
let's make it easier).

2. I remember one of the goals in Grass>=5.7 was to get rid of doubled
functionality.

Maciek

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

6

v.info -c must remain in 6.x.

You are right that v.db.columns would be better.

Radim

On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:

On wto, 2005-11-22 at 15:23 +0100, Markus Neteler wrote:
> On Tue, Nov 22, 2005 at 02:53:43PM +0100, Maciek Sieczka wrote:
> > On wto, 2005-11-22 at 10:31 +0100, Radim Blazek wrote:
> > > On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> > > > Hi
> > > >
> > > > I'm wondering if functionality of db.columns and v.info -c shouldn't be
> > > > merged into one command. Maybe extend db.columns to report types (other
> > > > info? say: number of records per column, check if null records
> > > > present/absent, number of null records?) and remove "-c" from v.info?
> > > >
> > > > Maciek
> > >
> > > How do you want to merge v. and db. commands?
> >
> > Isn't v.info -c an example?
>
> No: it shows the columns of a table *connected* to a
> vector map.

I know.

> But you can have many tables not connected to vector maps
> in your database. The v.* commands do not see them, but
> the db.* commands do see them.
>
> > > One works on vector and the other on table.
> > v.info -c works on a table
>
> Yes, but only on a table connected to a certain
> vector map.

I'm affraid I wasn't explicit enough in my fisrt post. Other words then.

Is it necessary to maintain "v.info -c" when db.columns, in conjnction
with "v.db.connect -p", provides the same functionality?

In order to know what table my_vector is connected to I do "v.db.connect
-p my_vector", then db.columns on the resulting table name to learn
about it's columns (using v.db.connect for learning the name of
connected table is pretty intuitive, as it is used also for connecting
and distonecing tables, should be no problems here for newbies).

Currently both "v.info -c" and db.columns print the column name -
doubled functionality. Only v.info -c prints the column type tough.
Instead of maintaing both commands, wouldn't it be better to implement
printing the column type in db.columns (or make it print even more
information besides coulmn name and type) and get rid of "-c" in v.info?

I'm rising this because:
1. I believe that a user will first seek for a command which can
describe a table I) among the db.* commands II) v.db.* III) v.* (v.info
would be the last reasonable place to look for it if I were a newbie,
let's make it easier).

2. I remember one of the goals in Grass>=5.7 was to get rid of doubled
functionality.

Maciek

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

7

On wto, 2005-11-22 at 19:18 +0100, Radim Blazek wrote:

v.info -c must remain in 6.x.

I see. Thanks for your prompt reply.

Maciek

You are right that v.db.columns would be better.

Radim

On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> On wto, 2005-11-22 at 15:23 +0100, Markus Neteler wrote:
> > On Tue, Nov 22, 2005 at 02:53:43PM +0100, Maciek Sieczka wrote:
> > > On wto, 2005-11-22 at 10:31 +0100, Radim Blazek wrote:
> > > > On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:
> > > > > Hi
> > > > >
> > > > > I'm wondering if functionality of db.columns and v.info -c shouldn't be
> > > > > merged into one command. Maybe extend db.columns to report types (other
> > > > > info? say: number of records per column, check if null records
> > > > > present/absent, number of null records?) and remove "-c" from v.info?
> > > > >
> > > > > Maciek
> > > >
> > > > How do you want to merge v. and db. commands?
> > >
> > > Isn't v.info -c an example?
> >
> > No: it shows the columns of a table *connected* to a
> > vector map.
>
> I know.
>
> > But you can have many tables not connected to vector maps
> > in your database. The v.* commands do not see them, but
> > the db.* commands do see them.
> >
> > > > One works on vector and the other on table.
> > > v.info -c works on a table
> >
> > Yes, but only on a table connected to a certain
> > vector map.
>
>
>
> I'm affraid I wasn't explicit enough in my fisrt post. Other words then.
>
> Is it necessary to maintain "v.info -c" when db.columns, in conjnction
> with "v.db.connect -p", provides the same functionality?
>
> In order to know what table my_vector is connected to I do "v.db.connect
> -p my_vector", then db.columns on the resulting table name to learn
> about it's columns (using v.db.connect for learning the name of
> connected table is pretty intuitive, as it is used also for connecting
> and distonecing tables, should be no problems here for newbies).
>
> Currently both "v.info -c" and db.columns print the column name -
> doubled functionality. Only v.info -c prints the column type tough.
> Instead of maintaing both commands, wouldn't it be better to implement
> printing the column type in db.columns (or make it print even more
> information besides coulmn name and type) and get rid of "-c" in v.info?
>
> I'm rising this because:
> 1. I believe that a user will first seek for a command which can
> describe a table I) among the db.* commands II) v.db.* III) v.* (v.info
> would be the last reasonable place to look for it if I were a newbie,
> let's make it easier).
>
> 2. I remember one of the goals in Grass>=5.7 was to get rid of doubled
> functionality.
>
> Maciek
>
>
> --------------------
> W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
> http://katalog.epf.pl/
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

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

8

On Tue, November 22, 2005 18:51, Maciek Sieczka wrote:

Currently both "v.info -c" and db.columns print the column name -
doubled functionality. Only v.info -c prints the column type tough.
Instead of maintaing both commands, wouldn't it be better to implement
printing the column type in db.columns (or make it print even more
information besides coulmn name and type) and get rid of "-c" in v.info?

db.describe gives details about columns.

Moritz

9

Although your point about duplicate functionality is correct, v.info -c is a
nice shorthand way to get the columns in the selected layer connected to a
vector. It is the way to easily get the show column button in the GIS
Manager.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Radim Blazek <radim.blazek@gmail.com>
Date: Tue, 22 Nov 2005 19:18:46 +0100
To: Maciek Sieczka <werchowyna@epf.pl>
Cc: Markus Neteler <neteler@itc.it>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] db.columns and v.info -c

v.info -c must remain in 6.x.

You are right that v.db.columns would be better.

Radim

On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:

On wto, 2005-11-22 at 15:23 +0100, Markus Neteler wrote:

On Tue, Nov 22, 2005 at 02:53:43PM +0100, Maciek Sieczka wrote:

On wto, 2005-11-22 at 10:31 +0100, Radim Blazek wrote:

On 11/22/05, Maciek Sieczka <werchowyna@epf.pl> wrote:

Hi

I'm wondering if functionality of db.columns and v.info -c shouldn't be
merged into one command. Maybe extend db.columns to report types (other
info? say: number of records per column, check if null records
present/absent, number of null records?) and remove "-c" from v.info?

Maciek

How do you want to merge v. and db. commands?

Isn't v.info -c an example?

No: it shows the columns of a table *connected* to a
vector map.

I know.

But you can have many tables not connected to vector maps
in your database. The v.* commands do not see them, but
the db.* commands do see them.

One works on vector and the other on table.

v.info -c works on a table

Yes, but only on a table connected to a certain
vector map.

I'm affraid I wasn't explicit enough in my fisrt post. Other words then.

Is it necessary to maintain "v.info -c" when db.columns, in conjnction
with "v.db.connect -p", provides the same functionality?

In order to know what table my_vector is connected to I do "v.db.connect
-p my_vector", then db.columns on the resulting table name to learn
about it's columns (using v.db.connect for learning the name of
connected table is pretty intuitive, as it is used also for connecting
and distonecing tables, should be no problems here for newbies).

Currently both "v.info -c" and db.columns print the column name -
doubled functionality. Only v.info -c prints the column type tough.
Instead of maintaing both commands, wouldn't it be better to implement
printing the column type in db.columns (or make it print even more
information besides coulmn name and type) and get rid of "-c" in v.info?

I'm rising this because:
1. I believe that a user will first seek for a command which can
describe a table I) among the db.* commands II) v.db.* III) v.* (v.info
would be the last reasonable place to look for it if I were a newbie,
let's make it easier).

2. I remember one of the goals in Grass>=5.7 was to get rid of doubled
functionality.

Maciek

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

10

On wto, 2005-11-22 at 15:39 -0700, Michael Barton wrote:

Although your point about duplicate functionality is correct, v.info -c is a
nice shorthand way to get the columns in the selected layer connected to a
vector. It is the way to easily get the show column button in the GIS
Manager.

True, at least for current Grass GUI. Do you mind adding your note to
http://intevation.de/rt/webrt?serial_num=3857?

Thanks,
Maciek

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