[GRASS5] a set of wishes for GRASS 5.7

GRASS GRASS developer
1

I am starting a project soon in which I hope to use GRASS 5.7. Given that an increasing amount of development is shifting to 5.7, I have a set of wishes I want to get out to the list. Perhaps with summer coming around, some can happen.

1. This is the biggest. I wish there was some way in GRASS itself to manage attribute data--especially for vectors. (I'm referring to the new GRASS native dbf format, not the external databases to which GRASS can connect.) v.reclass no-longer has any interactive component. The only way to edit values is to 1) use d.what.vect (which is still buggy and doesn't work after the first time in a GRASS session) on one feature at a time, or 2) use v.digit, again one feature at a time. There is no easy way to even see what values are in the linked attribute table for a vector map now that v.report is gone. I'd like to see v.report come back with options to select fields to report on. However, even more, I'd like to have some kind of simple table display and edit functions in GRASS. The ArcView model of a spreadsheet-like table view, with basic editing and query functions, seems desirable. The lack of any way to manage GRASS attribute data is made worse by the fact that GRASS now has the potential for much richer attribute data and much better query tools, coupled by the strange lack of open-source dbf management tools (like phpMyAdmin for MySQL). Perhaps someone can create a db.manage module.

Along these lines, it would also be nice to get back the interactive versions of r.reclass and r.recode that permit simple editing of category values. It would also be very nice to get back a way to enter or modify raster label strings. These were done under r.support, which is missing from 5.7. There is currently no way to modify raster labels in GRASS 5.7.

In sum, GRASS 5.7 has some new and very powerful ways to query attribute data, but has very minimal means to manage those data--even less so than in 5.0 and 5.3.

2. A flag that sets a default database connection (using the standard GRASS dbf files) for commands that have a database connection option. I'm still having trouble specifying the correct syntax to connect to the database in the new Spearfish data set for 5.7. The flag would make the connection to the database located in $GISBASE/$LOCATION_NAME/$MAPSET/dbf/. Obviously there is more to it than simply specifying this path. I've done that and still am getting a DBMI protocol error. For the GRASS native format, this should be largely seamless.

3. Select buttons for colors, icons, column name, and field value in d.vect. These seem doable as they exist (at least the colors and icons) in the version of d.vect in d.m.

4. A 'clear' button for all the tcltk autogenerated dialogs. I guess this would require a change to g.parser. However, it is a minor but cumulative pain to select long output in the lower window and scroll to delete it--so that I can see what I am doing wrong with the most current version of the command I issue.

5. A return of an interactive r.mapcalc. This is a complex tcltk script. Maybe I can even do this as I work on scripts this summer. However, if someone has a better idea, that would be great.

I sent in several bug reports for GRASS 5.7 to the bug tracker. I can reiterate them to the list if people think it would be good to do so. I just don't want to double people's mail.

Michael Barton
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

2

On Monday 10 May 2004 07:52, you wrote:

1. This is the biggest. I wish there was some way in GRASS itself to
manage attribute data--especially for vectors. (I'm referring to the
new GRASS native dbf format, not the external databases to which GRASS
can connect.) v.reclass no-longer has any interactive component. The
only way to edit values is to 1) use d.what.vect (which is still buggy
and doesn't work after the first time in a GRASS session) on one
feature at a time, or 2) use v.digit, again one feature at a time.
There is no easy way to even see what values are in the linked
attribute table for a vector map now that v.report is gone. I'd like to
see v.report come back with options to select fields to report on.
However, even more, I'd like to have some kind of simple table display
and edit functions in GRASS. The ArcView model of a spreadsheet-like
table view, with basic editing and query functions, seems desirable.
The lack of any way to manage GRASS attribute data is made worse by the
fact that GRASS now has the potential for much richer attribute data
and much better query tools, coupled by the strange lack of open-source
dbf management tools (like phpMyAdmin for MySQL). Perhaps someone can
create a db.manage module.

It was intention. We have enough problems to maintain GRASS as it is.
We should concentrate on 'geo' part and do not re-invent the wheel.
There are more DB clients available:
- OpenOffice: many databases
- pgaccess: Postgres
- MySQLGUI: MySQL
Is it a problem to use OpenOffice for DBF tables? I use OO.
There is also a simple table (like in ArcVIew) in QGIS
(selected features are highlighted in the map).

Everything (?) reported by v.report can be printed by v.to.db.
I don't believe that anybody can add the output form v.report
to a report nowadays. Output from v.to.db may be later formated
according to user needs, or DB connection from OO may be used
and output formated in OO.

