docs: Standardize naming: use "GRASS" instead of "GRASS GIS" (#5644)

Author: lindakarlovska

doc/NIX.md

@@ -16,7 +16,7 @@ tool that aims to make software deployment fully reproducible.
      | sh -s -- install
   ```
 
-## Create GRASS GIS development environment
+## Create GRASS development environment
 
 Nix provides a development environment containing all required dependencies.
 
@@ -34,7 +34,7 @@ Nix provides a development environment containing all required dependencies.
   direnv allow
   ```
 
-## Launch GRASS GIS directly from the source code
+## Launch GRASS directly from the source code
 
 Nix allows to run a program directly from git source code repository using
 following command:
@@ -62,7 +62,7 @@ nix run \
   nix run github:<PR-OWNER>/grass/<PR-BRANCH>#grass
   ```
 
-## Install GRASS GIS directly from the source code
+## Install GRASS directly from the source code
 
 To install a program permanently, use following command:
 
@@ -83,7 +83,7 @@ nix profile install \
   nix profile install github:OSGeo/grass/<REVISION|BRANCH|TAG>#grass
   ```
 
-## Uninstall GRASS GIS
+## Uninstall GRASS
 
 - List installed programs
 

doc/debugging.txt

@@ -1,4 +1,4 @@
-GRASS GIS Debugging:
+GRASS Debugging:
 
 See also
 https://grasswiki.osgeo.org/wiki/GRASS_Debugging

doc/development/README.md

@@ -3,7 +3,7 @@
 Find below the development and maintenance documentation.
 The API documentation is available in the appropriate places,
 but here is the information relevant to contributing to and
-maintaining GRASS GIS.
+maintaining GRASS.
 
 ## Style and GitHub guide
 

doc/development/branching_how-to.md

@@ -57,10 +57,10 @@ Update the version in the source code (use `minor` or `major`):
 ./utils/update_version.py minor
 ```
 
-If you are using a clone you use for building GRASS GIS,
-clean up (`make distclean`) your GRASS GIS build to remove
+If you are using a clone you use for building GRASS,
+clean up (`make distclean`) your GRASS build to remove
 the now outdated generated version numbers.
-(You don't need to build GRASS GIS if you have a fresh clone.)
+(You don't need to build GRASS if you have a fresh clone.)
 
 Search for all other mentions of the last few versions to see
 if they need to be updated, for example:

doc/development/github_guide.md

@@ -1,6 +1,6 @@
 # Guide to contributing on GitHub
 
-This guide covers contributing to the GRASS GIS source,
+This guide covers contributing to the GRASS source,
 specifically to the _main_ branch.
 It assumes that you have some very basic knowledge of Git and GitHub.
 
@@ -23,14 +23,14 @@ git clone https://github.com/your_GH_account/grass.git
 cd grass/
 ```
 
-1. Add the main GRASS GIS repository as "upstream" (use HTTPS URL):
+1. Add the main GRASS repository as "upstream" (use HTTPS URL):
 
 ```bash
 git remote add upstream https://github.com/OSGeo/grass
 ```
 
 1. Your remotes now should be "origin" which is your fork and "upstream" which
-  is this main GRASS GIS repository. You can confirm that using:
+  is this main GRASS repository. You can confirm that using:
 
 ```bash
 git remote -v
@@ -143,7 +143,7 @@ to help standardize the content.
 
 ## After creating a PR
 
-GRASS GIS maintainers will now review your PR.
+GRASS maintainers will now review your PR.
 If needed, the maintainers will work with you to improve your changes.
 
 Once the changes in the PR are ready to be accepted,

doc/development/style_guide.md

@@ -446,7 +446,7 @@ The `--overwrite` flag can be globally enabled by setting the environment variab
 
 #### Mask
 
-GRASS GIS has a global mask managed by the _r.mask_ tool and represented by a
+GRASS has a global mask managed by the _r.mask_ tool and represented by a
 raster called MASK by default. Raster tools called as a subprocess will automatically
 respect the globally set mask when reading the data. For outputs, respecting of
 the mask is optional.
@@ -876,13 +876,12 @@ Notes:
   [keyword index](https://grass.osgeo.org/grass-devel/manuals/keywords.html) in
   the manual
 
-These index manual pages are autogenerated during the build process of GRASS
-GIS.
+These index manual pages are autogenerated during the build process of GRASS.
 
 #### Lazy import of optional dependencies
 
 A tool may use a package that is not [required](../../REQUIREMENTS.md)
-by GRASS GIS and may not be available on a user's system.
+by GRASS and may not be available on a user's system.
 In these cases, import only after the _gs.parser_ call. In that way the
 tool can be safely compiled even if the dependency is not installed.
 

doc/examples/gui/wxpython/README

@@ -1,7 +1,7 @@
 Motivation
 ----------
 Example Tool should help new GRASS GUI programmers who are interested in
-adding or improving GRASS GIS functionality or writing GRASS GIS GUI-based
+adding or improving GRASS functionality or writing GRASS GUI-based
 application for their own purposes.
 
 How to use Example Tool

doc/examples/notebooks/README.md

@@ -15,9 +15,9 @@ the notebook.
 See also the official documentation for
 [The Jupyter Notebook](https://jupyter-notebook.readthedocs.io/en/latest/).
 
-### Introductory notebooks to GRASS GIS and Jupyter
+### Introductory notebooks to GRASS and Jupyter
 
-* GRASS GIS in Jupyter Notebook with Python and grass.jupyter:
+* GRASS in Jupyter Notebook with Python and grass.jupyter:
   [jupyter_example.ipynb](jupyter_example.ipynb)
 * The grass.jupyter Package: [jupyter_tutorial.ipynb](jupyter_tutorial.ipynb)
 
@@ -27,6 +27,6 @@ See also the official documentation for
 * Spatio-Temporal Analysis with grass.jupyter: [temporal.ipynb](temporal.ipynb)
 * Solar Energy Potential Analysis:
   [solar_potential.ipynb](solar_potential.ipynb)
-* GRASS GIS Scripting with Python:
+* GRASS Scripting with Python:
   [scripting_example.ipynb](scripting_example.ipynb)
-* Hydrology with GRASS GIS: [hydrology.ipynb](hydrology.ipynb)
+* Hydrology with GRASS: [hydrology.ipynb](hydrology.ipynb)

doc/examples/notebooks/temporal.ipynb

@@ -43,7 +43,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "## Start GRASS GIS"
+    "## Start GRASS"
    ]
   },
   {
@@ -52,7 +52,7 @@
    "metadata": {},
    "outputs": [],
    "source": [
-    "# Ask GRASS GIS where its Python packages are.\n",
+    "# Ask GRASS where its Python packages are.\n",
     "sys.path.append(\n",
     "    subprocess.check_output([\"grass\", \"--config\", \"python_path\"], text=True).strip()\n",
     ")\n",

doc/examples/python/raster_example_ctypes.py

@@ -37,7 +37,7 @@
 
 # check if GRASS is running or not
 if "GISBASE" not in os.environ:
-    sys.exit("You must be in GRASS GIS to run this program")
+    sys.exit("You must be in GRASS to run this program")
 
 # parse command line arguments, prompt user for a raster map name if one wasn't given
 input = sys.argv[1] if len(sys.argv) == 2 else input("Name of raster map? ")

doc/examples/python/vector_example_ctypes.py

@@ -31,7 +31,7 @@
 )
 
 if "GISBASE" not in os.environ:
-    sys.exit("You must be in GRASS GIS to run this program.")
+    sys.exit("You must be in GRASS to run this program.")
 
 input = sys.argv[1] if len(sys.argv) == 2 else input("Name of vector map? ")
 

doc/examples/raster/r.example/r.example.md

@@ -1,7 +1,7 @@
 ## DESCRIPTION
 
 *r.example* does practically do nothing, except for illustrating GRASS
-GIS raster programming. It copies over an existing raster map to a new
+raster programming. It copies over an existing raster map to a new
 raster map. See the source code for details.
 
 ## NOTES

doc/grass_database.md

@@ -1,27 +1,27 @@
 ---
-description: GRASS GIS Database
+description: GRASS Database
 ---
 
-# GRASS GIS Database
+# GRASS Database
 
-A GRASS GIS Database is simply a set of directories and files with
-certain structure which GRASS GIS works efficiently with. Project is a
+A GRASS Database is simply a set of directories and files with
+certain structure which GRASS works efficiently with. Project is a
 directory with data related to one geographic location or a project. All
 data within one project has the same coordinate reference system. A
 project contains mapsets and each mapset contains data related to a
 specific task, user or a smaller project. Within each project, a
 mandatory PERMANENT mapset exists which can contain commonly used data
 within one GRASS project such as base maps. The PERMANENT mapset also
 contains metadata related to the project such as the coordinate
-reference system. When GRASS GIS is started it connects to a database,
+reference system. When GRASS is started it connects to a database,
 project and mapset specified by the user.
 
 ![example: nc_spm - highway - elevation](grass_database.png)  
-*Fig. 1: GRASS GIS Database structure as visible to the user*
+*Fig. 1: GRASS Database structure as visible to the user*
 
-## GRASS GIS Database Directory
+## GRASS Database Directory
 
-All data for GRASS GIS must be in GRASS GIS Database which is a
+All data for GRASS must be in GRASS Database which is a
 directory (visible on the disk) containing subdirectories which are
 GRASS projects. User can have one or more of Databases on the disk.
 Typically users have one directory called `grassdata` in their home
@@ -30,13 +30,13 @@ 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
+GRASS 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
+used in GRASS to hold attribute data and might be part of the GRASS
+Database. From user point of view, GRASS 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
+tools. GRASS Database is often called GISDBASE or
 DATABASE.
 
 ## GRASS Projects
@@ -51,25 +51,25 @@ reference system.
 
 GRASS projects can be safely copied or moved as any other directories.
 Compressed projects are usually what GRASS users exchange between each
-other when they want to share a lot of data. For example, GRASS GIS
+other when they want to share a lot of data. For example, GRASS
 sample data are provided as projects.
 
 Note that a GRASS project used to be called *location* and this name has
 not been completely removed from code and documentation yet.
 
 Users and programmers familiar with relational databases such as
 PostgreSQL can view projects as individual databases inside a storage
-area (the GRASS GIS Database). Mapsets in a project are like namespaces
+area (the GRASS Database). Mapsets in a project are like namespaces
 or schemas inside a database.
 
 ## GRASS Mapsets
 
 Mapsets contains the actual data, mostly geospatial data, referred to as
-maps in GRASS GIS. Mapsets are a tool for organizing maps in a
+maps in GRASS. Mapsets are a tool for organizing maps in a
 transparent way as well as a tool for isolating different tasks to
 prevent data loss.
 
-GRASS GIS is always connected to one particular mapset. GRASS GIS
+GRASS is always connected to one particular mapset. GRASS
 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*](g.mapsets.md) module or in GUI
@@ -100,11 +100,11 @@ that their coordinate reference systems (as reported by
 coordinate reference systems, it is recommended to use
 [*r.proj*](r.proj.md) or [*v.proj*](v.proj.md) to reproject the data.
 The files and directories should not be moved or modified directly, but
-only using GRASS GIS tools.
+only using GRASS tools.
 
 ## The role of the PERMANENT Mapset
 
-When creating a new project, GRASS GIS automatically creates a special
+When creating a new project, GRASS automatically creates a special
 mapset called PERMANENT where the core data for the project are stored.
 
 Since the maps in PERMANENT mapset are visible from all the other
@@ -119,7 +119,7 @@ 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 with the same GRASS project
 as the database owner. To manipulate or add data to PERMANENT, the owner
-can start GRASS GIS and choose the relevant project and the PERMANENT
+can start GRASS and choose the relevant project and the PERMANENT
 mapset.
 
 The PERMANENT mapset also contains the `DEFAULT_WIND` file which holds
@@ -129,7 +129,7 @@ have the option of switching back to the default region at any time.
 
 ## Importing, exporting and linking data
 
-GRASS GIS works only with data which are imported into a GRASS Database,
+GRASS works only with data which are imported into a GRASS Database,
 so all data needs to be imported, e.g. by [*r.in.gdal*](r.in.gdal.md) or
 highly convenient [*r.import*](r.import.md), before the actual analysis.
 Data in GRASS Datable can be exported using for example
@@ -149,14 +149,14 @@ raster maps. Similarly for newly created maps,
 where the actual data will be stored, however in GRASS Database the data
 will be created as standard maps.
 
-## Starting GRASS GIS
+## Starting GRASS
 
-After launching GRASS GIS for the first time, the GUI opens in a default
+After launching GRASS for the first time, the GUI opens in a default
 project `world_latlong_wgs84`. From there a new project can be created.
 
-![GRASS GIS GUI after first start](grass_start.png)  
+![GRASS GUI after first start](grass_start.png)  
 
-GRASS GIS can be also started with a given database, project and mapset
+GRASS can be also started with a given database, project and mapset
 from the command line. For example, the following will start in a given
 mapset with only command line interface:
 

doc/howto_release.md

@@ -1,4 +1,4 @@
-# How to release GRASS GIS binaries and source code
+# How to release GRASS binaries and source code
 
 ## Assumptions
 
@@ -80,7 +80,7 @@ For a release, change the version after the RC cycle to an official release:
 ```
 
 The script will compute the correct version string and print a message
-containing it into the terminal (e.g., "version: GRASS GIS 3.5.0RC1").
+containing it into the terminal (e.g., "version: GRASS 3.5.0RC1").
 
 Commit with a commit message suggested by the script, e.g.:
 
@@ -152,7 +152,7 @@ stored for annotated tags including a date; message is suggested by the
 `./utils/update_version.py` script):
 
 ```bash
-git tag $TAG -a -m "GRASS GIS $VERSION"
+git tag $TAG -a -m "GRASS $VERSION"
 ```
 
 List all tags (annotated will be at the top of both lists):