multi-g.manuals; concurrency locking

GRASS GRASS user
1

De gustibus non esse disputandum. What icons and menus would you like me
to provide you with so that you can use the point-and-click method to
develop r.binfer scripts? r.combine? How about controlling ps.map? You
design the user interface, and I'll build it. But not for any Microsoft
platform. :slight_smile:

Icons or menus are for controlling programs like r.binfer, r.combine
or something like ps.map (which is useless under MS Windows as
your finished WYSIWYG map or picture is sent directly to the
postscript printer or to the *.ps file using the point-and-click method).
Besides this, all of these
programs have been programed in C-language and I do not see
a big problem to move them under MS Windows. For example
all the programs I was working on had been programmed
on a PC using Borland C++ with elegant Development Environment
which drastically reduces development time (e.g. r.flow, r.flow.3d,
r.flow.time, r.sun) and only after that I moved them into GRASS
(it usually took me a few days).

> Plenty
> of available SW for funny low prices allow me to combine those
> SW packages which are best for solving a specific task.

Precisely. Linux, XFree, GRASS, Khoros, Tcl/Tk, ...

These are really low-cost but also with minimal guarantees and
low technical support and documentation. I do not prefer hunting bugs...

User interfaces to software have to match the "bandwidth" of the software
being controlled. Point-and-click-type interfaces have a very low
bandwidth, which is fine if that's what your underlying software has. Some
parts of GRASS have such low bandwidth: d.rast, d.erase, d.frame if you
break it down into component actions, etc. Other parts of GRASS, however,
have a *very* much greater bandwidth: r.[b]infer, r.combine, p.map and so
on. Trying to force high-bandwidth software under a low-bandwidth user
interface will only cause problems.

Ask Intergraph, PCI and other companies why they move their products
under Windows NT...