2. A flag that sets a default database connection (using the standard
GRASS dbf files) for commands that have a database connection option.
I'm still having trouble specifying the correct syntax to connect to
the database in the new Spearfish data set for 5.7. The flag would make
the connection to the database located in
$GISBASE/$LOCATION_NAME/$MAPSET/dbf/. Obviously there is more to it
than simply specifying this path. I've done that and still am getting a
DBMI protocol error. For the GRASS native format, this should be
largely seamless.

$GISBASE/$LOCATION_NAME/$MAPSET/dbf/ is correct. Does the directory exist?
Does it fail always, also db.tables -p?

d.what.vect (which is still buggy
and doesn't work after the first time in a GRASS session) on one
feature at a time, or 2) use v.digit, again one feature at a time.

3. Select buttons for colors, icons, column name, and field value in d.vect.

4. A 'clear' button for all the tcltk autogenerated dialogs.

I would like to remove all TclTk related code (except NVIZ),
once QGIS, GTKGRASS or whatever are ready. At least lib/form,
db/drivers/dialog, Tk part from g.parser, lib/gtcltk, v.digit and d.m
(and revert R_get_location_with_*).

Radim

3

On Sun, May 09, 2004 at 10:52:55PM -0700, Michael Barton wrote:
[...]

I'd like to see v.report come back with options to select fields to
report on.

I have extended today the documentation of v.to.db to explain
v.report-like functionality.

[...]

Along these lines, it would also be nice to get back the interactive
versions of r.reclass and r.recode that permit simple editing of
category values. It would also be very nice to get back a way to enter
or modify raster label strings. These were done under r.support, which
is missing from 5.7. There is currently no way to modify raster labels
in GRASS 5.7.

To make the tcl/tk GUI bidirectional needs some (little?) work.
Since it was done for 5.3 as far as I remember, someone with TclTk
skills might be able to modify grass51/lib/gis/parser.c
Unfortunately I am not skilled.

In sum, GRASS 5.7 has some new and very powerful ways to query
attribute data, but has very minimal means to manage those data--even
less so than in 5.0 and 5.3.

Really? The SQL support (see db.execute, db.select) is not that bad.
Please keep in mind that there are less than two full-time developers
only for 5.7. Given that the new functionality is impressive!

2. A flag that sets a default database connection (using the standard
GRASS dbf files) for commands that have a database connection option.
I'm still having trouble specifying the correct syntax to connect to
the database in the new Spearfish data set for 5.7. The flag would make
the connection to the database located in
$GISBASE/$LOCATION_NAME/$MAPSET/dbf/. Obviously there is more to it
than simply specifying this path.

This is perfect. But don't forget to quote it. See

g.manual v.database
g.manual db.connect
g.manual v.db.connect

http://grass.itc.it/grass51/tutorial/attrib_storage.html#default

I have extended the man page of v.database with DBF example.

I've done that and still am getting a
DBMI protocol error. For the GRASS native format, this should be
largely seamless.

Right. You should not need it at all. Please post the complete
error message (please use latest 5.7).

3. Select buttons for colors, icons, column name, and field value in
d.vect. These seem doable as they exist (at least the colors and icons)
in the version of d.vect in d.m.

Volunteer needed...

4. A 'clear' button for all the tcltk autogenerated dialogs. I guess
this would require a change to g.parser. However, it is a minor but
cumulative pain to select long output in the lower window and scroll to
delete it--so that I can see what I am doing wrong with the most
current version of the command I issue.

Yes, done now in CVS.

5. A return of an interactive r.mapcalc. This is a complex tcltk
script. Maybe I can even do this as I work on scripts this summer.
However, if someone has a better idea, that would be great.

Years ago I have written a sort of r.mapcalc/tcl which
looks like a real calculator:

It's still there:
#change into 5.3 source code:
cd grass53src
#launch it:
wish src/tcltkgrass/todo/r_mapcalc.tcl

It was never finished due to my very limited tcl/tk skills.

I sent in several bug reports for GRASS 5.7 to the bug tracker. I can
reiterate them to the list if people think it would be good to do so. I
just don't want to double people's mail.

Generally it's important to maintain the bug reports separated.
And to find volunteers.

Markus

4

You guys have done a FANTASTIC job, and I am not complaining about this at all. You can only do so much. However, it is still difficult to manage attribute data from within GRASS. It seems that the main focus so far has been getting data out in diverse ways and using gdal and ogr to get data from elsewhere in. Personnally, I agree that these have priority. But, what I do requires a fair amount of data creation--which is why I've followed the improvements to v.digit with much interest. This is also the source of my wish for better attribute data entry/editing tools. AFAICT, db.select is a query tool. db.execute can of course issue sql update queries. However, this is different from a basic data editor. Answering Radim's response at the same time, OpenOffice for Mac is still at the 1.0 stage and does not include dbf support. Even if it did, this is a lot of program to install, just to edit dbf files. I have Excel and can use that, of course. It would still be nice to work within GRASS as was possible previously (albeit in a somewhat clunky way). My hope was to inspire another programmer to take up this task. A search on Sourceforge suggests that the tools are there to do some kind of simple editor.

