grassdata
in their home directory.
In multi-user environment users often have a grassdata
directory
mounted as a network directory (network file system).
For teams, a centralized GRASS DATABASE would be defined
in a shared network file system (e.g. NFS).
GRASS GIS Databases can be safely copied or moved as any other directories. Don't be confused with (relational) databases which are used in GRASS GIS to hold attribute data and might be part of the GRASS GIS Database. From user point of view, GRASS GIS Database with all its data in it is similar to, e.g. PostGIS, database, as it stores all information inside in a specific format and is accessible by specific tools. GRASS GIS Databases is in GRASS GIS often called GISDBASE or DATABASE.
GRASS Locations can be safely copied or moved as any other directories. Compressed Location is usually what GRASS users exchange between each other when they want to share a lot of data. For example, GRASS GIS sample data are provided as Locations.
Don't be confused with location as a place (file or directory) in a file system. The word location in GRASS Location refers to a location or area on Earth (or whatever is applicable). Users and programmers familiar with relational databases such as PostgreSQL can view Location as an individual database inside the system or a storage area which would be equivalent to GRASS GIS Database. Mapsets in a Locations are like namespaces or schemas inside a database.
GRASS GIS is always connected to one particular Mapset.
GRASS GIS modules can create, modify, change, or delete a data only in
the current Mapset.
By default, only the data from the current Mapset and PERMANENT Mapset
are visible. Using
g.mapsets
module or in GUI other Mapsets can be made visible and seamlessly accessible.
All data are available for reading when Mapset is specified explicitly,
for example to access map streets
in Mapset
new_highway
user can use streets@new_highway
.
For maps which are in the current or PERMAENT Mapsets or Mapsets
sets as visible (accessible), there is no need to use
@mapset
syntax.
Mapsets are used to store maps related to one project, smaller project, specific task, issue or subregions. In multi-user environment, when a team works together on one project, Mapsets support simultaneous access of several users to the maps stored within the same Location. Besides access to his or her own Mapset, each user can also read maps in PERMANENT Mapsent and in other users' Mapsets when set. However, each user can modify or remove only the maps in his or her own Mapset.
Besides the geospatial data, Mapset holds additional data such as
color tables (managed e.g. by r.colors)
and the current computational region's extent and resolution
stored in a file called WIND
and managed by g.region.
Mapsets can be copied and moved as directories, however only when it is clear that the projections of both Locations (as reported by g.proj) match each other. Since this is sometimes hard to to establish, it is recommended to use r.proj or v.proj to reproject the data. The files and directories should not be moved or modified directly, but only using GRASS GIS tools.
Since the maps in PERMANENT Mapset are visible from all the other Mapsets, it can be used to store the base maps (base cartography), data common to all projects or needed for different analyses done is separate Mapsets.
In multi-user environment, data in the PERMANENT Mapset can only be added, modified or removed by the owner of the PERMANENT Mapset; however, they can be accessed, analyzed, and copied into their own Mapset by the other users. The PERMANENT Mapset is useful for providing general spatial data (e.g. an elevation model), accessible but write-protected to all users who are working in the same Location as the database owner. To manipulate or add data to PERMANENT, the owner can start GRASS GIS and choose the relevant Location and the PERMANENT Mapset.
The PERMANENT Mapset also contains the DEFAULT_WIND
file which holds
the default computational region's extent and resolution values
for the Location (which all Mapsets will inherit when they are created).
Users have the option of switching back to the default region at any time.
For cases when import is not desirable, an option to link external data exists. Projection of the linked data must match the Location's projection otherwise the external data cannot be linked. (Linking data in different projection is not allowed as it would require on-the-fly reprojection which could cause inconsistencies in the data.
For example, module r.external links external raster data, so that the data are accessible in GRASS Database as standard raster maps. Similarly for newly created maps, r.external.out setups a format and directory where the actual data will be stored, however in GRASS Database the data will be created as standard maps.
# Linux, Mac, *BSD, ...: grass --text ~/grassdata/nc_spm_08_grass7/user1 # Windows grass --text D:\grassdata\nc_spm_08_grass7\user1
# Linux, Mac, *BSD, ...: grass -c EPSG:5514:3 ~/grassdata/mylocation # Windows grass -c EPSG:5514:3 D:\grassdata\mylocation
The most convenient way of using Location Wizard is creating new Location based on a georeferenced file, such as Shapefile or GeoTIFF, or by selecting the corresponding EPSG projection code. In case of using georeferenced file, you are asked whether the data itself should be imported into the new Location. The default region is then set to match imported map.
After defining a new Location, wxGUI starts automatically. If data were already imported, you can add them into the Layer Manager now and display them. More data can be imported into the Location, e.g. using import options in the File menu in Layer Manager or r.import.
Main index | Topics index | Keywords index | Graphical index | Full index
© 2003-2023 GRASS Development Team, GRASS GIS 8.3.dev Reference Manual