Location and Mapsets

A LOCATION is some geographic extent of interest that contains data sets that must all be in the same coordinate system. Every location has a PERMANENT directory which stores some basic information about the whole location, and is a good place to park base files. You can think of a location as a data library for a region of interest.

In a MAPSET you can organize GIS maps thematically or geographically or by project or whatever. Every GRASS session runs under the name of a MAPSET. A MAPSET may be a geographical subset or as large as the parent LOCATION. Technically they are subdirectories under any location. In a networked environment with several users working within the same location, mapsets play a special role. Users may only select (and thus modify) a mapset that they own (i.e., have created). However, data in all mapsets for a given location can be read by anyone (unless prevented by UNIX file permissions). The "PERMANENT" mapset usually contains the read-only base maps like the elevation model, while the other locations are readable and writable by their owners. The "PERMANENT" mapset also contains some information about the location itself that is not found in other mapsets (projection info etc.), thus it must exist in every location.

GRASS' logical database structure (one projection definition per LOCATION) avoids problems such as the ones introduced with the "on-the-fly" reprojection ability (typically problems caused by mixed datums) which is present in most GISes.

In depth explanations

In order to select a mapset as the current mapset (where newly created maps are stored), the user must be the owner of the mapset directory. Write permission of the directory is not sufficient.

A user can access maps in any mapset of the location for which s/he has the necessary permissions, i.e. read permission on files, read and execute permissions on directories.

Maps in a mapset other than the current mapset can be accessed using the map@mapset syntax, or by adding the other mapset(s) to the mapset search path using g.mapsets.

If you want to "take over" an existing location or mapset from a different user, you can change the owner with "chown" if you have root access. If you don't have root access but have write permission on the directory and all subdirectories, you can create a copy (which you will own) then delete the original and rename the copy.

If you have write permission on the mapset directory but lack write permission on any non-empty subdirectories, you can still make a copy (and rename both the original and the copy) but you will not be able to delete the original directory.

Rationale:

One of the main reasons why GRASS implements the ownership check is to prevent users from trying to create group-writable mapsets and encountering this situation.

In GRASS GIS 7 versions, the ownership check can be suppressed by setting one of the specific environmental variables, but this is only intended as workaround for single-user systems with "foreign" filesystems (e.g. FAT, shared directory between virtual machine and hosting computer) which don't have ownership information. It is not safe on a multi-user system.

If you are on a single user environment and you need to suppressed ownership check, you might want to put the setting of the variable to your ~/.profile, ~/.bashrc, ~/.pam_enviroment or whatever is the right way of setting variables session-wide on your system.

Best practice examples

Here some examples:

• A method is to make each LOCATION = a coordinate reference system, then use MAPSETs therein to hold all layers for some project.

Variation for teams:

• The /grassdata/ directory is on a shared network drive (e.g. NFS).
• LOCATIONs are named to reflect their coordinate reference system (latlong_wgs84, or utm32n, or ...)
• the MAPSET names are usually
  • project names, or
  • user surnames (= mapset owner, so they have their personal playground), or
  • dataset names in case of larger datasets (e.g. MODIS or ECAD time series with > 10,000 maps)

See also

• GRASS Location Wizard
• Computational region