[GRASSLIST:8678] [GRASS5] Re: GIS Manager updates

GRASS GRASS user
,
1

Michael,

This is tremendous. The new GIS looks and, as far as I can tell works, great (as of CVS this afternoon).

On a separate topic, I would to hear your (or anyone else's who would like to chime in) opinion concerning attribute management. Several folks in my department have vector layers on which they need to add anywhere from 5 to 50 attributes per polygon (5 to 50 new columns). They all have postgres and mysql installed (in addition to the standard defaulf dbf option). What approach do people take when building attribute intensive vector layers? Do you use a separate database (ie postgis)? or do you manage them in grass?

The motivation for this query is this: One of my colleagues stopped me in hall yesterday and reported the he couldn't figure out how to delete an attribute column once he had created it. I started looking into the issue last night and so far have not come up with an answer for him. And as long as I was on the topic I though I'd open it up to a larger question of attribute management.

Looking forward to reading everyone's suggestions,

Kirk

Kirk R. Wythers, Research Fellow
Dept. of Forest Resources
University of Minnesota
1530 Cleveland Ave N
Saint Paul, MN 55108
tel: 612.625.2261
email: kwythers@umn.edu

2

Kirk,

Glad you like the improvements. I'm trying to target people who know GIS,
but not GRASS, along with keeping it functional for old hands at the
program.

Attribute management is pretty weak in GRASS, though the new scripts for
column addition and value replacement are a bit help. More things can be
accomplished via SQL commands within GRASS.

This has been discussed and needs someone to write a data management module
in C or TclTk

Currently, the best bet is to use another program (database front end) to
manage the data tables for any heavy-duty activities.

Depending on what you want to do, this can be Open Office, MyPHP, several
freeware/shareware/commercial front ends, etc. If on Linux or a Mac and
installed correctly (a bit tricky), QGIS has a decent, if simple data table
manager (searching and changing values in a nice table interface, but not
column additions or deletions as far as I can tell).

SQLite support has been added to GRASS, but I'm not sure what that means
exactly (I've just emailed Radim this morning to try and get a
clarification). This may be a nice option.

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: "Kirk R. Wythers" <kwythers@umn.edu>
Date: Tue, 18 Oct 2005 12:54:32 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: List GRASS Users <GRASSLIST@baylor.edu>
Subject: [GRASS5] Re: [GRASSLIST:8664] GIS Manager updates

Michael,

This is tremendous. The new GIS looks and, as far as I can tell
works, great (as of CVS this afternoon).

On a separate topic, I would to hear your (or anyone else's who would
like to chime in) opinion concerning attribute management. Several
folks in my department have vector layers on which they need to add
anywhere from 5 to 50 attributes per polygon (5 to 50 new columns).
They all have postgres and mysql installed (in addition to the
standard defaulf dbf option). What approach do people take when
building attribute intensive vector layers? Do you use a separate
database (ie postgis)? or do you manage them in grass?

The motivation for this query is this: One of my colleagues stopped
me in hall yesterday and reported the he couldn't figure out how to
delete an attribute column once he had created it. I started looking
into the issue last night and so far have not come up with an answer
for him. And as long as I was on the topic I though I'd open it up to
a larger question of attribute management.

Looking forward to reading everyone's suggestions,

Kirk

Kirk R. Wythers, Research Fellow
Dept. of Forest Resources
University of Minnesota
1530 Cleveland Ave N
Saint Paul, MN 55108
tel: 612.625.2261
email: kwythers@umn.edu

3

I just tried the new GIS manager, and I think it is really good. The
only thing is that I foud some icons to be a little...big. Those on
the far right are at a good size, but I guess the others are big (like
zoom). Anyway, good job!

Carlos

On 10/18/05, Michael Barton <michael.barton@asu.edu> wrote:

Kirk,

Glad you like the improvements. I'm trying to target people who know GIS,
but not GRASS, along with keeping it functional for old hands at the
program.

Attribute management is pretty weak in GRASS, though the new scripts for
column addition and value replacement are a bit help. More things can be
accomplished via SQL commands within GRASS.

This has been discussed and needs someone to write a data management module
in C or TclTk

Currently, the best bet is to use another program (database front end) to
manage the data tables for any heavy-duty activities.

Depending on what you want to do, this can be Open Office, MyPHP, several
freeware/shareware/commercial front ends, etc. If on Linux or a Mac and
installed correctly (a bit tricky), QGIS has a decent, if simple data table
manager (searching and changing values in a nice table interface, but not
column additions or deletions as far as I can tell).

SQLite support has been added to GRASS, but I'm not sure what that means
exactly (I've just emailed Radim this morning to try and get a
clarification). This may be a nice option.

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: "Kirk R. Wythers" <kwythers@umn.edu>
> Date: Tue, 18 Oct 2005 12:54:32 -0500
> To: Michael Barton <michael.barton@asu.edu>
> Cc: List GRASS Users <GRASSLIST@baylor.edu>
> Subject: [GRASS5] Re: [GRASSLIST:8664] GIS Manager updates
>
> Michael,
>
> This is tremendous. The new GIS looks and, as far as I can tell
> works, great (as of CVS this afternoon).
>
> On a separate topic, I would to hear your (or anyone else's who would
> like to chime in) opinion concerning attribute management. Several
> folks in my department have vector layers on which they need to add
> anywhere from 5 to 50 attributes per polygon (5 to 50 new columns).
> They all have postgres and mysql installed (in addition to the
> standard defaulf dbf option). What approach do people take when
> building attribute intensive vector layers? Do you use a separate
> database (ie postgis)? or do you manage them in grass?
>
> The motivation for this query is this: One of my colleagues stopped
> me in hall yesterday and reported the he couldn't figure out how to
> delete an attribute column once he had created it. I started looking
> into the issue last night and so far have not come up with an answer
> for him. And as long as I was on the topic I though I'd open it up to
> a larger question of attribute management.
>
> Looking forward to reading everyone's suggestions,
>
> Kirk
>
> Kirk R. Wythers, Research Fellow
> Dept. of Forest Resources
> University of Minnesota
> 1530 Cleveland Ave N
> Saint Paul, MN 55108
> tel: 612.625.2261
> email: kwythers@umn.edu
>
>
>
>

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+

4

> On a separate topic, I would to hear your (or anyone else's who would
> like to chime in) opinion concerning attribute management. Several
> folks in my department have vector layers on which they need to add
> anywhere from 5 to 50 attributes per polygon (5 to 50 new columns).
> They all have postgres and mysql installed (in addition to the
> standard defaulf dbf option). What approach do people take when
> building attribute intensive vector layers? Do you use a separate
> database (ie postgis)? or do you manage them in grass?

dumb solution to remove a column, but it should work:

db.copy select=

only those columns you want to keep. (parse `db.describe -c` in a script)
Then remove old table, rename new table, and reconnect.
(v.db.droptable, v.db.connect; v.dbselect, ?)

This could be written as a script, eg v.db.delcol
(v.db.rmcol, v.db.removecol, v.db.dropcol,...)

but again, a fairly cruddy solution. Is there a SQL command that could
be passed to db.execute?

Hamish

5

On Oct 18, 2005, at 6:22 PM, Hamish wrote:

but again, a fairly cruddy solution. Is there a SQL command that could

be passed to db.execute?

postgres uses something like this:

ALTER TABLE products ADD COLUMN description text;

ALTER TABLE products DROP COLUMN description;

Hamish

6

Hamish wrote:

dumb solution to remove a column, but it should work:

db.copy select=

only those columns you want to keep. (parse `db.describe -c` in a script)
Then remove old table, rename new table, and reconnect.
(v.db.droptable, v.db.connect; v.dbselect, ?)

This could be written as a script, eg v.db.delcol
(v.db.rmcol, v.db.removecol, v.db.dropcol,...)

but again, a fairly cruddy solution. Is there a SQL command that could
be passed to db.execute?

Hamish

Kirk R. Wythers wrote:

On Oct 18, 2005, at 6:22 PM, Hamish wrote:

postgres uses something like this:

ALTER TABLE products ADD COLUMN description text;

ALTER TABLE products DROP COLUMN description;

Maybe such a (needed) script has to distinguish between DBF driver and the
other real SQL drivers?

If connection == dbf then do_the_nasty_way
else
use the ALTER command

? To implement DROP column into the DBF driver might be hard.

Markus