doc: remove GIS from several raster tools' documentation (#5684)

* clean up GRASS GIS notes for r.series

* clean up GRASS GIS notes for r.in.pdal

* clean up GRASS GIS notes for r.in.xyz remove GIS

* clean up GRASS GIS notes for r.mapcalc remove GIS

* clean up GRASS GIS notes for r.mfilter remove GIS

* clean up GRASS GIS notes for r.neighbors remove GIS

* clean up main.c for r.out.gdal change GRASS GIS to GRASS for metadata written to file

* clean up r.out.png change GRASS GIS to GRASS for documentation

* clean up r.out.vtk change GRASS GIS to GRASS in output file metadata

* clean up r.patch change GRASS GIS to GRASS for documentation

* clean up r.proj change GRASS GIS to GRASS for documentation

* clean up r.resamp.filter change GRASS GIS to GRASS for documentation

Author: dnewcomb

raster/r.in.pdal/grasslidarfilter.h

@@ -36,7 +36,7 @@ extern "C" {
 #pragma clang diagnostic pop
 #endif
 
-/* All GRASS GIS filters which are similar across multiple modules
+/* All GRASS filters which are similar across multiple modules
  * put together as one PDAL Stage class.
  */
 class GrassLidarFilter : public pdal::Filter, public pdal::Streamable {

raster/r.in.pdal/r.in.pdal.html

@@ -27,7 +27,7 @@ <h3>Binning</h3>
 The main difference between <em>r.in.pdal</em> and
 <em><a href="v.in.pdal.html">v.in.pdal</a></em> is that
 <em>r.in.pdal</em> creates a raster instead of just importing the
-points into GRASS GIS. However, <em>r.in.pdal</em> does not merely
+points into GRASS. However, <em>r.in.pdal</em> does not merely
 rasterizes the points from the point cloud. <em>r.in.pdal</em>
 uses binning to derive values for individual raster cells,
 so the value of a cell is typically an aggregation of values
@@ -41,7 +41,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.pdal</em> because the result is GRASS GIS 2D raster.
+<em>r.in.pdal</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)
@@ -180,7 +180,7 @@ <h3>Filtering and selection</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.pdal/r.in.pdal.md

@@ -22,7 +22,7 @@ example raw LiDAR or sidescan sonar swath data.
 
 The main difference between *r.in.pdal* and *[v.in.pdal](v.in.pdal.md)*
 is that *r.in.pdal* creates a raster instead of just importing the
-points into GRASS GIS. However, *r.in.pdal* does not merely rasterizes
+points into GRASS. However, *r.in.pdal* does not merely rasterizes
 the points from the point cloud. *r.in.pdal* uses binning to derive
 values for individual raster cells, so the value of a cell is typically
 an aggregation of values of individual points falling into one cell. In
@@ -34,7 +34,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.pdal* 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.
@@ -171,7 +171,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.in.xyz/r.in.xyz.html

@@ -334,7 +334,7 @@ <h2>SEE ALSO</h2>
  - The UNIX pipe viewer utility
 
 <p>
-Overview: <a href="https://grasswiki.osgeo.org/wiki/Interpolation">Interpolation and Resampling</a> in GRASS GIS
+Overview: <a href="https://grasswiki.osgeo.org/wiki/Interpolation">Interpolation and Resampling</a> in GRASS
 
 <h2>AUTHORS</h2>
 

raster/r.in.xyz/r.in.xyz.md

@@ -300,7 +300,7 @@ Development Team.
 utility
 
 Overview: [Interpolation and
-Resampling](https://grasswiki.osgeo.org/wiki/Interpolation) in GRASS GIS
+Resampling](https://grasswiki.osgeo.org/wiki/Interpolation) in GRASS
 
 ## AUTHORS
 

raster/r.mapcalc/r.mapcalc.html

@@ -594,7 +594,7 @@ <h3>Backwards compatibility</h3>
 foo = 1
 EOF
 </pre></div>
-But unless you need compatibility with previous GRASS GIS versions, use <code>file=</code>
+But unless you need compatibility with previous GRASS versions, use <code>file=</code>
 explicitly, as stated above.
 <p>
 When the map name contains uppercase letter(s) or a dot which are not

raster/r.mapcalc/r.mapcalc.md

@@ -666,7 +666,7 @@ foo = 1
 EOF
 ```
 
-But unless you need compatibility with previous GRASS GIS versions, use
+But unless you need compatibility with previous GRASS versions, use
 `file=` explicitly, as stated above.
 
 When the map name contains uppercase letter(s) or a dot which are not

raster/r.mapcalc/r3.mapcalc.html

@@ -420,7 +420,7 @@ <h3>Backwards compatibility</h3>
 foo = 1
 EOF
 </pre></div>
-But unless you need compatibility with previous GRASS GIS versions, use <code>file=</code>
+But unless you need compatibility with previous GRASS versions, use <code>file=</code>
 explicitly, as stated above.
 <p>
 When the map name contains uppercase letter(s) or a dot which are not

raster/r.mapcalc/r3.mapcalc.md

@@ -484,7 +484,7 @@ foo = 1
 EOF
 ```
 
-But unless you need compatibility with previous GRASS GIS versions, use
+But unless you need compatibility with previous GRASS versions, use
 `file=` explicitly, as stated above.
 
 When the map name contains uppercase letter(s) or a dot which are not

raster/r.mfilter/r.mfilter.html

@@ -147,7 +147,7 @@ <h3>PERFORMANCE</h3>
      </div>
 <p> Note that parallelization is implemented only for the parallel filter,
 not the sequential one.
-To take advantage of the parallelization, GRASS GIS
+To take advantage of the parallelization, GRASS
 needs to compiled with OpenMP enabled.
 
 <h2>NOTES</h2>

raster/r.neighbors/r.neighbors.html

@@ -437,7 +437,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 be compiled with OpenMP enabled.
 
 <h2>EXAMPLES</h2>

raster/r.neighbors/r.neighbors.md

@@ -393,7 +393,7 @@ 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 be
+zero. To take advantage of the parallelization, GRASS needs to be
 compiled with OpenMP enabled.
 
 ## EXAMPLES

raster/r.out.gdal/main.c

@@ -707,7 +707,7 @@ int main(int argc, char *argv[])
         char *pszValue;
 
         pszKey = "TIFFTAG_SOFTWARE";
-        G_asprintf(&pszValue, "GRASS GIS %s with GDAL %d.%d.%d",
+        G_asprintf(&pszValue, "GRASS %s with GDAL %d.%d.%d",
                    GRASS_VERSION_NUMBER, GDAL_VERSION_MAJOR, GDAL_VERSION_MINOR,
                    GDAL_VERSION_REV);
         GDALSetMetadataItem(hCurrDS, pszKey, pszValue, NULL);
@@ -718,7 +718,7 @@ int main(int argc, char *argv[])
         char *pszValue;
 
         pszKey = "SOFTWARE";
-        G_asprintf(&pszValue, "GRASS GIS %s with GDAL %d.%d.%d",
+        G_asprintf(&pszValue, "GRASS %s with GDAL %d.%d.%d",
                    GRASS_VERSION_NUMBER, GDAL_VERSION_MAJOR, GDAL_VERSION_MINOR,
                    GDAL_VERSION_REV);
         GDALSetMetadataItem(hCurrDS, pszKey, pszValue, NULL);

raster/r.out.png/r.out.png.html

@@ -1,6 +1,6 @@
 <h2>DESCRIPTION</h2>
 
-<em>r.out.png</em> exports a GRASS GIS raster map in non-georeferenced
+<em>r.out.png</em> exports a GRASS raster map in non-georeferenced
 Portable Network Graphics (PNG) image format, respecting the current
 region resolution and bounds.
 

raster/r.out.png/r.out.png.md

@@ -1,6 +1,6 @@
 ## DESCRIPTION
 
-*r.out.png* exports a GRASS GIS raster map in non-georeferenced Portable
+*r.out.png* exports a GRASS raster map in non-georeferenced Portable
 Network Graphics (PNG) image format, respecting the current region
 resolution and bounds.
 

raster/r.out.vtk/writeascii.c

@@ -74,7 +74,7 @@ void write_vtk_normal_header(FILE *fp, struct Cell_head region,
     /*Simple vtk ASCII header */
     fprintf(fp, "# vtk DataFile Version 3.0\n");
     /* The header line describes the data. */
-    fprintf(fp, "GRASS GIS %i Export\n", GRASS_VERSION_MAJOR);
+    fprintf(fp, "GRASS %i Export\n", GRASS_VERSION_MAJOR);
     fprintf(fp, "ASCII\n");
     fprintf(fp, "DATASET STRUCTURED_POINTS\n"); /*We are using the structured
                                                    point dataset. */
@@ -105,7 +105,7 @@ void write_vtk_structured_elevation_header(FILE *fp, struct Cell_head region)
 
     /*Simple vtk ASCII header */
     fprintf(fp, "# vtk DataFile Version 3.0\n");
-    fprintf(fp, "GRASS GIS %i Export\n", GRASS_VERSION_MAJOR);
+    fprintf(fp, "GRASS %i Export\n", GRASS_VERSION_MAJOR);
     fprintf(fp, "ASCII\n");
     fprintf(fp, "DATASET STRUCTURED_GRID\n"); /*We are using the structured grid
                                                  dataset. */
@@ -123,7 +123,7 @@ void write_vtk_polygonal_elevation_header(FILE *fp, struct Cell_head region)
 
     /*Simple vtk ASCII header */
     fprintf(fp, "# vtk DataFile Version 3.0\n");
-    fprintf(fp, "GRASS GIS %i Export\n", GRASS_VERSION_MAJOR);
+    fprintf(fp, "GRASS %i Export\n", GRASS_VERSION_MAJOR);
     fprintf(fp, "ASCII\n");
     fprintf(fp, "DATASET POLYDATA\n"); /*We are using polydataset. */
     fprintf(fp, "POINTS %i float\n", region.cols * region.rows);

raster/r.patch/r.patch.html

@@ -175,7 +175,7 @@ <h3>PERFORMANCE</h3>
      (Intel Core i9-10940X CPU @ 3.30GHz x 28) </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>EXAMPLES</h2>

raster/r.patch/r.patch.md

@@ -153,7 +153,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.proj/r.proj.html

@@ -59,7 +59,7 @@ <h4>Map projections</h4>
 points at intermediate locations relative to the source grid are
 estimated.
 
-<h4>Reprojecting vector maps within the GRASS GIS</h4>
+<h4>Reprojecting vector maps within GRASS</h4>
 <!-- move this into v.proj.html !! -->
 GIS data capture, import and transfer often requires a reprojection
 step, since the source or client will frequently be in a different

raster/r.proj/r.proj.md

@@ -56,7 +56,7 @@ sample points in another projection. Thus, the conversion of raster maps
 involves an interpolation step in which the values of points at
 intermediate locations relative to the source grid are estimated.
 
-#### Reprojecting vector maps within the GRASS GIS
+#### Reprojecting vector maps within GRASS
 
 GIS data capture, import and transfer often requires a reprojection
 step, since the source or client will frequently be in a different CRS
@@ -71,7 +71,7 @@ used to process simple lists using a one-line command. The *m.proj*
 module provides a handy front end to `cs2cs`.
 
 Vector maps is generally more complex, as parts of the data stored in
-the files will describe topology, and not just coordinates. In GRASS GIS
+the files will describe topology, and not just coordinates. In GRASS,  
 the *[v.proj](v.proj.md)* module is provided to reproject vector maps,
 transferring topology and attributes as well as node coordinates. This
 program uses the CRS definition and parameters which are stored in the

raster/r.resamp.filter/r.resamp.filter.html

@@ -119,7 +119,7 @@ <h3>PERFORMANCE</h3>
      number of cells. See benchmark script in the 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.
 
 

raster/r.resamp.filter/r.resamp.filter.md

@@ -100,7 +100,7 @@ By specifying the number of parallel processes with **nprocs** option,
 See benchmark script in the 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.
 
 ## SEE ALSO

raster/r.series/graphics_for_description.ipynb

@@ -6,7 +6,7 @@
    "source": [
     "# Graphics for Description of r.series\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_."
    ]
   },
   {

raster/r.series/r.series.html

@@ -163,7 +163,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.series/r.series.md

@@ -159,7 +159,7 @@ memory size for 10000x10000 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