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

[Hamish]

[mix of replies here..]


Russell:
> Because that's what Fedora has packaged. 

There's little anyone here can do about that, except get 6beta2 ready
and hope the redhat people pick it up.


>  > When you create a "location" to store your GIS files, you are asked
>  > to define a default region. You don't HAVE to do this (you can just
>  > put 0 and 1 in the extents in fact), but it is a good idea.
> 
> Then that is what GRASS should do.

A note could be added that "non-critical - you can change these later".
(Of course we need to make the default region overwritable first :)
A GUI (click Next..) for all of this will happen one day. bit by bit...


> 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.  Prompt them for the
> projection, and use the inferred value as the default.  That's now the
> projection for everything in $HOME/.grass.

So what if the user is in Europe or Asia? XY or Lat-lon?
I'm in New Zealand, we use a couple different howevermany million
projections here and a couple of different map datums; UTM isn't used
much if at all.

The very important point is this: it is much better to make no choice
at all rather than to start making incorrect assumptions. This way the
user knows where the error is and what question has to be answered.
It's a very important and well demonstrated point. Many disasters.

with respect to setting locations automatically from GeoTIFFs by
default: I've got a CD here with about 50 important maps, all with
bogus/incorrect metadata. I don't think this is so unusual, upstream
data sources of specialist items often have less than perfect quality
control. Just in my one case yes, but the problem exists, and a new user
is never going to be able to know what to trust..
I am reminded of Excel vs. Matlab in taking an average of a series of
data points. Excel will take the average irregardless of the number of
NaN cells; Matlab will cough blood and make you explicitly tell it
that's what you really really want to do. Ease of use vs. imposed
correctness isn't always a bad thing.


[reorganizing GRASS raster directory structure planned for the future]
> It's just renaming.

no, it is resorting files in a non-backwards compatible way. I guess you
could leave a trail of symlinks but that's even messier.
This will happen one day.


> > Renaming of symbols upon which downstream client software depends is
> > a backward compatibility issue.
>
> How many other programs besides the ones shipped with GRASS understand
> GRASS's file hierarchy?  I acknowledge the general case of the problem
> you describe.

gdal->qgis for one.
lots of homebrew scripts for two.
anyway -- this will happen one day and the world will adapt.


re the GRASS prompt "too UNIXy".
would you prefer
PS1='GRASS:\W > '
?

re using shell scripts to automate grass modules.
For me this along with openness of the source are the two most 
important features GRASS has. I'm often running scripts 
controlling thousands of model runs 24 hours a day on a custom 
code base.... nothing else can come close to doing that.


Re "what a pile of shit, let's start over from the CERL code".
Thierry Laronde has already started this with his KerGIS:
  http://www.kergis.com/

Thuban & QGIS are not really competition to GRASS, as they are more
cartography packages (sounds like what you are really looking for) while
GRASS is more focused on analysis and modelling.
QGIS works quite well as a GUI front end for GRASS by the way.


> Anecdotal evidence: I saw a presentation by the NPS on water flow in
> Mammoth Cave.  Me: "Nice maps; did you use GRASS?"  NPS: "No,
> ARCview.  We used to use GRASS, but .... we switched."

not to hide my head in the sand but correlation does not predicate
causality .. staff turnover & lack of motivation to retrain is usually
a biggie, even if the old system worked better if you knew how to use
it properly.

If you want nice maps, use GRASS->GMT.
 (or ps.map if you want to learn & tweak [that one's at the heart of
  this issue: d.m's print menu as a front end for ps.map])


> GRASS developers acknowledge that GRASS is hard to use
> on one hand, but they also say that fixing that problem is not a
> priority for them.

Speaking for myself, I get paid to run models and make maps, not make
nice GUIs for other people (nothing against other people, but they 
don't give me money). My priority is to get GRASS to do what I want it
to do, and to a point where I can publish and others can reproduce my
results without being a C programmer or a diviner. If someone like
Michael Barton can come along and fix up the GUI or someone like Radim
Blazek can help write a new one, or someone like Lorenzo Moretti can do
an amazing job packaging it, then great. Just not me.
[yes, I understand ease of use != GUI, just verbally...]

n.b. installation used to be "the hardest step" after which everything
became easier. Seems we've moved on down the road.


Mark:
> Why does GRASS require more users?

more users mean a more diverse base & more bug squashing, good thing.
compromising core features to do so, bad thing. (*cough* gnome 2.4)


Mark:
> GRASS is not really intended for use by naive users.

everyone has to start out from zero at some point. The learning curve is
steep, but we shouldn't grease it.


Mark:
> If there are complaints that it is not small enough to
> fit in your shirt pocket and that it doesn't have a little LCD screen
> for displaying web pages, 

yeah, we do that:
 http://grass.ibiblio.org/platforms/grasshandheld.html


Mark:
> 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.

a) I don't believe we've met.
b) crap, I'm in the wrong place.
 :)
[well I'm no Mr.Vanderbilt but I've been to his air-boat shed once.]


I think the answer is: be consistent and concise and let there be a
logic to it. ease of use flows from that.


... anyway back to spending the finite energy fixing things.



regards,
Hamish