[GRASS5] Re: GRASS 5.7 updated scripts
Michael Barton
michael.barton at asu.edu
Mon May 10 13:52:22 EDT 2004
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 at grass.itc.it wrote:
> Send grass5 mailing list submissions to
> grass5 at 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 at grass.itc.it
>
> You can reach the person managing the list at
> grass5-admin at 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 at itc.it>
> Date: May 10, 2004 3:07:07 AM MST
> To: Hamish <hamish_nospam at yahoo.com>
> Cc: grass5 at 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 at itc.it>
> Date: May 10, 2004 4:28:38 AM MST
> To: Hamish <hamish_nospam at yahoo.com>
> Cc: Request Tracker <grass-bugs at intevation.de>, grass5 at 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 :-)
> On command line it's functional now in 5.7.
>
> Markus
>
>
>
>
> From: Markus Neteler <neteler at itc.it>
> Date: May 10, 2004 4:34:53 AM MST
> To: Glynn Clements <glynn.clements at virgin.net>
> Cc: Request Tracker <grass-bugs at intevation.de>, grass5 at 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 at itc.it>
> Date: May 10, 2004 5:32:47 AM MST
> To: Paolo Cavallini <cavallini at faunalia.it>
> Cc: grass5 at 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):
> http://packages.qa.debian.org/g/gdal.html
>
> If the problem persists, it should be reported to the
> GDAL mailing list (otherwise success :-).
>
> Good luck,
>
> Markus
>
>
>
>
> From: Markus Neteler <neteler at itc.it>
> Date: May 10, 2004 5:34:20 AM MST
> To: grass5 at 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 at itc.it>
> Date: May 10, 2004 6:58:11 AM MST
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass5 at 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 at asu.edu>
> Date: May 10, 2004 7:34:00 AM MST
> To: grass5 at 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 at 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 at asu.edu>
> Date: May 10, 2004 7:37:15 AM MST
> To: grass5 at 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 at 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 at pobox.com>
> Date: May 10, 2004 7:54:46 AM MST
> To: cavallini at faunalia.it
> Cc: grass5 at grass.itc.it
> Subject: [GRASS5] Re: Fwd: Re: Mappe GRASS
>
>
> Paolo Cavallini (by way of Paolo Cavallini <cavallini at 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 at 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 at asu.edu>
> Date: May 10, 2004 8:16:15 AM MST
> To: Markus Neteler via RT <grass-bugs at intevation.de>
> Cc: grass5 at 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 at asu.edu>
> Date: May 10, 2004 8:38:05 AM MST
> To: Markus Neteler <neteler at itc.it>
> Cc: grass5 at 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 at pobox.com>
> Date: May 10, 2004 9:02:13 AM MST
> To: Radim Blazek <blazek at itc.it>
> Cc: grass5 at 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 at 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 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 26942 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040510/afe61a5b/attachment.bin
More information about the grass-dev
mailing list