doc: remove GIS from several raster tools' documentation, pt2 (#5697)

Second half of the edits to convert the references to GRASS GIS to GRASS in the raster command directory. References were not edited. Links to wiki pages titled GRASS GIS were not edited.

Author: dnewcomb

raster/r.geomorphon/main.c

@@ -528,8 +528,7 @@ int main(int argc, char **argv)
                         prof_int("format_version_major", 0);
                         prof_int("format_version_minor", 9);
                         prof_utc("timestamp", time(NULL));
-                        snprintf(buf, sizeof(buf),
-                                 "r.geomorphon GRASS GIS %s [%s]",
+                        snprintf(buf, sizeof(buf), "r.geomorphon GRASS %s [%s]",
                                  GRASS_VERSION_STRING, GRASS_HEADERS_VERSION);
                         prof_str("generator", buf);
 

raster/r.in.gdal/r.in.gdal.html

@@ -1,6 +1,6 @@
 <h2>DESCRIPTION</h2>
 
-<em>r.in.gdal</em> allows a user to create a GRASS GIS raster map layer,
+<em>r.in.gdal</em> allows a user to create a GRASS raster map layer,
 or imagery group, from any GDAL supported raster map format, with an optional
 title. The imported file may also be used to create a new project
 (previously called location).
@@ -411,7 +411,7 @@ <h2>SEE ALSO</h2>
 </em>
 
 <p>
-GRASS GIS Wiki page: Import of <a href="https://grasswiki.osgeo.org/wiki/Global_datasets">Global datasets</a>
+GRASS Wiki page: Import of <a href="https://grasswiki.osgeo.org/wiki/Global_datasets">Global datasets</a>
 
 <h2>AUTHOR</h2>
 

raster/r.in.gdal/r.in.gdal.md

@@ -1,6 +1,6 @@
 ## DESCRIPTION
 
-*r.in.gdal* allows a user to create a GRASS GIS raster map layer, or
+*r.in.gdal* allows a user to create a GRASS raster map layer, or
 imagery group, from any GDAL supported raster map format, with an
 optional title. The imported file may also be used to create a new
 project (previously called location).
@@ -395,7 +395,7 @@ GDAL Pages: <https://gdal.org>
 [r.in.ascii](r.in.ascii.md), [r.in.bin](r.in.bin.md),
 [r.null](r.null.md), [t.register](t.register.md)*
 
-GRASS GIS Wiki page: Import of [Global
+GRASS Wiki page: Import of [Global
 datasets](https://grasswiki.osgeo.org/wiki/Global_datasets)
 
 ## AUTHOR

raster/r.in.lidar/r.in.lidar.html

@@ -28,7 +28,7 @@ <h3>Binning</h3>
 The main difference between <em>r.in.lidar</em> and
 <em><a href="v.in.lidar.html">v.in.lidar</a></em> is that
 <em>r.in.lidar</em> creates a raster instead of just importing the
-points into GRASS GIS. However, <em>r.in.lidar</em> does not merely
+points into GRASS. However, <em>r.in.lidar</em> does not merely
 rasterizes the points from the point cloud. <em>r.in.lidar</em>
 uses binning to derive values for individual raster cells,
 so the value of a cell is typically an aggregation of values
@@ -42,7 +42,7 @@ <h3>Binning</h3>
 points which fall into one raster cell, i.e. bin. The number of points
 per cell (bin) indicates the density of points in the point cloud.
 The cell (bin) is always square or rectangular in case of
-<em>r.in.lidar</em> because the result is GRASS GIS 2D raster.
+<em>r.in.lidar</em> because the result is GRASS 2D raster.
 The result of binning where the number of point per cell is counted
 is sometimes called 2D (two dimensional) histogram because
 a histogram is used in univariate statistics (in one dimension)
@@ -155,7 +155,7 @@ <h3>Filtering</h3>
 </pre></div>
 
 See <em><a href="g.region.html">g.region</a></em> for details about
-computation region handling in GRASS GIS.
+computation region handling in GRASS.
 
 <p>
 The <b>zrange</b> parameter may be used for filtering the input data by

raster/r.in.lidar/r.in.lidar.md

@@ -22,7 +22,7 @@ with large datasets (see below for memory management notes).
 
 The main difference between *r.in.lidar* and
 *[v.in.lidar](v.in.lidar.md)* is that *r.in.lidar* creates a raster
-instead of just importing the points into GRASS GIS. However,
+instead of just importing the points into GRASS. However,
 *r.in.lidar* does not merely rasterizes the points from the point cloud.
 *r.in.lidar* uses binning to derive values for individual raster cells,
 so the value of a cell is typically an aggregation of values of
@@ -35,7 +35,7 @@ In the basic case, binning is a method which counts the number of points
 which fall into one raster cell, i.e. bin. The number of points per cell
 (bin) indicates the density of points in the point cloud. The cell (bin)
 is always square or rectangular in case of *r.in.lidar* because the
-result is GRASS GIS 2D raster. The result of binning where the number of
+result is GRASS 2D raster. The result of binning where the number of
 point per cell is counted is sometimes called 2D (two dimensional)
 histogram because a histogram is used in univariate statistics (in one
 dimension) to count the number samples falling into a given bin.
@@ -142,7 +142,7 @@ g.region s=s-0.000001
 ```
 
 See *[g.region](g.region.md)* for details about computation region
-handling in GRASS GIS.
+handling in GRASS.
 
 The **zrange** parameter may be used for filtering the input data by
 vertical extent. Example uses include filtering out extreme outliers and

raster/r.info/r.info.html

@@ -29,7 +29,7 @@ <h2>NOTES</h2>
 
 <p>
 Some standards (ISO-C90) and compilers do not support the 'long long' type
-as a 64-bit type. In the case that GRASS GIS was built with such a compiler,
+as a 64-bit type. In the case that GRASS was built with such a compiler,
 an accuracy message may be displayed in the output of <em>r.info</em>
 after Total Cells.
 

raster/r.info/r.info.md

@@ -23,7 +23,7 @@ On large maps, the total number of cells in the map may not be displayed
 with an accurate number. This is only cosmetic.
 
 Some standards (ISO-C90) and compilers do not support the 'long long'
-type as a 64-bit type. In the case that GRASS GIS was built with such a
+type as a 64-bit type. In the case that GRASS was built with such a
 compiler, an accuracy message may be displayed in the output of *r.info*
 after Total Cells.
 

raster/r.resamp.interp/r.resamp.interp.html

@@ -48,7 +48,7 @@ <h3>PERFORMANCE</h3>
      number of cells. See benchmark scripts in source code.</i>
      </div>
 <p>To reduce the memory requirements to minimum, set option <b>memory</b> to zero.
-To take advantage of the parallelization, GRASS GIS
+To take advantage of the parallelization, GRASS
 needs to compiled with OpenMP enabled.
 
 <h2>EXAMPLE</h2>

raster/r.resamp.interp/r.resamp.interp.md

@@ -42,7 +42,7 @@ By specifying the number of parallel processes with **nprocs** option,
 See benchmark scripts in source code.*
 
 To reduce the memory requirements to minimum, set option **memory** to
-zero. To take advantage of the parallelization, GRASS GIS needs to
+zero. To take advantage of the parallelization, GRASS needs to
 compiled with OpenMP enabled.
 
 ## EXAMPLE

raster/r.rescale.eq/r.rescale.eq.html

@@ -10,7 +10,7 @@ <h2>DESCRIPTION</h2>
 number of categories from a raster map layer with a large
 range of category values (e.g., elevation).
 <em>Rescaled</em> map layers are appropriate for use in
-such GRASS GIS commands as
+such GRASS commands as
 
 <em><a href="r.stats.html">r.stats</a></em>,
 <em><a href="r.report.html">r.report</a></em>, and

raster/r.rescale.eq/r.rescale.eq.md

@@ -8,7 +8,7 @@ reflect the original category values that produced each category. This
 command is useful for producing representations with a reduced number of
 categories from a raster map layer with a large range of category values
 (e.g., elevation). *Rescaled* map layers are appropriate for use in such
-GRASS GIS commands as *[r.stats](r.stats.md)*,
+GRASS commands as *[r.stats](r.stats.md)*,
 *[r.report](r.report.md)*, and *[r.coin](r.coin.md)*.
 
 ## EXAMPLE

raster/r.rescale/r.rescale.html

@@ -10,7 +10,7 @@ <h2>DESCRIPTION</h2>
 number of categories from a raster map layer with a large
 range of category values (e.g., elevation).
 <em>Rescaled</em> map layers are appropriate for use in
-such GRASS GIS commands as
+such GRASS commands as
 
 <em><a href="r.stats.html">r.stats</a></em>,
 <em><a href="r.report.html">r.report</a></em>, and

raster/r.rescale/r.rescale.md

@@ -7,7 +7,7 @@ are generated with category labels that reflect the original category
 values that produced each category. This command is useful for producing
 representations with a reduced number of categories from a raster map
 layer with a large range of category values (e.g., elevation).
-*Rescaled* map layers are appropriate for use in such GRASS GIS commands
+*Rescaled* map layers are appropriate for use in such GRASS commands
 as *[r.stats](r.stats.md)*, *[r.report](r.report.md)*, and
 *[r.coin](r.coin.md)*.
 

raster/r.slope.aspect/r.slope.aspect.html

@@ -13,7 +13,7 @@ <h2>DESCRIPTION</h2>
 elevation values, <em>not</em> rescaled or categorized data. If the elevation
 values are in other units than in the horizontal units,
 they must be converted to horizontal units using the parameter <b>zscale</b>.
-<em>In GRASS GIS 7, vertical units are not assumed to be meters any more.
+<em>In GRASS, vertical units are not assumed to be meters any more.
 For example, if both your vertical and horizontal units are feet,
 parameter <b>zscale</b> must not be used</em>.
 
@@ -193,7 +193,7 @@ <h3>PERFORMANCE</h3>
      </div>
 
 <p>To reduce the memory requirements to minimum, set option <b>memory</b> to zero.
-To take advantage of the parallelization, GRASS GIS
+To take advantage of the parallelization, GRASS
 needs to compiled with OpenMP enabled.
 
 <h2>EXAMPLES</h2>

raster/r.slope.aspect/r.slope.aspect.md

@@ -12,7 +12,7 @@ The **elevation** input raster map specified by the user must contain
 true elevation values, *not* rescaled or categorized data. If the
 elevation values are in other units than in the horizontal units, they
 must be converted to horizontal units using the parameter **zscale**.
-*In GRASS GIS 7, vertical units are not assumed to be meters any more.
+*In GRASS, vertical units are not assumed to be meters any more.
 For example, if both your vertical and horizontal units are feet,
 parameter **zscale** must not be used*.
 
@@ -150,7 +150,7 @@ memory size for 5000x5000 raster. See benchmark scripts in source code.
 (Intel Core i9-10940X CPU @ 3.30GHz x 28)*
 
 To reduce the memory requirements to minimum, set option **memory** to
-zero. To take advantage of the parallelization, GRASS GIS needs to
+zero. To take advantage of the parallelization, GRASS needs to
 compiled with OpenMP enabled.
 
 ## EXAMPLES

raster/r.solute.transport/example.py

@@ -1,6 +1,6 @@
 #!/usr/bin/env python3
 # This is an example script how groundwater flow and solute transport are
-# computed within GRASS GIS
+# computed within GRASS
 import grass.script as gs
 
 # Overwrite existing maps

raster/r.solute.transport/r.solute.transport.html

@@ -93,7 +93,7 @@ <h2>EXAMPLE</h2>
 <div class="code"><pre>
 #!/usr/bin/env python3
 # This is an example script how groundwater flow and solute transport are
-# computed within GRASS GIS
+# computed within GRASS
 import sys
 import os
 import grass.script as gs

raster/r.solute.transport/r.solute.transport.md

@@ -86,7 +86,7 @@ projection.
 ```python
 #!/usr/bin/env python3
 # This is an example script how groundwater flow and solute transport are
-# computed within GRASS GIS
+# computed within GRASS
 import sys
 import os
 import grass.script as gs

raster/r.stats.zonal/graphics_for_description.ipynb

@@ -6,9 +6,9 @@
    "source": [
     "# Graphics for description of r.stats.zonal\n",
     "\n",
-    "To be run in a GRASS GIS session, North Carolina sample dataset.\n",
+    "To be run in a GRASS session, North Carolina sample dataset.\n",
     "\n",
-    "Requires _d.explanation.plot_ (GRASS GIS addon), _pngquant_, _optipng_ and ImageMagic _mogrify_."
+    "Requires _d.explanation.plot_ (GRASS addon), _pngquant_, _optipng_ and ImageMagic _mogrify_."
    ]
   },
   {