[GRASS5] Re: GRASS 5.7 updated scripts

GRASS GRASS developer
, ,
1

Markus,

These are in the tcltkgrass for 5.7 package that is on my website now. (http://www.public.asu.edu/~cmbarton/grass.htm). I can break them out if you'd like.

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:04 AM, grass5-request@grass.itc.it wrote:

Send grass5 mailing list submissions to
  grass5@grass.itc.it

To subscribe or unsubscribe via the World Wide Web, visit
  http://grass.itc.it/mailman/listinfo/grass5
or, via email, send a message with subject or body 'help' to
  grass5-request@grass.itc.it

You can reach the person managing the list at
  grass5-admin@grass.itc.it

When replying, please edit your Subject line so it is more specific
than "Re: Contents of grass5 digest..."

Today's Topics:

   1. Re: 5.7: man pages extended (Markus Neteler)
   2. Re: [bug #2402] (grass) r.colors - new rules=name option not yet working (Markus Neteler)
   3. Re: [bug #2402] (grass) r.colors - new rules=name option not yet working (Markus Neteler)
   4. Re: Re: Fwd: Re: Mappe GRASS (Markus Neteler)
   5. Re: Re: GRASS 5.3 release (Markus Neteler)
   6. Re: a set of wishes for GRASS 5.7 (Markus Neteler)
   7. Re: r.fillnulls (Michael Barton)
   8. Re: grass 5.3 and 5.7 scripts (Michael Barton)
   9. Re: Fwd: Re: Mappe GRASS (Frank Warmerdam)
  10. Re: [bug #2402] r.colors in GRASS 5.7 (Michael Barton)
  11. Re: a set of wishes for GRASS 5.7 (Michael Barton)
  12. Re: OGR (Frank Warmerdam)

From: Markus Neteler <neteler@itc.it>
Date: May 10, 2004 3:07:07 AM MST
To: Hamish <hamish_nospam@yahoo.com>
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] 5.7: man pages extended

On Thu, May 06, 2004 at 06:16:05PM +1200, Hamish wrote:

I have modified the build script which generates
the HTML manual pages in 5.7 to add a one-line
description of each module. Like that you can
quickly search for a certain functionality.

Now online at:
http://grass.itc.it/grass51/manuals/html57_user/index.html
(auto-generated from CVS)

So please keep on writing reasonable stuff into
module->description =

...

Another useful extension in the C code might be
the introduction of keywords. Per module maybe
2-5 keywords. But yes, a lot of work.

Could it just search through the module->description strings? most of
the keywords will already be in there, & if not probably should be.
Adding keywords to every single module is a lot of work...

Probably we first have to implement an offline search engine
(something similar as provided by the R-stats where you can search
within local manual pages). Any ideas?

An exception might be where only one of Delaunay/Voronoi is mentioned in
the description, but I guess you could always rewrite the line it if
need be.

e.g. Debian's "apt-cache search foo" works on the included 2-3 sentence
descriptions.

Nice!

Markus

From: Markus Neteler <neteler@itc.it>
Date: May 10, 2004 4:28:38 AM MST
To: Hamish <hamish_nospam@yahoo.com>
Cc: Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject: Re: [GRASS5] [bug #2402] (grass) r.colors - new rules=name option not yet working

On Mon, May 10, 2004 at 05:30:19PM +1200, Hamish wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=2402
---------------------------------------------------------------------
Subject: r.colors - new rules=name option not yet working

I tried the new rules=[filename] option. It generates ERROR: Unable to
open rules file [filename]. Then it stops all processing until a
ctrl-C is pressed. I tried a simple rules file:

1 blue
2 green
end

(I tried it with and without 'end' and got the same result)

The rules file needs to be in the $GISBASE/etc/colors/ directory.

I have added the path to the message. Now the user knows where
the file is searched:

r.colors N45E008.meters rules=test.rul
ERROR: Unable to open rules file test.rul in
       /nfsmnt/ssi0/ssi/neteler/grass57/dist.i686-pc-linux-gnu/etc/colors/test.rul

I just added a few more: terrain, bcyr, slope, and elevation. You can try
copying over the four example files from src/raster/r.colors/cmd/ as
well, some are nice.

Fixed also in 5.7 now.

Also, it won't even get this far from the autogenerated GUI because it
conflicts with the type=[option] argument. There needs to be a 'none'
selection for the type option in the GUI header.

The GUI and man page will be updated at some point to cover both these
issues..

Left to the author :slight_smile:
On command line it's functional now in 5.7.

Markus

From: Markus Neteler <neteler@itc.it>
Date: May 10, 2004 4:34:53 AM MST
To: Glynn Clements <glynn.clements@virgin.net>
Cc: Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject: Re: [GRASS5] [bug #2402] (grass) r.colors - new rules=name option not yet working

On Mon, May 10, 2004 at 08:08:54AM +0100, Glynn Clements wrote:
...

Also, it won't even get this far from the autogenerated GUI because it
conflicts with the type=[option] argument. There needs to be a 'none'
selection for the type option in the GUI header.

It needs to be a separate menu entry; exactly the same issue also
applies to the rast= option.

What about a function which reports the names of the currently
existing files in $GISBASE/etc/colors/ ? A function which
returns the file names as comma separated list? Then
the 5.7 GUI would auto-generate a selection box, and the cmd
line version would show the names (so no further blind guessing).

Markus

From: Markus Neteler <neteler@itc.it>
Date: May 10, 2004 5:32:47 AM MST
To: Paolo Cavallini <cavallini@faunalia.it>
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] Re: Fwd: Re: Mappe GRASS

On Fri, May 07, 2004 at 06:38:55PM +0200, Paolo Cavallini wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all, we are trying to compile compiling grass and we've got this error:

make[2]: Entering directory `/home/paolo/grass51/general/g.proj'
gcc -I/home/paolo/grass51/include
- - -I/home/paolo/grass51/dist.i686-pc-linux-gnu/include -DGV_FORMAT_51 -Wall
- - -Wconversion -Wno-implicit-int -I/usr/include -DUSE_GDAL_H
- - -I/home/paolo/grass51/include
- - -I/home/paolo/grass51/dist.i686-pc-linux-gnu/include \
        -o OBJ.i686-pc-linux-gnu/main.o -c main.c
In file included from /usr/include/cpl_csv.h:46,
                 from main.c:26:
/usr/include/cpl_serv.h:149: error: conflicting types for `CE_None'
/usr/include/cpl_error.h:101: error: previous declaration of `CE_None'
/usr/include/cpl_serv.h:151: error: conflicting types for `CE_Warning'
/usr/include/cpl_error.h:103: error: previous declaration of `CE_Warning'
/usr/include/cpl_serv.h:152: error: conflicting types for `CE_Failure'
/usr/include/cpl_error.h:104: error: previous declaration of `CE_Failure'
/usr/include/cpl_serv.h:155: error: conflicting types for `CE_Fatal'
/usr/include/cpl_error.h:107: error: previous declaration of `CE_Fatal'
/usr/include/cpl_serv.h:162: error: conflicting types for
`CPLSetErrorHandler' /usr/include/cpl_error.h:117: error: previous
declaration of
`CPLSetErrorHandler'
make[2]: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1
make[2]: Leaving directory `/home/paolo/grass51/general/g.proj'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/paolo/grass51/general'
make: *** [default] Error 1

  The problem seems generated by a double declaration in the following
headers:
/usr/include/cpl_error.h
/usr/include/cpl_serv.h
installed from these packages:
libgeotiff1-devel-1.1.4-7mdk
libgdal0-devel-1.1.9-2mdk

Maybe you can try GDAL 1.2.0 first (1.1.9 is really old):
Debian Package Tracking System - gdal

If the problem persists, it should be reported to the
GDAL mailing list (otherwise success :-).

Good luck,

Markus

From: Markus Neteler <neteler@itc.it>
Date: May 10, 2004 5:34:20 AM MST
To: grass5@grass.itc.it
Subject: Re: [GRASS5] Re: GRASS 5.3 release

On Fri, May 07, 2004 at 09:17:34AM -0700, Michael Barton wrote:

I agreed to get the scripts g.parser compliant, but of course will
welcome any help offered. A month back, I went through and updated as
many 5.3 scripts as I could get to work to 5.7 and submitted them to
Markus. This is about 90% of the work needed. They need to be tested by
others too of course, but should work pretty much as is with 5.3.

Michael,

could you store the updated scripts onto your web site
for others to test?

Markus

From: Markus Neteler <neteler@itc.it>
Date: May 10, 2004 6:58:11 AM MST
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] a set of wishes for GRASS 5.7

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

From: Michael Barton <michael.barton@asu.edu>
Date: May 10, 2004 7:34:00 AM MST
To: grass5@grass.itc.it
Subject: [GRASS5] Re: r.fillnulls

Markus,

I just found last night that s.surf.rst has now been upgraded to v.surf.rst. I updated the r.fillnulls script accordingly but have not had time to test it. I will do so in the next few days.

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 3:01 AM, grass5-request@grass.itc.it wrote:

It's in fact much simpler:
Once we have fixed the RST LatLong bug (the next days, already
identified), I'll submit r.fill.nulls in 5.7 with the small change
that s.surf.rst is named v.surf.rst in 5.7.

From: Michael Barton <michael.barton@asu.edu>
Date: May 10, 2004 7:37:15 AM MST
To: grass5@grass.itc.it
Subject: [GRASS5] Re: grass 5.3 and 5.7 scripts

Sorry if I misunderstood and got it backward. As far as scripts and tcltkgrass are concerned, there is no reason not to release 5.3.0 as it is. I was thinking ahead to the final 5.4 version. I can make the 5.3 scripts 5.7 compatible or not. Whatever works the best for all.

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 3:01 AM, grass5-request@grass.itc.it wrote:

No, I suggested the opposite (maybe I was not clear in that
personal mail). With one limitation:
But I also suggested to stop 5.3 development and to go for 5.7.

From: Frank Warmerdam <warmerdam@pobox.com>
Date: May 10, 2004 7:54:46 AM MST
To: cavallini@faunalia.it
Cc: grass5@grass.itc.it
Subject: [GRASS5] Re: Fwd: Re: Mappe GRASS

Paolo Cavallini (by way of Paolo Cavallini <cavallini@faunalia.it>) wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all, we are trying to compile compiling grass and we've got this error:
make[2]: Entering directory `/home/paolo/grass51/general/g.proj'
gcc -I/home/paolo/grass51/include
- - -I/home/paolo/grass51/dist.i686-pc-linux-gnu/include -DGV_FORMAT_51 -Wall
- - -Wconversion -Wno-implicit-int -I/usr/include -DUSE_GDAL_H
- - -I/home/paolo/grass51/include
- - -I/home/paolo/grass51/dist.i686-pc-linux-gnu/include \
        -o OBJ.i686-pc-linux-gnu/main.o -c main.c
In file included from /usr/include/cpl_csv.h:46,
                 from main.c:26:
/usr/include/cpl_serv.h:149: error: conflicting types for `CE_None'
/usr/include/cpl_error.h:101: error: previous declaration of `CE_None'
/usr/include/cpl_serv.h:151: error: conflicting types for `CE_Warning'
/usr/include/cpl_error.h:103: error: previous declaration of `CE_Warning'
/usr/include/cpl_serv.h:152: error: conflicting types for `CE_Failure'
/usr/include/cpl_error.h:104: error: previous declaration of `CE_Failure'
/usr/include/cpl_serv.h:155: error: conflicting types for `CE_Fatal'
/usr/include/cpl_error.h:107: error: previous declaration of `CE_Fatal'
/usr/include/cpl_serv.h:162: error: conflicting types for
`CPLSetErrorHandler' /usr/include/cpl_error.h:117: error: previous
declaration of
`CPLSetErrorHandler'
make[2]: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1
make[2]: Leaving directory `/home/paolo/grass51/general/g.proj'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/paolo/grass51/general'
make: *** [default] Error 1
  The problem seems generated by a double declaration in the following headers:
/usr/include/cpl_error.h
/usr/include/cpl_serv.h
installed from these packages:
libgeotiff1-devel-1.1.4-7mdk
libgdal0-devel-1.1.9-2mdk

Paolo,

This problem is related to a conflict between libgeotiff and GDAL definitions.
Curse me for using a version of my low level CPL definitions in libgeotiff!

Anyways, I would suggest you upgrade to GDAL 1.2.0 and libgeotif 1.2.2 and see
if the problems persist.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

From: Michael Barton <michael.barton@asu.edu>
Date: May 10, 2004 8:16:15 AM MST
To: Markus Neteler via RT <grass-bugs@intevation.de>
Cc: grass5@grass.itc.it
Subject: [GRASS5] Re: [bug #2402] r.colors in GRASS 5.7

This sounds good.

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 4:33 AM, Markus Neteler via RT wrote:

On Mon, May 10, 2004 at 08:08:54AM +0100, Glynn Clements wrote:
...

Also, it won't even get this far from the autogenerated GUI because it
conflicts with the type=[option] argument. There needs to be a 'none'
selection for the type option in the GUI header.

It needs to be a separate menu entry; exactly the same issue also
applies to the rast= option.

What about a function which reports the names of the currently
existing files in $GISBASE/etc/colors/ ? A function which
returns the file names as comma separated list? Then
the 5.7 GUI would auto-generate a selection box, and the cmd
line version would show the names (so no further blind guessing).

Markus

From: Michael Barton <michael.barton@asu.edu>
Date: May 10, 2004 8:38:05 AM MST
To: Markus Neteler <neteler@itc.it>
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] a set of wishes for GRASS 5.7

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!

From: Frank Warmerdam <warmerdam@pobox.com>
Date: May 10, 2004 9:02:13 AM MST
To: Radim Blazek <blazek@itc.it>
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] OGR

Radim Blazek wrote:

I added also OGR DBMI driver, but there is a problem,
I wanted to use FID (feature ID) as GRASS category, unfortunately
FID may be 0, in GRASS, category = 0 is the same as no category,
so I used FID+1 in vector library, but I forgot that it cannot
work in the driver. Any idea how to solve this?

Radim,

I'm not sure what is the problem with using FID+1. Could you explain
why this does not "work in the driver"?

As previously noted, many OGR formats are not suitable for random access,
and some do not have stable FIDs, though in some cases this is a bug that
could be corrected.

I'm not sure why the performance was so bad with shapefiles. Generally,
random access to shapefiles via FID should be relatively fast. It would
be interesting to see what is making this slow.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

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