[GRASS5] Re: [Fwd: whinging about GRASS again]

[Mark P. Line]

Russell Nelson said:
> Michael Barton writes:
>>
>> First, a question. Since you are trying the most current version of
>> GRASS (something I indeed recommend), why are you testing some version
>> of 5.7 when 6.0.0 beta 1 has been released. Depending on which version
>> of 5.7 you are looking at, this could make an enormous difference in the
>> functionality of GRASS.
>
> Because that's what Fedora has packaged.  When somebody says "GRASS is
> the open source GIS program", and they install the GRASS package,
> that's what they'll get.

Sorry, there's no such thing as "the GRASS package".


> Here's one way the learning curve could be flattened:
>
> First, don't ask for a location.  Use $HOME/.grass.

What do you call it on Windows and Mac systems?
How do you share locations among several users?


> Second, when they import something into $HOME/.grass, look at its
> bounding box. If it's 0,0 through (say) 2048,2048, then it's an xy
> projection.  If it's 45,-75 through 44,-74, it's lat/lon.  If it's
> howevermany hundred thousand by howevermany million, it's UTM.

If you believe that there's a solid algorithm for automatically generating
a useful DEFAULT_WIND for a map or set of maps that are about to be
imported into a location, code it up and contribute it. If it works, there
might be users besides yourself who'd like to use it.


>  > However, many others were reluctant to do so because of backward
>  > compatibility with large investment in GIS data.
>
> It's just renaming.

Renaming of symbols upon which downstream client software depends is a
backward compatibility issue. Even if what you're doing seems completely
innocuous, it's not innocuous if it breaks an interface contract that
other components in the greater environment have relied upon. That comes
with the territory when you're dealing with software-in-the-large.

"I think I'll rebuild my Linux kernel with fork() renamed to spoon().
Surely that won't cause any problems, since all I've done is rename one
little symbol." See the problem?


>> However, this has been done with a very small community of very
>> dedicated developers. To have more improvements requires more user
>> contribution to GRASS development.
>
> It also requires more GRASS users.

Why does GRASS require more users?


> GRASS can do a better job of tolerating GIS naivete.

Why would it want to do that?

GRASS is not and never has been a desktop mapping application for
Heathcliff Xavier Thurston Vanderbilt III, maritime division manager for
Ocean Shipping International, Inc. who doesn't know a projection from a
chinchilla but who needs to see where the SS LeaksRUs is currently located
on a world map on his computer screen.

GRASS is a spatial analysis and visualization application for John Miller,
principal investigator for the federal fisheries laboratory who's picked
up a project for assessing the return distribution of tagged coho salmon
in south Alaska rivers.

The John Millers of the world use GRASS daily more or less without
complaint, and enjoy every new version that comes down the pike with even
more useful functionality.

The Cliff Vanderbilts of the world don't even dust their own monitors, and
certainly GRASS is not for them. There are plenty of products out there
for this type of user, and they're likely to just go out and buy one of
them.

There's no need for the GRASS development community to waste its time
morphing GRASS from something that gives John Miller the latest in
algorithmic wherewithal into something that gives Cliff Vanderbilt
something to click at in between morning tennis and afternoon golf.


> I think that 90% of my complaints are caused by the GRASS shell.  I'll
> bet that if I spend some time looking at it, I'll find some
> improvements that can be made.

Of course. Anybody can do that. But can you design and code the
improvements and make them stick?


-- Mark

Mark P. Line
Polymathix
San Antonio, TX