[GRASS5] viewing map attribute table

GRASS GIS GRASS GIS developer
1

Hello,

Another missing feature in GRASS is the capacity to easily view the map
attribute table. The current option is 'db.select TableName', but the output
is not very beautiful and is difficult to browse.

I think this feature would be useful in connection with the other attribute
management modules I just sent.

Does anyone have an idea how to create a nicer and browsable display of an
attribute table in the tcltk interface ? I guess the easiest would be to pipe
the db.select results into awk for formatting and then open a new tcltk window
which displays the results.

Moritz

2

On Wed, May 25, 2005 at 10:38:29AM +0200, Moritz Lennert wrote:

Hello,

Another missing feature in GRASS is the capacity to easily view the map
attribute table. The current option is 'db.select TableName', but the output
is not very beautiful and is difficult to browse.

I think this feature would be useful in connection with the other attribute
management modules I just sent.

Does anyone have an idea how to create a nicer and browsable display of an
attribute table in the tcltk interface ? I guess the easiest would be to pipe
the db.select results into awk for formatting and then open a new tcltk window
which displays the results.

Maybe pipe the output of
v.db.select map
into a tcl table viewer? I have just added a WHERE statement to v.db.select.

Markus

3

On Wed, May 25, 2005 14:32, Markus Neteler said:

On Wed, May 25, 2005 at 10:38:29AM +0200, Moritz Lennert wrote:

Hello,

Another missing feature in GRASS is the capacity to easily view the map
attribute table. The current option is 'db.select TableName', but the output
is not very beautiful and is difficult to browse.

I think this feature would be useful in connection with the other attribute
management modules I just sent.

Does anyone have an idea how to create a nicer and browsable display of an
attribute table in the tcltk interface ? I guess the easiest would be to
pipe
the db.select results into awk for formatting and then open a new tcltk
window
which displays the results.

Maybe pipe the output of
v.db.select map
into a tcl table viewer?

Yes, this is what I think as well. Daniel suggested TkTable, but I'm looking
at the possibilities of doing this with just the basic tcltk to avoid creating
another dependency.

I have just added a WHERE statement to v.db.select.

Except for the the fact that in one you chose a map and in the other a table,
what is the difference between v.db.select and db.select ? (or is v.db.select
just a sort of frontend to db.select ?)

Moritz

4

Moritz Lennert wrote:

Hello,

Another missing feature in GRASS is the capacity to easily view the map
attribute table. The current option is 'db.select TableName', but the output
is not very beautiful and is difficult to browse.

I think this feature would be useful in connection with the other attribute
management modules I just sent.

Does anyone have an idea how to create a nicer and browsable display of an
attribute table in the tcltk interface ? I guess the easiest would be to pipe
the db.select results into awk for formatting and then open a new tcltk window
which displays the results.

Moritz

The form library is based on simple Web browser written in TclTk, I don't recall however if it supports HTML tables or not.

Radim

5

On Wed, May 25, 2005 at 03:00:49PM +0200, Moritz Lennert wrote:
...

Except for the the fact that in one you chose a map and in the other a table,
what is the difference between v.db.select and db.select ? (or is v.db.select
just a sort of frontend to db.select ?)

db.select can access tables which are not vector maps (right?).
v.db.select is using the dblink definition of the map (right?).

Markus

6

On Wed, May 25, 2005 15:10, Radim Blazek said:

Moritz Lennert wrote:

Hello,

Another missing feature in GRASS is the capacity to easily view the map
attribute table. The current option is 'db.select TableName', but the output
is not very beautiful and is difficult to browse.

I think this feature would be useful in connection with the other attribute
management modules I just sent.

Does anyone have an idea how to create a nicer and browsable display of an
attribute table in the tcltk interface ? I guess the easiest would be to
pipe
the db.select results into awk for formatting and then open a new tcltk
window
which displays the results.

Moritz

The form library is based on simple Web browser written in TclTk, I
don't recall however if it supports HTML tables or not.

There seem to be some problems with the form library at least under Debian, so
I am a bit hesitant of going that way.

Moritz

7

On Wed, May 25, 2005 15:00, Moritz Lennert said:

On Wed, May 25, 2005 14:32, Markus Neteler said:

On Wed, May 25, 2005 at 10:38:29AM +0200, Moritz Lennert wrote:

Hello,
Another missing feature in GRASS is the capacity to easily view the map

attribute table. The current option is 'db.select TableName', but the
output

is not very beautiful and is difficult to browse.
I think this feature would be useful in connection with the other

attribute

management modules I just sent.
Does anyone have an idea how to create a nicer and browsable display of an

attribute table in the tcltk interface ? I guess the easiest would be to
pipe

