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

Michael Barton Michael.Barton at asu.edu
Thu Jan 22 09:16:40 PST 2015

For this release, we need to focus on just tweaking the current startup screen and doing better graphics for the splash. The other topic is a much bigger issue.

The reasons that GRASS just can’t open and then load a file like a word processor are multiple and related. Foremost is the underlying structure of the geospatial data that GRASS uses. The GISDBASE/location/mapset structure organizes the location and the format of the data.

A word processor like LibreOffice can open a file from anywhere, in any format that it can read, modify it, and save it to anywhere the computer user has access to. A GRASS user can ONLY open GIS data from a mapset within the current location within the current database. A GIS file modified or created can ONLY be saved within the current mapset. A non-GRASS GIS file can be imported into the current mapset, but ONLY if it has the same projection as the current location. Any GRASS user must encounter these interactions of file location, format, and projection before using GIS data. So allowing a user to start the program before facing this only kicks the can down the road a short distance.

QGIS uses shapefiles and (IIRC) geotiffs for its GIS data. These are pretty portable and can be stored anywhere, and include projection information with them (or they should). Arc is more like GRASS. I’m not sure about the current version, but in prior versions at least, you could not even move Arc directories without messing up the program’s ability to read the data correctly.

Both QGIS and Arc get around the problem of opening files in different formats and projections by doing approximate reprojection on the fly. For a lot of very good reasons, the GRASS developer community has repeatedly decided that this is not a good idea for GRASS because of its potential for geospatial error and for users to misunderstand the approximate nature of the automatic reprojection.

So we are back to the database/location/mapset organization. Unless we make some fundamental changes in how GRASS works, users MUST open GRASS in a database/location/mapset. They MUST choose (or have chosen for them) a projection (location) and working directory (mapset). Making a default one for them (e.g., a latlon default) doesn’t help all that much it seems to me.

Perhaps an alternative is to change the names somewhat so that users are informed about what is really needed to start GRASS.

1. pick a projection (not a location)
2. pick a working directory (not a mapset)

To really implement this more easily, we might want to consider de-coupling these fundamentals (especially projection) from the file structure. In other words, we could get rid of “location” as a directory that has a PERMANENT mapset with files for projection and extent, and keep this information elsewhere. Then we could more easily have working directories (currently called mapsets) in any location on the computer. This could make it easier to get people started and still maintain the geospatial integrity that GRASS is known for.

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 22, 2015, at 8:27 AM, Anna Petrášová <kratochanna at gmail.com<mailto:kratochanna at gmail.com>> wrote:

On Thu, Jan 22, 2015 at 9:41 AM, Martin Landa <landa.martin at gmail.com<mailto:landa.martin at gmail.com>> wrote:

2015-01-22 9:48 GMT+01:00 Markus Metz <markus.metz.giswork at gmail.com<mailto:markus.metz.giswork at gmail.com>>:
> A suggestion for a compromise:
> Have a minimal welcome screen that says something like
> "Starting GRASS GIS in location X, mapset Y"
> nothing else, no list of all the available locations and mapsets
> Only two buttons: OK, Change
> Make OK the default, Change will bring up the current welcome screen.
> The user has then just to hit enter and GRASS is running. This would
> reduce the (confusing) amount of information on the current welcome
> screen. It would also give more space for a little graphic ;-)
> Location and mapset can be taken from GISRC, if that does not exist,
> create a new GISDBASE in the user's home, put the demolocation in it
> and use this (I think the wingrass installer is already doing that).

it make sense to me, I really like this idea. Martin

I am not particularly fond of this idea, I change location and mapset quite often, so this is additional step. I agree GISDBASE and the demolocation should be already there during the first start. Then the user can just hits Start GRASS on the current welcome dialog and there is no need for the minimal welcome screen. It works like this for Windows already. It creates grassdata in My Documents if I remember correctly, I am not sure why not in home.

What I struggle with when explaining students how to use GRASS is not really the welcome screen but reprojecting data. If we would find a way to automatically reproject data during import, that would save a lot of work and explanation and it's useful not just for beginners. This is a topic for a different thread, how exactly it should be implemented. No matter what we decide to do with the starting of grass, this should be implemented. Especially when user will start with empty location, they will want to import their data and then the reprojection is crucial. I saw a lot of cases when they just override the projection check to overcome the error they get and don't read.

Any opinion on what can we do for this release?


Martin Landa
grass-dev mailing list
grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150122/79bc4b72/attachment-0001.html>

More information about the grass-dev mailing list