Whom do you mean by "GRASS programmers", and who defines what their "task"
is? You can only mean (a) GRASS programmers at CERL or (b) GRASS
programmers outside of CERL. CERL programmers know what their tasks are,
and they are not bound by what you or I think they are, because they have
their own clientele (to which neither you nor I belong). GRASS programmers
outside of CERL are almost always GRASS users who find they need to do
some programming or shell scripting along the way.
The number of GRASS
programmers outside of CERL who are not primarily GRASS users you can
count on the fingers of one hand. I'm one, some people at Osiris are too,
and I suspect that Gilles Clement would put himself in that category.
There are others. But pretty much all other GRASS programmers *outside*
CERL have user-oriented agendas related to their tasks (or their
organization's tasks) as GRASS users. So: CERL programmers' tasks are
defined by somebody other than you or me; other programmers' tasks are
defined by somebody other than you or me (except that I define my own
tasks as a GRASS programmer).

I agree with you. That's why there is a big problem to make GRASS with
floating point or high-technology features (3D and 4D GRASS).

I think you're forgetting where GRASS is coming from (literally) and how
it is developed. If you do not want to do your own GRASS programming, but
have good suggestions on how you think GRASS could be improved, you should
definitely post your ideas to one of the GRASSHopper lists. Maybe somebody
will take you up on your ideas. If you keep them to yourself, they can't.

You are also saying: if you do not satisfied then make your own
program or wait 5-10 years when someone will make it.

Do you think this is the best way how to hold GRASS among top GIS'?

Regards,

Jaro

------------------------------------------------------------------------
Jaro Hofierka
Dept. of Cartography, Geoinformatics & Rem. Sensing
Comenius University
842 15 Bratislava E-mail: hofierka@devin.fns.uniba.sk
Slovakia hofierka@geoinfo.fns.uniba.sk
------------------------------------------------------------------------

2

On Sat, 26 Mar 1994, Jaro Hofierka wrote:

Icons or menus are for controlling programs like r.binfer, r.combine
or something like ps.map (which is useless under MS Windows as
your finished WYSIWYG map or picture is sent directly to the
postscript printer or to the *.ps file using the point-and-click method).

How would you use icons or menus to control r.binfer, for example? I think
we're misunderstanding each other here.

Besides this, all of these
programs have been programed in C-language and I do not see
a big problem to move them under MS Windows. For example
all the programs I was working on had been programmed
on a PC using Borland C++ with elegant Development Environment
which drastically reduces development time (e.g. r.flow, r.flow.3d,
r.flow.time, r.sun) and only after that I moved them into GRASS
(it usually took me a few days).

I suspect that the code in r.flow, r.sun etc. was pretty
platform-independent (largely numerical, aren't they?). What about
developing the equivalents to xgdisplay, xgregion, xgmapcalc or xdigit
under MS-Windows? And to what end?

> Precisely. Linux, XFree, GRASS, Khoros, Tcl/Tk, ...
>
These are really low-cost but also with minimal guarantees and
low technical support and documentation. I do not prefer hunting bugs...

Low documentation only applies to GRASS, out of the packages I mentioned
above. Low technical support only applies to any of them if you don't have
access to the Internet. If you do, then there are hundreds (for Linux:
tens of thousands) of people who read the newsgroups where you can get
tech support.

I've been using the above configuration (except for Khoros, which breaks
my disk space for the time being) for over six months now, and have yet to
hunt for any kind of bug. I just install the software and use it. I think
you might have gained a very wrong impression of contemporary freeware.

> User interfaces to software have to match the "bandwidth" of the software
> being controlled. Point-and-click-type interfaces have a very low
> bandwidth, which is fine if that's what your underlying software has. Some
> parts of GRASS have such low bandwidth: d.rast, d.erase, d.frame if you
> break it down into component actions, etc. Other parts of GRASS, however,
> have a *very* much greater bandwidth: r.[b]infer, r.combine, p.map and so
> on. Trying to force high-bandwidth software under a low-bandwidth user
> interface will only cause problems.

Ask Intergraph, PCI and other companies why they move their products
under Windows NT...

Ask them why they're simultaneously retaining support of their traditional
Unix platforms. Vendors will port software if there are customers for
the new platform. There are customers for new Microsoft platforms because
Microsoft has a good marketing department.

Anyway, GRASS is being ported to Windows NT also. Why not? NT has a
Unix-like kernel derived from Mach. If the system dependencies can be
worked out for the display subsystem, then there's no reason why GRASS
shouldn't be ported to NT. You can bet, though, that that most definitely
will not cause GRASS to disappear from Sun, SGI or Linux platforms.

> I think you're forgetting where GRASS is coming from (literally) and how
> it is developed. If you do not want to do your own GRASS programming, but
> have good suggestions on how you think GRASS could be improved, you should
> definitely post your ideas to one of the GRASSHopper lists. Maybe somebody
> will take you up on your ideas. If you keep them to yourself, they can't.

You are also saying: if you do not satisfied then make your own
program or wait 5-10 years when someone will make it.

Come on, Jaro, play fair. As you can see, I explicitly said the *opposite*
of what you're accusing me of here. What would the people who develop and
maintain Windows NT say if you told them you thought it needed a
left-handed gribbet? They would say, "if you are not satisfied then make
your own program or wait 5-10 years and someone will make it". What do the
many GRASS programmers say when you tell them that GRASS needs a
left-handed gribbet? Well, I can't speak for others, but I always say,
"tell me how you think a left-handed gribbet should work in GRASS, and
maybe I can make one, if I think I and other people might need one, too".
That is, in fact, what happens constantly within the GRASS community.
You've done so yourself, in fact, haven't you?

Do you think this is the best way how to hold GRASS among top GIS'?

Funny you should mention that. GRASS probably has the worst user interface
of any GIS I've ever seen, but its strict modularity makes it pretty easy
to shrink-fit just about any user interface front-end around an existing
installation. Nobody in her right mind would ever claim that GRASS was
easy to learn, but it's not really hard to use. Nevertheless, there are
something like 15,000 GRASS users worldwide, from what I hear. One reason
for that might be that it doesn't cost anything. But, there's lots of free
software that people won't use, for various reasons. So there must be
additional reasons why so many people want to use GRASS, in spite of
itself.

Jaro, nobody is telling you to "go write a program if you don't like what
you've got", because nobody is telling you to use GRASS, and the GRASS
you've got probably didn't cost you much.

So, now, I'm ready to hear all your constructive comments on what aspects
of GRASS should be improved. And I'm not telling you to go off and worry
about the improvements yourself, but I'm offering to look into the
possibilities of contributing code or documentation. That is, unless you
don't want me to.

-- Mark

--------------------------------------------------------------------
Mark P. Line Phone: +1-206-733-6040
Open Pathways Fax: +1-206-733-6040
P.O. Box F Email: markline@henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------