the db.select results into awk for formatting and then open a new tcltk

window

which displays the results.

Maybe pipe the output of
v.db.select map
into a tcl table viewer?

Yes, this is what I think as well. Daniel suggested TkTable, but I'm looking

at the possibilities of doing this with just the basic tcltk to avoid
creating

another dependency.

Using the code at the bottom of http://wiki.tcl.tk/3150 which uses the 'grid'
widget, I can currently display data relatively nicely, but the frame has the
size of the table, without any scrollbars and so when you get more than just a
few rows it goes way beyond the screen. In addition it takes quite a while to
load the data, so I guess it must be quite inefficient.

But I still have to refamiliarise myself with tcltk in order to create
anything useful. It's been a long time...

Any pointers concerning above problems are more than welcome.

Moritz

I have just added a WHERE statement to v.db.select.

Except for the the fact that in one you chose a map and in the other a

table,

what is the difference between v.db.select and db.select ? (or is

v.db.select

just a sort of frontend to db.select ?)

Moritz

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

8

This would be very nice. Perhaps we should also have a db.dropcolumn. Then
with the browse, it is possible to do all standard table management except
adding or deleting a record. The latter is more problematic as one would
hope to make sure it is linked to a vector object.

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: Moritz Lennert <mlennert@club.worldonline.be>
Reply-To: <mlennert@club.worldonline.be>
Date: Wed, 25 May 2005 10:38:29 +0200 (CEST)
To: Grass Developers List <grass5@grass.itc.it>
Subject: [GRASS5] viewing map attribute table

Hello,

Another missing feature in GRASS is the capacity to easily view the map
attribute table. The current option is 'db.select TableName', but the output
is not very beautiful and is difficult to browse.

I think this feature would be useful in connection with the other attribute
management modules I just sent.

Does anyone have an idea how to create a nicer and browsable display of an
attribute table in the tcltk interface ? I guess the easiest would be to pipe
the db.select results into awk for formatting and then open a new tcltk window
which displays the results.

Moritz

9

On Wed, May 25, 2005 18:14, Michael Barton said:

This would be very nice. Perhaps we should also have a db.dropcolumn.

I don't think that ALTER TABLE DROP COLUMN is implemented in the GRASS SQL.
Radim ?

If it isn't then I don't know how to drop a column.

Then
with the browse, it is possible to do all standard table management

Well, for me v.db.updatecol is still incomplete as it only allows to update a
column with an absolute value and not an expression. This is desperately
needed if you want to create intensity data (e.g. you have population and
surface columns and want to create a density column).

If it is too complicated to implement this in the sql update command, maybe it
would be possible to integrate it into d.vect.thematic by giving the
possibility to chose a second column and the nature of its relation to the
first ?

except
adding or deleting a record. The latter is more problematic as one would
hope to make sure it is linked to a vector object.

I think all these kinds of operations (including the expression update) would
be easier if we use sqlite3 as Markus suggests.

Moritz

10

On Wed, May 25, 2005 23:54, Moritz Lennert said:

On Wed, May 25, 2005 18:14, Michael Barton said:

Then
with the browse, it is possible to do all standard table management

Well, for me v.db.updatecol is still incomplete as it only allows to update a
column with an absolute value and not an expression. This is desperately
needed if you want to create intensity data (e.g. you have population and
surface columns and want to create a density column).

Thinking about this a little more: it should be possible to select the
contents of two columns into two arrays, do the calculation in the shell
script and then update a third column with the resulting values. However, I am
not sure if all shells support arrays ?

In any case a more complete sql update command would be more efficient, I think.

Moritz

11

Thinking about this a little more: it should be possible to select the
contents of two columns into two arrays, do the calculation in the
shell script and then update a third column with the resulting values.
However, I am not sure if all shells support arrays ?

I think you will need to save to temp files. (use g.tempfile)

hints--

integer math in a shell:

expr 1 + 2

integer math in a bash shell:

echo $(( 1 + 2 ))

floating point math using "bc":

echo "scale=6; 1 / 2" | bc

But "bc" in not guaranteed to be installed on all systems.

floating point math using "awk":

echo "1 2" | awk '{print $1 / $2}'

then add column and populate with
echo "INSERT INTO $NAME VALUES ()" | db.execute

Hamish

12

Moritz Lennert wrote:

On Wed, May 25, 2005 18:14, Michael Barton said:

This would be very nice. Perhaps we should also have a db.dropcolumn.

I don't think that ALTER TABLE DROP COLUMN is implemented in the GRASS SQL.
Radim ?

No, it is not implemented.

BTW, v.db.updatecol could be probably called simply v.db.update, there are no other properties which could be updated AFAIK.

Radim