Hi Steve,
[cc to grass5 developers list]
On Tue, Jan 23, 2001 at 04:47:09PM -0600, Stevet@redriver.water.ca.gov wrote:
22 Jan. 2001
GRASS 5 Develipment Team;
via - Marcus Neteler <neteler@geog.uni-hannover.de>Your web page asks for comments, bugs and such.
SO.....
I downloaded last week's snap-shot. The "stable" tar-ball
was not present due to a stated found-error. The web page indicated
that the snap-shot had the error fixed.I compiled the snap-shot on both Slackware 4.0 and Slackware
7.1. The first is a "libc-5" type and the second is a "glibc2" type.
It compiled on both. The 7.1 compile had numerous pointer conversion
errors. The 4.0 had relitivly none. Experience dictates bad coding
practices to be the cause. Simply isolate the warnings, add the usual
force to type in the call and the warnings go away. If they don't then
the compiler has a problem that needs to be addressed.
GRASS 5 is still on it's way to compile without *any* warning.
Comparing to 1999 we are quite close now. Please send over the
warnings for analysis, maybe we can fix them.
After compilation I tried to run a small project through the
GRASS5.0-beta11 I had just compiled. (I tried this on both compiles
and got the same results, which speaks well for consistancy.)First problem: The fix-2 in the v.out.ascii has never been
addressed. I have, at least twice, posted the
problem, it reasion and the fix to the GRASS
users group.
In fact this is not o.k. We apologize if this happened the last twelve
month and kindly request you to send your patch again. If it fixes
a problem, we should immediately update v.out.ascii.
Second problem:The vector-to-raster converter is broken. Not
only does ver.5 run considerably slower than
ver.4.21, it fails to handle files of size.
One file it was to convert was to have 104
passes. It hung on the 8th and after 45 minutes
of effort required me to pull the power to regain
control of my machine.
The same input, on the same machine but running
GRASS 4.21 took 12 minutes and 11 seconds to run
all 104 passes to normal completion.
This was reported recently to me. On my machine (Linux, Suse7) I don't
face such problem. Please report the bug here:
http://www.geog.uni-hannover.de/grass/bugtracking/bugreport.html
Third problem: The r.stats program has been modified. The
doccumentation has been modified. But they do not
agree.
That's to be corrected.
There are programmers in this world that
can certify that I fire people for doing that.
As GRASS is open source and the development team open to new members
and contributions I invite you to update the html-page of r.stats.
If you send the update to me, I will update it in CVS.
Generally GRASS is GPL-licensed (The GNU General Public License v3.0 - GNU Project - Free Software Foundation).
See "11":
"NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR
THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO
THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM
PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.
"
Luckily we cannot get fired... The general idea of GRASS is to collect
contributions of users and programmers. GRASS is always is transition,
however, we work hard to get it as stable and consistent as possible.
Please keep in mind that GRASS is huge:
As of Jan 24 2001 the .c and .h files count nearly 1.5 Million lines
of source code.
I don't expect programmers to be English Professors, but I do
make them responsible for the accuracy of the doccumentation of their
own efforts. If you modify a subroutine, I expect you to rewiew/correct
it's doccumentation. I leave it to the English Lit types to correct the
spelling, grammar and make it presentable. But - the programmer is still
responsible for the correctness of the content.
I agree. Perhaps you could volunteer to assist us in correcting the
documentation?
Change of subject. In one section I saw a request for someone
to add a "block adjustment" module. Talk about a brain going a zillion
different directions at the same time! I finally got it under control
enough to hold it to just a few points. Why? Where is the rest of it?
Who has the skill to trouble shoot it? What is the bases of the data to
be used (table-top scanner, near quarter million dollar roll feed auto-
adjusting computer driven scanners, micron accuracy multi-read mechanical
plattens) ??? What about the image itself? Is it with fids, or reseau,
or none of the above??? "Block Adjust" is more like a sledge hammer,
and it comes at the end, (usually) after a great deal of effort in the
refinement of the base and the image data via the strip adjustments.
(The fancy roll feed scanner (LH-Systems) is in the other room.)
1. It's on the wish list
2. It's not stated that it should be integrated into the core package
3. see below
This brings me to a point I feel I need to air. It can be fun
to take someone else's efforts and 'improve' it. It can be quite
gratifying to take something 'make-shift' and turn it into something
'solid'. BUT - there are some 'lines in the sand' that cannot be
crossed. A programmer is a tool maker. Very akin to a tool-n-die shopman.
A programmer is NOT the craftsman who will use the tool. Just as the
hammer maker, the screwdriver maker and other tool makers know they
must never, never dictate to the craftsman how to hold or use the tool
or which tool to use for what, so it must be with programmers.
Here I don't agree. Most of the GRASS developers *are* using there modules.
That's the basic reason to develop them.
A tool
that is built from less than 'solid' materials will always be less in
quality. Just as a program 'thrown together' from various changeable
aids will never be de-bug-able. No quality mechanic would ever willingly
buy a wrench which had a softwood handle, a plastic jaw and was bound
together by string. The same goes for application programs. Pick a
language for the application and stick to it.Our first acquisition of GRASS was on a Spark Station, then
on a DecStation and now on PC's. Maybe you can port your code to
the next platform correctly.
I still don't see the problem except the three bugs denoted above.
But will the other aids make the effort?
Can the other aids even be ported? Will their makers do a craftsman
like job of their ports? I am of course talking about TK, TCL, JAVA,
and all the other "shortcuts" I see in GRASS5. The tool-n-die
shopman is a craftsman. One that has much skill. One that knows his
first job is to fully understand the design he is asked to create.
Else how can he choose his materials? Or his fabrication methods?
So it must be for the programmer.To agree or to disagree with what you have read comes under
the wonderfull concept of Freedom of Choice. As it should! But here
is a truth:
When one takes on oneself the job of maintainer of product,
particularly a product upon which others base their livelyhood, one
leaves the realm of children. "Hacking code" isn't "Crafting code."
I have no problems if you go back to older GRASS releases. We don't
force you to use the current version.
ftp://grass.baylor.edu/pub/grass/grass4.0/
ftp://grass.baylor.edu/pub/grass/grass4.2/
Old GRASS FP version:
ftp://129.229.103.1/pub/grass/outgoing/Floating_pt/
(enjoy compiling this version)
If you just have to have a block adjust program, I believe
BLUH was written at the University of Hannover, Germany; in fortran.
It ran on the PDP-11 and VAX-VMS. State of California got a lot of
use out of it. It was discontinued when they converted to soft-copy
a couple of years ago.V6.30 - July 1985
Autnor - Dr.-Ing. Karsten Jacobsen
Institut fur Photogrammetrie und Ingenieurvermessungen
Universitat Hannover
Nienburger Strasse 1
D 3000 HannoverLocation close enough?
I know Dr. Jacobsen, met him recently. But BLUH is proprietary.
http://www.ipi.uni-hannover.de/html/service/bluh/BLUH.HTM
So we cannot use it under terms of GPL.
Steven L. Turner LLS stevet@water.ca.gov
GIS Tech. Support (916) 653-4041 V/M
Unit - Land & Water Use (916) 657-4796 F
Section - Statewide Planning
Division of Planning and Local Assistance
Department of Water Resources
State of California
1416 9th Street, Rm 150
Sacramento, CA 95814
Regards
Markus Neteler
--
Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'