[GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25

GRASS GIS GRASS GIS developer
1

Hi,

a few questions:

On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote:

Author: michael

Update of /grassrepository/grass6/lib/init
In directory doto:/tmp/cvs-serv30054

Modified Files:
  gis_set.tcl
Log Message:
update exec and eval exec statements to properly parse arguments

Index: gis_set.tcl

RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -d -r1.24 -r1.25
--- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24
+++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25
@@ -312,10 +312,10 @@
     pack $introtitle -side top

     .frame0.intro.msg tag configure all -justify center
- .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS Version $GRASSVERSION\n"]
+ .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS version $GRASSVERSION\n"]
     .frame0.intro.msg insert end [G_msg "The world's leading open source GIS\n\n"]
- .frame0.intro.msg insert end [G_msg "Select an existing project location and mapset\n"]
- .frame0.intro.msg insert end [G_msg "or define a new project location\n"]
+ .frame0.intro.msg insert end [G_msg "Select an existing projection location and GIS mapset\n"]

... what does "existing projection location" mean?
I only know "existing project location". The change adds confusion in my opinion.
If projected is meant, it is not right since latlong (usually) and xy (always) are
unprojected.

+ .frame0.intro.msg insert end [G_msg "or define a new projection location\n"]

...also here.

     .frame0.intro.msg tag add all 1.0 end
     .frame0.intro.msg configure -state disabled

@@ -338,7 +338,7 @@
     label .frame0.frameDB.left.label \
       -anchor {n} \
       -justify right \
- -text [G_msg "Path to location: \n(GRASS Database)"]
+ -text [G_msg "Path to location : "]

"GRASS Database" is a widely used term in the GRASS literature,
but sure if it should be removed.

     entry .frame0.frameDB.mid.entry \
       -relief {sunken} \
@@ -408,7 +408,7 @@

     label .frame0.frameMS.label \
       -anchor {w} \
- -text [G_msg "Accessible Mapsets"]
+ -text [G_msg "(Accessible) GIS Mapsets"]

... this re-reverted the last fix...
The () do not add information in my opionion.

     listbox .frame0.frameMS.listbox \
       -relief {sunken} \
@@ -460,7 +460,7 @@

     label .frame0.frameNMS.first.label \
       -anchor {n} \
- -text [G_msg "Create new mapset\nin selected location"]
+ -text [G_msg "Create new GIS mapset\nin currrent location"]

I am also not sure of that. In the beginning nothing is selected,
so there is no currrent location.
  

     entry .frame0.frameNMS.second.entry \
       -relief {sunken} \
@@ -495,7 +495,7 @@

     label .frame0.frameNMS.fourth.label \
       -anchor {n} \
- -text [G_msg "\nDefine new location by:"]
+ -text [G_msg "Define new projection location"]

... again confusing (for me).

     button .frame0.frameNMS.fifth.button \

It seems that this needs to be discussed again: at least I
would like to better understand most of the changes.

thanks

Markus

2

Markus,

I'm happy to see suggestions. Here is my rational for wording changes. Maybe
there can be better wording than my quick fix.

I'm trying to think of a user who knows something about GIS and is opening
GRASS for the first time. Before she or he can do anything--even start the
program--they have to choose a "database", "location", and "mapset".

But what is a database? Of course everyone knows that a database is an
attribute table or related set of attribute tables defined in a data
dictionary. Except that's not what a GRASS database is. It is simply the
directory/folder where "locations" are stored.

But what is a location? Of course that is a place, maybe where your study
area is located. But how do you select that? Except in GRASS, a "location"
is really a folder with definitions of the projection (including 'geographic
projections' like latlon), coordinate system, and optionally the extents
defining a particular part of the world. More people would probably
understand what we mean if we ask them to choose the projection/coordinate
system than to choose a "location".

Then you have to select a "mapset". But what is a mapset. In GRASS, that's
where your GIS files are stored--which is what this hypothetical new user
has really wanted to get at all along.

Every time I try to explain how to start GRASS, I have to explain what a
"database", "location", and "mapset" is before the person can even get
started working with the program. Any GIS will have some jargon that a
person will have to get through (e.g., 'theme' instead of layer). But it
would be nice to not have to hit someone with GRASS-specific jargon before
they even get the program opened. Of course you can press the help button,
but many people would just like to start the program before doing anything
else.

So I was trying to build in some translations of GRASS jargon to help
someone get started. I dropped "GIS Database" because it's not used much.
But location and mapset are used a lot. Of course this made for some awkward
phraseology, as you noticed. I really did mean "projection location"
instead of project location.

Maybe "Select an existing 'location' (projection/coordinate system) and GIS
Mapset..."???

GIS Mapset doesn't sound too awkward to me. But maybe to others?

Suggestions?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Mon, 17 Jul 2006 19:35:56 +0200
To: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl,
1.24, 1.25

Hi,

a few questions:

On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote:

Author: michael

Update of /grassrepository/grass6/lib/init
In directory doto:/tmp/cvs-serv30054

Modified Files:
gis_set.tcl
Log Message:
update exec and eval exec statements to properly parse arguments

Index: gis_set.tcl

RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -d -r1.24 -r1.25
--- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24
+++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25
@@ -312,10 +312,10 @@
     pack $introtitle -side top

     .frame0.intro.msg tag configure all -justify center
- .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS Version
$GRASSVERSION\n"]
+ .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS version
$GRASSVERSION\n"]
     .frame0.intro.msg insert end [G_msg "The world's leading open source
GIS\n\n"]
- .frame0.intro.msg insert end [G_msg "Select an existing project location
and mapset\n"]
- .frame0.intro.msg insert end [G_msg "or define a new project
location\n"]
+ .frame0.intro.msg insert end [G_msg "Select an existing projection
location and GIS mapset\n"]

... what does "existing projection location" mean?
I only know "existing project location". The change adds confusion in my
opinion.
If projected is meant, it is not right since latlong (usually) and xy (always)
are
unprojected.

+ .frame0.intro.msg insert end [G_msg "or define a new projection
location\n"]

...also here.

     .frame0.intro.msg tag add all 1.0 end
     .frame0.intro.msg configure -state disabled

@@ -338,7 +338,7 @@
     label .frame0.frameDB.left.label \
-anchor {n} \
-justify right \
- -text [G_msg "Path to location: \n(GRASS Database)"]
+ -text [G_msg "Path to location : "]

"GRASS Database" is a widely used term in the GRASS literature,
but sure if it should be removed.

     entry .frame0.frameDB.mid.entry \
-relief {sunken} \
@@ -408,7 +408,7 @@

     label .frame0.frameMS.label \
-anchor {w} \
- -text [G_msg "Accessible Mapsets"]
+ -text [G_msg "(Accessible) GIS Mapsets"]

... this re-reverted the last fix...
The () do not add information in my opionion.

     listbox .frame0.frameMS.listbox \
-relief {sunken} \
@@ -460,7 +460,7 @@

     label .frame0.frameNMS.first.label \
-anchor {n} \
- -text [G_msg "Create new mapset\nin selected location"]
+ -text [G_msg "Create new GIS mapset\nin currrent location"]

I am also not sure of that. In the beginning nothing is selected,
so there is no currrent location.
  

     entry .frame0.frameNMS.second.entry \
-relief {sunken} \
@@ -495,7 +495,7 @@

     label .frame0.frameNMS.fourth.label \
-anchor {n} \
- -text [G_msg "\nDefine new location by:"]
+ -text [G_msg "Define new projection location"]

... again confusing (for me).

     button .frame0.frameNMS.fifth.button \

It seems that this needs to be discussed again: at least I
would like to better understand most of the changes.

thanks

Markus

3

Michael, all,

On Mon, Jul 17, 2006 at 01:21:05PM -0700, Michael Barton wrote:

Markus,

I'm happy to see suggestions. Here is my rational for wording changes. Maybe
there can be better wording than my quick fix.

I'm trying to think of a user who knows something about GIS and is opening
GRASS for the first time. Before she or he can do anything--even start the
program--they have to choose a "database", "location", and "mapset".

But what is a database? Of course everyone knows that a database is an
attribute table or related set of attribute tables defined in a data
dictionary. Except that's not what a GRASS database is. It is simply the
directory/folder where "locations" are stored.

But what is a location? Of course that is a place, maybe where your study
area is located. But how do you select that? Except in GRASS, a "location"
is really a folder with definitions of the projection (including 'geographic
projections' like latlon), coordinate system, and optionally the extents
defining a particular part of the world. More people would probably
understand what we mean if we ask them to choose the projection/coordinate
system than to choose a "location".

I always understood (and also teach it like that) that a "location"
is a project - but not a projection.

"project location" would be even ok but "projection location" I don't
really agree with. Sure, I am not a native speaker.

Then you have to select a "mapset". But what is a mapset. In GRASS, that's
where your GIS files are stored--which is what this hypothetical new user
has really wanted to get at all along.

A mapset is a set of maps...

Every time I try to explain how to start GRASS, I have to explain what a
"database", "location", and "mapset" is before the person can even get
started working with the program.

Right. But that's not so bad because people have to even know what's
a projection to create a new location or explicitely create a
non-projected location (xy, latlong).

Any GIS will have some jargon that a
person will have to get through (e.g., 'theme' instead of layer). But it
would be nice to not have to hit someone with GRASS-specific jargon before
they even get the program opened. Of course you can press the help button,
but many people would just like to start the program before doing anything
else.

I don't think that GRASS is full of jargon.

So I was trying to build in some translations of GRASS jargon to help
someone get started. I dropped "GIS Database" because it's not used much.
But location and mapset are used a lot. Of course this made for some awkward
phraseology, as you noticed. I really did mean "projection location"
instead of project location.

Yes, you have inverted my "project location" fix :slight_smile:

Maybe "Select an existing 'location' (projection/coordinate system) and GIS
Mapset..."???

GIS Mapset doesn't sound too awkward to me. But maybe to others?

Suggestions?

I just want to avoid that we break with the existing wealth of documentation
and also a bit with tradition (we have many long term users who even took a
while to switch to GRASS 5 or GRASS 6). It is already quite hard to keep
presentations reasonably updated, but for tutorials (there are many) and books
it is even worse.

Well, let's hear the others. It's worth to get this discussed.

Markus

> From: Markus Neteler <neteler@itc.it>
> Date: Mon, 17 Jul 2006 19:35:56 +0200
> To: <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl,
> 1.24, 1.25
>
> Hi,
>
> a few questions:
>
>
> On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote:
>> Author: michael
>>
>> Update of /grassrepository/grass6/lib/init
>> In directory doto:/tmp/cvs-serv30054
>>
>> Modified Files:
>> gis_set.tcl
>> Log Message:
>> update exec and eval exec statements to properly parse arguments
>>
>> Index: gis_set.tcl
>> ===================================================================
>> RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v
>> retrieving revision 1.24
>> retrieving revision 1.25
>> diff -u -d -r1.24 -r1.25
>> --- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24
>> +++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25
>> @@ -312,10 +312,10 @@
>> pack $introtitle -side top
>>
>> .frame0.intro.msg tag configure all -justify center
>> - .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS Version
>> $GRASSVERSION\n"]
>> + .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS version
>> $GRASSVERSION\n"]
>> .frame0.intro.msg insert end [G_msg "The world's leading open source
>> GIS\n\n"]
>> - .frame0.intro.msg insert end [G_msg "Select an existing project location
>> and mapset\n"]
>> - .frame0.intro.msg insert end [G_msg "or define a new project
>> location\n"]
>> + .frame0.intro.msg insert end [G_msg "Select an existing projection
>> location and GIS mapset\n"]
>
> ... what does "existing projection location" mean?
> I only know "existing project location". The change adds confusion in my
> opinion.
> If projected is meant, it is not right since latlong (usually) and xy (always)
> are
> unprojected.
>
>
>
>> + .frame0.intro.msg insert end [G_msg "or define a new projection
>> location\n"]
>
> ...also here.
>
>> .frame0.intro.msg tag add all 1.0 end
>> .frame0.intro.msg configure -state disabled
>>
>> @@ -338,7 +338,7 @@
>> label .frame0.frameDB.left.label \
>> -anchor {n} \
>> -justify right \
>> - -text [G_msg "Path to location: \n(GRASS Database)"]
>> + -text [G_msg "Path to location : "]
>
> "GRASS Database" is a widely used term in the GRASS literature,
> but sure if it should be removed.
>
>
>> entry .frame0.frameDB.mid.entry \
>> -relief {sunken} \
>> @@ -408,7 +408,7 @@
>>
>> label .frame0.frameMS.label \
>> -anchor {w} \
>> - -text [G_msg "Accessible Mapsets"]
>> + -text [G_msg "(Accessible) GIS Mapsets"]
>
> ... this re-reverted the last fix...
> The () do not add information in my opionion.
>
>
>> listbox .frame0.frameMS.listbox \
>> -relief {sunken} \
>> @@ -460,7 +460,7 @@
>>
>> label .frame0.frameNMS.first.label \
>> -anchor {n} \
>> - -text [G_msg "Create new mapset\nin selected location"]
>> + -text [G_msg "Create new GIS mapset\nin currrent location"]
>
> I am also not sure of that. In the beginning nothing is selected,
> so there is no currrent location.
>
>> entry .frame0.frameNMS.second.entry \
>> -relief {sunken} \
>> @@ -495,7 +495,7 @@
>>
>> label .frame0.frameNMS.fourth.label \
>> -anchor {n} \
>> - -text [G_msg "\nDefine new location by:"]
>> + -text [G_msg "Define new projection location"]
>
> ... again confusing (for me).
>
>>
>> button .frame0.frameNMS.fifth.button \
>>
>
> It seems that this needs to be discussed again: at least I
> would like to better understand most of the changes.
>
> thanks
>
> Markus
>
>

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

4

On Jul 17, 2006, at 4:21 PM, Michael Barton wrote:

Markus,

I'm happy to see suggestions. Here is my rational for wording changes. Maybe
there can be better wording than my quick fix.

I'm trying to think of a user who knows something about GIS and is opening
GRASS for the first time. Before she or he can do anything--even start the
program--they have to choose a "database", "location", and "mapset".

But what is a database? Of course everyone knows that a database is an
attribute table or related set of attribute tables defined in a data
dictionary. Except that's not what a GRASS database is. It is simply the
directory/folder where "locations" are stored.

But what is a location? Of course that is a place, maybe where your study
area is located. But how do you select that? Except in GRASS, a "location"
is really a folder with definitions of the projection (including 'geographic
projections' like latlon), coordinate system, and optionally the extents
defining a particular part of the world. More people would probably
understand what we mean if we ask them to choose the projection/coordinate
system than to choose a "location".

Then you have to select a "mapset". But what is a mapset. In GRASS, that's
where your GIS files are stored--which is what this hypothetical new user
has really wanted to get at all along.

Every time I try to explain how to start GRASS, I have to explain what a
"database", "location", and "mapset" is before the person can even get
started working with the program. Any GIS will have some jargon that a
person will have to get through (e.g., 'theme' instead of layer). But it
would be nice to not have to hit someone with GRASS-specific jargon before
they even get the program opened. Of course you can press the help button,
but many people would just like to start the program before doing anything
else.

So I was trying to build in some translations of GRASS jargon to help
someone get started. I dropped "GIS Database" because it's not used much.
But location and mapset are used a lot. Of course this made for some awkward
phraseology, as you noticed. I really did mean "projection location"
instead of project location.

I have been using GRASS for too long for making any suggestion
useful for new users (GIS database, location and mapset has always worked for me)
but I found projection location very confusing for both old users and
potentially for people who may be new to GRASS but know what projection means.

I like project location (I found that people have a quick grasp of location
when I describe it as a project and that you have to select a coordinate system for it)
and mapset people usually get right away.
I don't have an opinion about what to use instead of GIS database, I haven't seen
people complaining about that either.

Maybe "Select an existing 'location' (projection/coordinate system) and GIS
Mapset..."???

there are additional buttons for selection of projection so "project location"
sounds good enough for me

GIS Mapset doesn't sound too awkward to me. But maybe to others?

I think that Mapset is sufficient - there is already GIS in the title.

Suggestions?

I have written this answer before reading a response from Markus - I did not even think
about the problems that would cause the change in the startup with documentation, tutorials,
and description of modules etc. - Markus is right, we should
stick with the terminology that we have unless there is a really compelling
reason to change it - it is not too bad and I found
that people get it pretty quickly (compared e.g. to the region management or the terminology
used in other systems).

Helena

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Mon, 17 Jul 2006 19:35:56 +0200
To: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl,
1.24, 1.25

Hi,

a few questions:

On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote:

Author: michael

Update of /grassrepository/grass6/lib/init
In directory doto:/tmp/cvs-serv30054

Modified Files:
gis_set.tcl
Log Message:
update exec and eval exec statements to properly parse arguments

Index: gis_set.tcl

RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -d -r1.24 -r1.25
--- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24
+++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25
@@ -312,10 +312,10 @@
     pack $introtitle -side top

     .frame0.intro.msg tag configure all -justify center
- .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS Version
$GRASSVERSION\n"]
+ .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS version
$GRASSVERSION\n"]
     .frame0.intro.msg insert end [G_msg "The world's leading open source
GIS\n\n"]
- .frame0.intro.msg insert end [G_msg "Select an existing project location
and mapset\n"]
- .frame0.intro.msg insert end [G_msg "or define a new project
location\n"]
+ .frame0.intro.msg insert end [G_msg "Select an existing projection
location and GIS mapset\n"]

... what does "existing projection location" mean?
I only know "existing project location". The change adds confusion in my
opinion.
If projected is meant, it is not right since latlong (usually) and xy (always)
are
unprojected.

+ .frame0.intro.msg insert end [G_msg "or define a new projection
location\n"]

...also here.

     .frame0.intro.msg tag add all 1.0 end
     .frame0.intro.msg configure -state disabled

@@ -338,7 +338,7 @@
     label .frame0.frameDB.left.label \
-anchor {n} \
-justify right \
- -text [G_msg "Path to location: \n(GRASS Database)"]
+ -text [G_msg "Path to location : "]

"GRASS Database" is a widely used term in the GRASS literature,
but sure if it should be removed.

     entry .frame0.frameDB.mid.entry \
-relief {sunken} \
@@ -408,7 +408,7 @@

     label .frame0.frameMS.label \
-anchor {w} \
- -text [G_msg "Accessible Mapsets"]
+ -text [G_msg "(Accessible) GIS Mapsets"]

... this re-reverted the last fix...
The () do not add information in my opionion.

     listbox .frame0.frameMS.listbox \
-relief {sunken} \
@@ -460,7 +460,7 @@

     label .frame0.frameNMS.first.label \
-anchor {n} \
- -text [G_msg "Create new mapset\nin selected location"]
+ -text [G_msg "Create new GIS mapset\nin currrent location"]

I am also not sure of that. In the beginning nothing is selected,
so there is no currrent location.

     entry .frame0.frameNMS.second.entry \
-relief {sunken} \
@@ -495,7 +495,7 @@

     label .frame0.frameNMS.fourth.label \
-anchor {n} \
- -text [G_msg "\nDefine new location by:"]
+ -text [G_msg "Define new projection location"]

... again confusing (for me).

     button .frame0.frameNMS.fifth.button \

It seems that this needs to be discussed again: at least I
would like to better understand most of the changes.

thanks

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

5

My concern is not with the terminology per se. There is still a considerable
lack of consistency in terminology from one GIS platform to another. GRASS
terminology is a little obtuse, but not excessively so. The concepts are
pretty straightforward once you learn them.

My concern is that the way the startup works, a user must confront and
understand GRASS-specific terms--ones used in no other GIS--before he or she
can even start the program. People I introduce to GRASS always find that a
big stumbling block. This complaint about the startup has come across the
user list regularly too.

Maybe the best solution is to change the startup somehow. However, changing
the way GRASS starts is much more involved than simply changing the language
in the startup screen.

For example, most new users I've talked with indeed take 'location' to mean
project location--as it was originally intended I suspect. Then they are put
off by the need to specify the extents and resolution of their location
before the program will even start. But when I explain that they only REALLY
need to specify the projection parameters (latlon; utm, datum, and zone;
etc.), they have a much easier time of it. What really matters most in a
location is projection information in the WIND and PROJ files, not the
extents and resolution--which can be changed easily during a GRASS session.
But this is not conveyed by the term "location" alone.

Anyway, I was trying to respond to numerous comments about the startup being
confusing to a new but knowledgeable user. The startup screen gives people
their first impression of the program. So whatever goes there should
encourage them to work with the software. I agree that what I stuck in the
new screen should be improved, but also feel that some hand-holding to new
users would be worthwhile.

Cheers,
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Helena Mitasova <hmitaso@unity.ncsu.edu>
Date: Mon, 17 Jul 2006 21:25:46 -0400
To: Michael Barton <michael.barton@asu.edu>
Cc: Markus Neteler <neteler@itc.it>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl,
1.24, 1.25

On Jul 17, 2006, at 4:21 PM, Michael Barton wrote:

Markus,

I'm happy to see suggestions. Here is my rational for wording
changes. Maybe
there can be better wording than my quick fix.

I'm trying to think of a user who knows something about GIS and is
opening
GRASS for the first time. Before she or he can do anything--even
start the
program--they have to choose a "database", "location", and "mapset".

But what is a database? Of course everyone knows that a database is an
attribute table or related set of attribute tables defined in a data
dictionary. Except that's not what a GRASS database is. It is
simply the
directory/folder where "locations" are stored.

But what is a location? Of course that is a place, maybe where your
study
area is located. But how do you select that? Except in GRASS, a
"location"
is really a folder with definitions of the projection (including
'geographic
projections' like latlon), coordinate system, and optionally the
extents
defining a particular part of the world. More people would probably
understand what we mean if we ask them to choose the projection/
coordinate
system than to choose a "location".

Then you have to select a "mapset". But what is a mapset. In GRASS,
that's
where your GIS files are stored--which is what this hypothetical
new user
has really wanted to get at all along.

Every time I try to explain how to start GRASS, I have to explain
what a
"database", "location", and "mapset" is before the person can even get
started working with the program. Any GIS will have some jargon that a
person will have to get through (e.g., 'theme' instead of layer).
But it
would be nice to not have to hit someone with GRASS-specific jargon
before
they even get the program opened. Of course you can press the help
button,
but many people would just like to start the program before doing
anything
else.

So I was trying to build in some translations of GRASS jargon to help
someone get started. I dropped "GIS Database" because it's not used
much.
But location and mapset are used a lot. Of course this made for
some awkward
phraseology, as you noticed. I really did mean "projection location"
instead of project location.

I have been using GRASS for too long for making any suggestion
useful for new users (GIS database, location and mapset has always
worked for me)
but I found projection location very confusing for both old users and
potentially for people who may be new to GRASS but know what
projection means.

I like project location (I found that people have a quick grasp of
location
when I describe it as a project and that you have to select a
coordinate system for it)
and mapset people usually get right away.
I don't have an opinion about what to use instead of GIS database, I
haven't seen
people complaining about that either.

Maybe "Select an existing 'location' (projection/coordinate system)
and GIS
Mapset..."???

there are additional buttons for selection of projection so "project
location"
sounds good enough for me

GIS Mapset doesn't sound too awkward to me. But maybe to others?

I think that Mapset is sufficient - there is already GIS in the title.

Suggestions?

I have written this answer before reading a response from Markus - I
did not even think
about the problems that would cause the change in the startup with
documentation, tutorials,
and description of modules etc. - Markus is right, we should
stick with the terminology that we have unless there is a really
compelling
reason to change it - it is not too bad and I found
that people get it pretty quickly (compared e.g. to the region
management or the terminology
used in other systems).

Helena

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Mon, 17 Jul 2006 19:35:56 +0200
To: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init
gis_set.tcl,
1.24, 1.25

Hi,

a few questions:

On Mon, Jul 17, 2006 at 07:28:42PM +0200, grass@intevation.de wrote:

Author: michael

Update of /grassrepository/grass6/lib/init
In directory doto:/tmp/cvs-serv30054

Modified Files:
gis_set.tcl
Log Message:
update exec and eval exec statements to properly parse arguments

Index: gis_set.tcl

RCS file: /grassrepository/grass6/lib/init/gis_set.tcl,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -d -r1.24 -r1.25
--- gis_set.tcl 24 Jun 2006 19:33:59 -0000 1.24
+++ gis_set.tcl 17 Jul 2006 17:28:40 -0000 1.25
@@ -312,10 +312,10 @@
     pack $introtitle -side top

     .frame0.intro.msg tag configure all -justify center
- .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS
Version
$GRASSVERSION\n"]
+ .frame0.intro.msg insert end [G_msg "Welcome to GRASS GIS
version
$GRASSVERSION\n"]
     .frame0.intro.msg insert end [G_msg "The world's leading
open source
GIS\n\n"]
- .frame0.intro.msg insert end [G_msg "Select an existing
project location
and mapset\n"]
- .frame0.intro.msg insert end [G_msg "or define a new project
location\n"]
+ .frame0.intro.msg insert end [G_msg "Select an existing
projection
location and GIS mapset\n"]

... what does "existing projection location" mean?
I only know "existing project location". The change adds confusion
in my
opinion.
If projected is meant, it is not right since latlong (usually) and
xy (always)
are
unprojected.

+ .frame0.intro.msg insert end [G_msg "or define a new projection
location\n"]

...also here.

     .frame0.intro.msg tag add all 1.0 end
     .frame0.intro.msg configure -state disabled

@@ -338,7 +338,7 @@
     label .frame0.frameDB.left.label \
-anchor {n} \
-justify right \
- -text [G_msg "Path to location: \n(GRASS Database)"]
+ -text [G_msg "Path to location : "]

"GRASS Database" is a widely used term in the GRASS literature,
but sure if it should be removed.

     entry .frame0.frameDB.mid.entry \
-relief {sunken} \
@@ -408,7 +408,7 @@

     label .frame0.frameMS.label \
-anchor {w} \
- -text [G_msg "Accessible Mapsets"]
+ -text [G_msg "(Accessible) GIS Mapsets"]

... this re-reverted the last fix...
The () do not add information in my opionion.

     listbox .frame0.frameMS.listbox \
-relief {sunken} \
@@ -460,7 +460,7 @@

     label .frame0.frameNMS.first.label \
-anchor {n} \
- -text [G_msg "Create new mapset\nin selected location"]
+ -text [G_msg "Create new GIS mapset\nin currrent location"]

I am also not sure of that. In the beginning nothing is selected,
so there is no currrent location.

     entry .frame0.frameNMS.second.entry \
-relief {sunken} \
@@ -495,7 +495,7 @@

     label .frame0.frameNMS.fourth.label \
-anchor {n} \
- -text [G_msg "\nDefine new location by:"]
+ -text [G_msg "Define new projection location"]

... again confusing (for me).

     button .frame0.frameNMS.fifth.button \

It seems that this needs to be discussed again: at least I
would like to better understand most of the changes.

thanks

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

6

Michael Barton wrote:

Anyway, I was trying to respond to numerous comments about the startup being
confusing to a new but knowledgeable user. The startup screen gives people
their first impression of the program. So whatever goes there should
encourage them to work with the software. I agree that what I stuck in the
new screen should be improved, but also feel that some hand-holding to new
users would be worthwhile.

I agree with Markus and Helena that the terminology should stay as it is.
I actually don't think that it is the terminology that makes the start-up difficult for users, it is the fact that they actually have to think about projection and extent when many just want to open a file they received for which they know neither...

What about keeping the original terms with some pop-up help at mouse-over explaining what the term means ?

Moritz

7

Michael Barton wrote:

My concern is not with the terminology per se. There is still a considerable
lack of consistency in terminology from one GIS platform to another. GRASS
terminology is a little obtuse, but not excessively so. The concepts are
pretty straightforward once you learn them.

My concern is that the way the startup works, a user must confront and
understand GRASS-specific terms--ones used in no other GIS--before he or she
can even start the program. People I introduce to GRASS always find that a
big stumbling block. This complaint about the startup has come across the
user list regularly too.

Maybe the best solution is to change the startup somehow. However, changing
the way GRASS starts is much more involved than simply changing the language
in the startup screen.

For example, most new users I've talked with indeed take 'location' to mean
project location--as it was originally intended I suspect. Then they are put
off by the need to specify the extents and resolution of their location
before the program will even start. But when I explain that they only REALLY
need to specify the projection parameters (latlon; utm, datum, and zone;
etc.), they have a much easier time of it. What really matters most in a
location is projection information in the WIND and PROJ files, not the
extents and resolution--which can be changed easily during a GRASS session.
But this is not conveyed by the term "location" alone.

Anyway, I was trying to respond to numerous comments about the startup being
confusing to a new but knowledgeable user. The startup screen gives people
their first impression of the program. So whatever goes there should
encourage them to work with the software. I agree that what I stuck in the
new screen should be improved, but also feel that some hand-holding to new
users would be worthwhile.

I'm not so sure.

I don't believe that GRASS will ever be the kind of package which can
be used without reading any documentation, and I don't consider this
to be a defect.

A user isn't going to be able to do anything useful with GRASS without
having first read some documentation, so it doesn't really matter
whether they have to read the documentation before they get to the
startup screen or afterwards.

If a user is looking for a simple package which they can use without
reading any documentation, it's probably better if they realise sooner
rather than later that GRASS isn't such a package.

E.g. if they aren't familiar with the notion of the current region,
making the startup screen simpler is just going to trade "what do I
type here?" queries for "why do I get a blank screen from d.rast?"
queries.

[And the latter are frequently answered with the (bogus) advice of:
use "g.region rast=..." to move the region to the map, when they
should be using r.region to move the map.]

--
Glynn Clements <glynn@gclements.plus.com>

8

On Tue, 2006-07-18 at 09:15 +0200, Moritz Lennert wrote:

Michael Barton wrote:

> Anyway, I was trying to respond to numerous comments about the startup being
> confusing to a new but knowledgeable user. The startup screen gives people
> their first impression of the program. So whatever goes there should
> encourage them to work with the software. I agree that what I stuck in the
> new screen should be improved, but also feel that some hand-holding to new
> users would be worthwhile.

I agree with Markus and Helena that the terminology should stay as it is.
I actually don't think that it is the terminology that makes the
start-up difficult for users, it is the fact that they actually have to
think about projection and extent when many just want to open a file
they received for which they know neither...

What about keeping the original terms with some pop-up help at
mouse-over explaining what the term means ?

And/or some script-based help that can provide some guidance, such as
"this looks like a GIS file associated with the US Census TIGER
database. If this is correct, your projection is likely $PROJ and your
extent is likely $EXTENT. Should I use those values?" Or, "this looks
like a GIS file associated with a Magellan GPS device. If this is
correct..."

I believe that there are a few simple use cases--electronic versions of
USGS maps, GPS reference data, etc--that cover literally millions of
intelligent, but not sophisticated, users. These users don't
necessarily need toolbar help in figuring out which band of LANDSAT data
they want to overlay, but they do want to map demographic or geocache
data, and it would be HUGE if GRASS made it as easy as possible to be
successful in those two use cases.

M

M

9

Glynn,

I appreciate tremendously all the great work you have been doing for
GRASS, except on one point...

On Tue, 2006-07-18 at 08:25 +0100, Glynn Clements wrote:

Michael Barton wrote:

> My concern is not with the terminology per se. There is still a considerable
> lack of consistency in terminology from one GIS platform to another. GRASS
> terminology is a little obtuse, but not excessively so. The concepts are
> pretty straightforward once you learn them.

I fundamentally agree with Michael here.

> My concern is that the way the startup works, a user must confront and
> understand GRASS-specific terms--ones used in no other GIS--before he or she
> can even start the program. People I introduce to GRASS always find that a
> big stumbling block. This complaint about the startup has come across the
> user list regularly too.

I find this everywhere I travel, and even find myself stumbling on the
problem. I don't use GRASS every day, but I want to be able to use it
every now and again without feeling lost and baffled. When I use it for
a weekend, I think to myself "hey, I've got it! Now I'm not going to
forget it." Three months later, I've forgotten it. This is not only
frustrating to me, but makes it very difficult for me to be a GRASS
ambassador to other business people who would benefit tremendously from
being able to map their business data and ideas to geographic reference
points or regions.

So here is where I disagree with you:

I'm not so sure.

I don't believe that GRASS will ever be the kind of package which can
be used without reading any documentation, and I don't consider this
to be a defect.

Would you be willing to maintain that opinion as part of a silent
minority?

A user isn't going to be able to do anything useful with GRASS without
having first read some documentation, so it doesn't really matter
whether they have to read the documentation before they get to the
startup screen or afterwards.

I know a lot of people who are far more motivated to read documentation
when they have evidence that they really are this >< close to attacking
their real problem. If they have to read a lot of documentation before
getting a map loaded, it requires them to believe (1) they can find the
map they need, (2) they can get it loaded, (3) they can do the analysis
they want. That's a lot of doubt to carry while reading documentation.

Here's an example. I have a theory that US democracy (as I define it)
is weakened (as I define it) when US congressional districts are redrawn
(as required by the US constitution) to be less, rather than more,
convex (which is left to the courts and the incumbent representatives in
charge of drawing the maps). To test this theory, I need to look at
congressional district maps and find which ones are becoming less and
less convex over time. I have no idea how to do this, but I can start
attacking the problem by selecting stories I believe correlate to
"stronger" or "weaker" democratic activity and attribute that to the
relevant districts, then I can see whether such attribution shows a
visual correlation. If I start to see a correlation, I can learn how to
order districts based on convexity and then actively search for
validating or repudiating evidence of the theory.

To get going, I type into Google "us congressional district map" and two
clicks later I'm at http://nationalatlas.gov/atlasftp.html#cgd109p .
Now, with GRASS as it is, I'm pretty sure I have the right map
somewhere, but I not at all sure I can begin my demographic analysis of
democracy. I don't know if GRASS supports these formats. I don't know
whether I can load these things correctly. I don't know what kind of
processing I need to do to load or begin working on these maps. If
GRASS lowered the barrier to all these issues, I'd be much more likely
to engage the documentation to solve my problem at hand. As it is, I
feel I need to do a lot of work, on an uncertain foundation, just to get
to square one. I am sure that many people feel this way.

If a user is looking for a simple package which they can use without
reading any documentation, it's probably better if they realise sooner
rather than later that GRASS isn't such a package.

I believe that GRASS /can/ be such a package, or can be the basis of
such a package (such as QGIS). But don't if we keep convincing
ourselves that GIS should be left to the experts.

M

10

... what does "existing projection location" mean?

my overspent 2c re. startup GUI wording:

"database". This one should change in the GUI startup screen now that
the vector engine talks to "real" databases. I like simple two words:
"data path:" for the GUI's database needs. g.gisenv and internally can
still use "database" without harm, although r.proj et al. will refer to
it, the help pages can provide the meaning.

r.proj:
    dbase Path to GRASS database of input location

shrug. At first I thought this was easy to understand, on second reading
I'm not so sure.

"location" is a bit ??? at first glance, but I still haven't heard
anything I like better. It is not confusing once you know what it refers
to, albeit somewhat non-intuitive at first.

Michael:

Maybe "Select an existing 'location' (projection/coordinate system)

This sounds ok to me, but note you can have multiple locations which
use the same projection. (e.g. ll_world, ll_canada) The common
projection is a feature of a location, but not its only quality.

Markus:

"project location" would be even ok

but then it could be read like "location of project on the hard drive"
when it is intended to refer to geo-location ??? or maybe "geo-location"
is better reserved for a mapset name, refering to an area somewhere
within the projection's domain.

"mapset" is relatively clear; don't clutter it with "GIS mapset" ("GIS"
is redundant) or "available mapsets" (what are the unavailable ones?!)

maybe make more use of the filing cabinet, drawer, and folder analogy.

Michael:

but also feel that some hand-holding to new users would be worthwhile.

sure. the idea is to be both easy/quick to understand and exact in
meaning. A hard task in practice.

Glynn:

A user isn't going to be able to do anything useful with GRASS without
having first read some documentation, so it doesn't really matter
whether they have to read the documentation before they get to the
startup screen or afterwards.

In order to get a new user hooked (or at least not give up after hours
of frustration with nothing to show for it), the startup -> "first
light" of a map steps are crucial to get in the first 10-20 minutes of
use.

People are egotistical by nature. They'll either figure the software is
broken or that they aren't as smart as they thought they were. Both may
or may not be true, but neither is anything close to a productive way to
sell your product. They need to keep using the software long enough to
see the power and options available to them at which point they will
sell it to themselves. A cryptic brick wall that asks them to press
<esc><enter> for unknown reasons doesn't help.

solution: tooltips (paragraphs!) on the startup screen so they can
stumble past that, do a good job on the new GUI, pump the tutorials like
mad, and gratuitously link to the help pages.

Glynn:

[And the latter are frequently answered with the (bogus) advice of:
use "g.region rast=..." to move the region to the map, when they
should be using r.region to move the map.]

a) that assumes typical import data is unprojected, and b) you still
run into the "g.region rast=" problem 5 minutes later.

It is possible to be both beginner-friendly and not have to dumb
everything down until it is useless. I think we are lucky to be fighting
to make something powerful easy to use, rather than fighting to make
something easy to use useful for something beyond the most simple tasks.

Hamish

11

I agree with this. This is why the wording turned out awkward. It would be
much easier to just come up with more generic descriptions of what is needed
to start the program, but it is important to maintain the link with existing
terminology. And the terminology is not bad--better than the terminology in
some other programs, IMHO. It's just that it is specific to GRASS only and
must be faced to simply start the program.

So maybe a better idea is to keep the GRASS terminology and offer a brief
definition rather than to create a hybrid like I did. What about something
along the lines of...

Select GIS database
(directory containing GRASS data)

Select location
(projection and optional geographic extents)

Select mapset
(GIS files)

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Mon, 17 Jul 2006 22:43:15 +0200
To: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl,
1.24, 1.25

I just want to avoid that we break with the existing wealth of documentation
and also a bit with tradition (we have many long term users who even took a
while to switch to GRASS 5 or GRASS 6). It is already quite hard to keep
presentations reasonably updated, but for tutorials (there are many) and books
it is even worse.

Well, let's hear the others. It's worth to get this discussed.

Markus

12

I agree!

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 19 Jul 2006 02:10:44 +1200
To: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl,
1.24, 1.25

... what does "existing projection location" mean?

my overspent 2c re. startup GUI wording:

"database". This one should change in the GUI startup screen now that
the vector engine talks to "real" databases. I like simple two words:
"data path:" for the GUI's database needs. g.gisenv and internally can
still use "database" without harm, although r.proj et al. will refer to
it, the help pages can provide the meaning.

r.proj:
    dbase Path to GRASS database of input location

shrug. At first I thought this was easy to understand, on second reading
I'm not so sure.

"location" is a bit ??? at first glance, but I still haven't heard
anything I like better. It is not confusing once you know what it refers
to, albeit somewhat non-intuitive at first.

Michael:

Maybe "Select an existing 'location' (projection/coordinate system)

This sounds ok to me, but note you can have multiple locations which
use the same projection. (e.g. ll_world, ll_canada) The common
projection is a feature of a location, but not its only quality.

Markus:

"project location" would be even ok

but then it could be read like "location of project on the hard drive"
when it is intended to refer to geo-location ??? or maybe "geo-location"
is better reserved for a mapset name, refering to an area somewhere
within the projection's domain.

"mapset" is relatively clear; don't clutter it with "GIS mapset" ("GIS"
is redundant) or "available mapsets" (what are the unavailable ones?!)

maybe make more use of the filing cabinet, drawer, and folder analogy.

Michael:

but also feel that some hand-holding to new users would be worthwhile.

sure. the idea is to be both easy/quick to understand and exact in
meaning. A hard task in practice.

Glynn:

A user isn't going to be able to do anything useful with GRASS without
having first read some documentation, so it doesn't really matter
whether they have to read the documentation before they get to the
startup screen or afterwards.

In order to get a new user hooked (or at least not give up after hours
of frustration with nothing to show for it), the startup -> "first
light" of a map steps are crucial to get in the first 10-20 minutes of
use.

People are egotistical by nature. They'll either figure the software is
broken or that they aren't as smart as they thought they were. Both may
or may not be true, but neither is anything close to a productive way to
sell your product. They need to keep using the software long enough to
see the power and options available to them at which point they will
sell it to themselves. A cryptic brick wall that asks them to press
<esc><enter> for unknown reasons doesn't help.

solution: tooltips (paragraphs!) on the startup screen so they can
stumble past that, do a good job on the new GUI, pump the tutorials like
mad, and gratuitously link to the help pages.

Glynn:

[And the latter are frequently answered with the (bogus) advice of:
use "g.region rast=..." to move the region to the map, when they
should be using r.region to move the map.]

a) that assumes typical import data is unprojected, and b) you still
run into the "g.region rast=" problem 5 minutes later.

It is possible to be both beginner-friendly and not have to dumb
everything down until it is useless. I think we are lucky to be fighting
to make something powerful easy to use, rather than fighting to make
something easy to use useful for something beyond the most simple tasks.

Hamish