Location and Mapsets - Revision history

Neteler: remove hardcoded version specific urls, use latest version

2018-12-04T10:15:14Z

remove hardcoded version specific urls, use latest version

← Older revision		Revision as of 10:15, 4 December 2018
Line 23:		Line 23:
	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.		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 {{cmd\|variables~~\|version=70~~}}, 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.		In GRASS GIS 7 versions, the ownership check can be suppressed by setting one of the specific environmental {{cmd\|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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> or whatever is the right way of setting variables session-wide on your 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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> or whatever is the right way of setting variables session-wide on your system.

Neteler: /* Variation for teams */

2016-06-10T16:21:57Z

Variation for teams

← Older revision		Revision as of 16:21, 10 June 2016
Line 74:		Line 74:

	=== Variation for '''teams''' ===		=== Variation for '''teams''' ===
			* The GRASS GIS software is installed in a network folder. It comes right away with multi-user support.
	* The /grassdata/ directory is on a shared network drive (e.g. NFS).		* 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 ...)		* LOCATIONs are named to reflect their coordinate reference system (''latlong_wgs84'', or ''utm32n'', or ...)

Neteler: /* Using GRASS GIS locations in a network */

2016-06-10T16:20:33Z

Using GRASS GIS locations in a network

← Older revision		Revision as of 16:20, 10 June 2016
Line 81:		Line 81:
	** ''dataset names'' in case of larger datasets (e.g. MODIS or ECAD time series with > 10,000 maps)		** ''dataset names'' in case of larger datasets (e.g. MODIS or ECAD time series with > 10,000 maps)

	=== Using GRASS GIS locations in a network ===		=== Multiuser support: Using GRASS GIS locations in a network ===

	'''''Q:''' I am trying to figure out the best way to allow students to work on high resolution imagery in computer labs where their own local computers/sessions are limited in terms of disk space and where the file server is normally read-only for students.''		'''''Q:''' I am trying to figure out the best way to allow students to work on high resolution imagery in computer labs where their own local computers/sessions are limited in terms of disk space and where the file server is normally read-only for students.''

Neteler: + Restrictions to the location/mapset names: https://lists.osgeo.org/pipermail/grass-user/2015-November/073382.html

2015-12-01T10:11:01Z

+ Restrictions to the location/mapset names: https://lists.osgeo.org/pipermail/grass-user/2015-November/073382.html

← Older revision		Revision as of 10:11, 1 December 2015
Line 26:		Line 26:

	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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> or whatever is the right way of setting variables session-wide on your 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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> or whatever is the right way of setting variables session-wide on your system.

			== Restrictions to the location/mapset names ==

			They may not contain any of the characters:

			/ " ' @ , = *

			or space, DEL (code 127/0x7F), any control character or any 8-bit character ([https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/legal_name.c source]).

			Also, because map, mapset and location names are used directly as file and/or directory names, they may not contain any character which is prohibited in a filename by the underlying OS. On Windows, this includes:

			\ / : * ? " < > \|

			(source: try entering any of these characters when renaming a file or directory on Windows.)

			The OS may also impose other restrictions (e.g. you typically can't have a file or directory named "." or ".." although the "." character isn't itself prohibited).

			=== Mapset name related user questions ===

			'''Q:''' I just found out that if you use a numeric mapset (e.g. 2014_123) you have to use single quotes in mapcalc expressions.

			'''A:''' Which names are legal and which names can be used in {{cmd\|r.mapcalc}} without quoting are different. E.g. a "-" character (minus, hyphen, dash) is legal in a map, mapset or location name, but r.mapcalc requires the name to be quoted, otherwise it will be interpreted as a subtraction.

			'''Q:''' ... e.g the following example will raise an error:

			r.mapcalc expression="foo=R1@2014_123"

			results in:

			Syntax error, unexpected INTEGER, expecting VARNAME or NAME

			'''A:''' An unquoted name consists of a sequence of characters other than space, control characters, or any of:

			^ # @ , " ' ( ) [ ] + - * / % > < ! = & \| ? : ; ~

			([https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/mapcalc.l#L97 source]:, definition of "N" (line 97) in r.mapcalc.l]

			''However'': it may not have a prefix which is a valid integer or floating-point literal (which is why your example above generates an error), as those take precedence over names.

			A quoted name can contain any character other than the quote character itself. Note that quoted names aren't always maps (or mapsets or locations); they can also be used for variables if you feel you have to use a name which isn't valid as an unquoted name.

	== Best practice examples ==		== Best practice examples ==

Neteler: +Permission management

2014-12-12T11:40:19Z

+Permission management

@@ Line 50: / Line 50: @@
 * Clients: Linux, Windows, whatever
-'''Server setup:'''
+==== Server setup ====
 * Put the data on e.g. <tt>/storage/grassdata/<various locations here/></tt>
 * export the directory tree <tt>/storage/grassdata/</tt> as read-only NFS share
 * Remember to put all data into the PERMANENT mapset.
-'''Student machine(s):'''
+==== Student machine(s) ====
 * as sysadmin (root) user, add to /etc/fstab (only one time needed):
    mkdir -p /storage/grassdata/
@@ Line 67: / Line 67: @@
 *** Check http://en.wikipedia.org/wiki/NTFS_reparse_point and http://en.wikipedia.org/wiki/NTFS_symbolic_link
-'''Usage:'''
+==== Permission management ====
 Now start GRASS with $USER/grassdata/ and location1 and create a new user mapset within it.

Neteler at 15:59, 8 November 2014

2014-11-08T15:59:54Z

← Older revision		Revision as of 15:59, 8 November 2014
Line 59:		Line 59:
	mkdir -p /storage/grassdata/		mkdir -p /storage/grassdata/
	mount via NFS /storage/grassdata/ into /storage/grassdata/		mount via NFS /storage/grassdata/ into /storage/grassdata/
	* for each user (Linux/Unix example):		* for each user
			** Linux/Unix example:
	mkdir $USER/grassdata		mkdir $USER/grassdata
	mkdir $USER/grassdata/location1		mkdir $USER/grassdata/location1
	ln -s /storage/grassdata//location1/PERMANENT $USER/grassdata/location1/		ln -s /storage/grassdata//location1/PERMANENT $USER/grassdata/location1/
			** Windows example
			*** Check http://en.wikipedia.org/wiki/NTFS_reparse_point and http://en.wikipedia.org/wiki/NTFS_symbolic_link

	'''Usage:'''		'''Usage:'''

Neteler: Using GRASS GIS locations in a network

2014-11-08T15:57:02Z

Using GRASS GIS locations in a network

@@ Line 33: / Line 33: @@
 * 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''':
+=== 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 ...)
@@ Line 40: / Line 40: @@
 ** 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 ==

Neteler at 20:13, 27 April 2014

2014-04-27T20:13:47Z

← Older revision		Revision as of 20:13, 27 April 2014
Line 1:		Line 1:
			__TOC__

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

Line 5:		Line 7:
	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.		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 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.		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.
Line 25:		Line 27:
	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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> or whatever is the right way of setting variables session-wide on your 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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> or whatever is the right way of setting variables session-wide on your system.

	=== Best practice examples ===		== Best practice examples ==

	Here some examples:		Here some examples:
Line 39:		Line 41:
	** ''dataset names'' in case of larger datasets (e.g. MODIS or ECAD time series with > 10,000 maps)		** ''dataset names'' in case of larger datasets (e.g. MODIS or ECAD time series with > 10,000 maps)

	=== See also ===		== See also ==

	* [[GRASS Location Wizard]]		* [[GRASS Location Wizard]]

Neteler: +Best practice examples

2014-04-27T20:12:20Z

+Best practice examples

← Older revision		Revision as of 20:12, 27 April 2014
Line 24:		Line 24:

	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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> or whatever is the right way of setting variables session-wide on your 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 <tt>~/.profile</tt>, <tt>~/.bashrc</tt>, <tt>~/.pam_enviroment</tt> 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 ===		=== See also ===

Neteler: +Computational region link

2013-12-22T12:24:13Z

+Computational region link

← Older revision		Revision as of 12:24, 22 December 2013
Line 28:		Line 28:

	* [[GRASS Location Wizard]]		* [[GRASS Location Wizard]]
			* [[Computational region]]

	[[Category:FAQ]]		[[Category:FAQ]]