[GRASS-dev] Making start of GRASS GIS easier for newcomers

Blumentrath, Stefan Stefan.Blumentrath at nina.no
Fri Jan 30 12:20:17 PST 2015

Dear all,

I would like to support Michael`s and Nikos`s suggestions for changes in the descriptions on the welcome screen in trunk, as I think careful and well-thought-out wording will be an important means of "Making start of GRASS GIS easier for newcomers".

On courses here at the University of Oslo, I saw people creating a new gisdbase folder - in anticipatory obedience - at the beginning of the second day of the course, because it was the first thing we did on the first day. Shortly after they wondered how they can access the data from the first day... Saying something like "There can be more than one or more directories like that on one machine" is technically true but does probably not reflect the concept of the GRASS GIS database... 
Furthermore, if that folder is predefined, people may be less tempted to create several gisdatabase folder on their computer.
One might even go one step further saying:

"The GRASS GIS database directory is the central place where all your GRASS GIS data will be stored/organized. Change the folder only for a good reason."
Also greying out the path (and not having it as an input field), as proposed by others earlier, could be a good idea.

As for the Location description, what about:
"A Location in GRASS is defined by a Coordinate Reference System. It is a subdirectory of the gisdatabase containing one or more collections of spatial data ("Mapsets"), which all share the Location`s CRS."
I also like this statement from the wiki: "You can think of a location as a data library for a region of interest."

For mapsets I do like Nikos proposal. And alike Michael I tend to compare mapsets with projects (and not Locations). In fact creating a location for every project would be counterproductive cause it would lead to fragmentation and data duplication... 

Markus, from your experience from your courses, are there explanations which usually work particularly well for newbies and people coming from other GIS?

Kind regards,

-----Original Message-----
From: grass-dev-bounces at lists.osgeo.org [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Nikos Alexandris
Sent: 29. januar 2015 18:13
To: Moritz Lennert
Cc: Michael Barton; GRASS developers grass-developers
Subject: Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 29.01.2015 18:49, Moritz Lennert wrote:

>> ### Mapset
>> "A Mapset contains GIS data. Every Location automatically has one 
>> Mapset named PERMANENT that also contains projection information for 
>> the Location."
> Maybe add a little about use of mapsets:
> "A Mapset is a subdirectory of a location and contains GIS data.
> Mapsets are used to organise the data into coherent subsets (by 
> project, user, or other systems). Every Location automatically has one 
> Mapset named PERMANENT that also contains projection information for 
> the Location."

Proposing slightly different wording:

"A Mapset is a subdirectory inside a Location and contains geospatial data. Mapsets are useful in organising the data into coherent subsets (by project, user, or other thematic units)."

> If we don't have enough space, I'd just drop the last sentence about 
> the PERMANENT mapset.
> [Looking at this I actually makes me think about the real need for 
> 'PERMANENT'. Couldn't the location-relevant files just be stored in 
> (possible hidden files directly in the location directory ? Or do we 
> want to keep the notion of permanent data vs modifiable data for 
> educational purpose ? Then again, I don't really want to open 
> Pandora's box at this stage of the release process... ;-) ]

Using the PERMANENT Mapset as a safety-pool, for all of the "raw" data, isn't a bad idea as well. Copy then elsewhere and play along.  I do it most of the times.  It saves time to re-import stuff, for example, if a map is irreversibly modified.  Which is a matter of time to happen (and not a question of "will it happen?").  At the end of a project's life-cycle, stuff can be cleaned.

grass-dev mailing list
grass-dev at lists.osgeo.org

More information about the grass-dev mailing list