I haven't tried to compile QGIS to see if it runs on my Mac yet, so it is nice to know that it has an editor. As Radim describes it, this should do the trick. More complex things could be done with db.execute.

Michael
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On May 10, 2004, at 6:58 AM, Markus Neteler wrote:

Really? The SQL support (see db.execute, db.select) is not that bad.
Please keep in mind that there are less than two full-time developers
only for 5.7. Given that the new functionality is impressive!

5

On Mon, May 10, 2004 at 08:38:05AM -0700, Michael Barton wrote:

You guys have done a FANTASTIC job, and I am not complaining about this
at all. You can only do so much. However, it is still difficult to
manage attribute data from within GRASS. It seems that the main focus
so far has been getting data out in diverse ways and using gdal and ogr
to get data from elsewhere in. Personnally, I agree that these have
priority. But, what I do requires a fair amount of data creation--which
is why I've followed the improvements to v.digit with much interest.
This is also the source of my wish for better attribute data
entry/editing tools. AFAICT, db.select is a query tool. db.execute can
of course issue sql update queries. However, this is different from a
basic data editor. Answering Radim's response at the same time,
OpenOffice for Mac is still at the 1.0 stage and does not include dbf
support. Even if it did, this is a lot of program to install, just to
edit dbf files. I have Excel and can use that, of course. It would
still be nice to work within GRASS as was possible previously (albeit
in a somewhat clunky way). My hope was to inspire another programmer to
take up this task. A search on Sourceforge suggests that the tools are
there to do some kind of simple editor.

Michael,

ideas are not the problem. We are in the need to have someone looking
into this (a *new, additional* GRASS 5.7 programmer). But I think
that I have posted this message already too often.
The question is: how to raise interest in GRASS 5.7 programming?

I can understand your problems, but this must be solved by someone else.

I haven't tried to compile QGIS to see if it runs on my Mac yet, so it
is nice to know that it has an editor. As Radim describes it, this
should do the trick. More complex things could be done with db.execute.

Michael

Best,

Markus

6

On Monday 10 May 2004 17:38, Michael Barton wrote:

basic data editor. Answering Radim's response at the same time,
OpenOffice for Mac is still at the 1.0 stage and does not include dbf
support. Even if it did, this is a lot of program to install, just to
edit dbf files. I have Excel and can use that, of course.

Do you have MS Access? It is better than OO.
Are you sure that OO 1.0 for Mac does not include dbf databases?
(Tools -> Data Sources -> Database Type: dBase)

I haven't tried to compile QGIS to see if it runs on my Mac yet, so it
is nice to know that it has an editor. As Radim describes it, this
should do the trick.

Sorry for confusion, it is read only.

Radim

7

Database user tools are only in OO 1.1.1. Currently, OO for Mac is at 1.0.3. It may be upgraded to 1.1.1 soon. MS Access is only available for Windows.

I can read dbf files into Excel or even Filemaker. Or I could fire up FoxPro in OS 9 (though Visual FoxPro for Mac is notoriously unstable). However, it would be nice to have an editor available in GRASS simultaneously while working with the vector features. Perhaps this is simply not feasible even if someone was available to program one. And certainly, by switching to a *.dbf format, it is now possible to use other tools to get at attribute tables. Still one can wish...

Michael
______________________________
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On May 10, 2004, at 9:09 AM, Radim Blazek wrote:

Do you have MS Access? It is better than OO.
Are you sure that OO 1.0 for Mac does not include dbf databases?
(Tools -> Data Sources -> Database Type: dBase)

8

[snip]

ideas are not the problem. We are in the need to have someone looking
into this (a *new, additional* GRASS 5.7 programmer). But I think
that I have posted this message already too often.
The question is: how to raise interest in GRASS 5.7 programming?

-- kind of off-topic --

I think there does interest in GRASS programming exist but to get off the
ground/ to get involved is the problem.
Moreover I assume that a considerable amount of ANSI-C programming knowledge
is necessary before any programming can be done. Hence this is the major
barrier for "usual" GRASS user.
Personally I would be interested in learning how to contribute to new GRASS
capabilities (especially implementing spatial models like GRASP-R or an
neural network equivalent) but I have no advanced programming skills at all.

For instance a section in the GRASS Newsletter covering the topic "how to
become involved" might result in an increased interest and can be distributed
in appropriate locations e.g. applied computer science departments where C
programming skills are likely to be found :wink:

I would appreciate if somebody starts a column for people who like to
contribute to GRASS programming but have little background (but I don't know
if this is possible without starting from scratch -> teaching basic
programming)

regards Martin