CI: Enable codespell for Markdown and HTML files and fix typos

.pre-commit-config.yaml

@@ -128,7 +128,5 @@ repos:
           - c
           - c++
           - csv
-          - html
-          - markdown
           - python
           - tex

doc/development/style_guide.md

@@ -414,7 +414,7 @@ See [Changing computational region](#changing-computational-region) for more det
 #### Mapsets
 
 **Output data should be always written to the current mapset**. This is ensured
-by build-in GRASS mechanisms, so there is nothing which needs to be done in the
+by built-in GRASS mechanisms, so there is nothing which needs to be done in the
 tool. If a tool modifies inputs, the input must be in the current mapset.
 
 The tool should accept inputs from any mapset in the current project. The

doc/interfaces_overview.md

@@ -114,7 +114,7 @@ m.d_vect(map="streets", color="black")
 m.show()
 ```
 
-![Elevation map overlayed with streets with gj.Map](jupyter_map.png)
+![Elevation map overlaid with streets with gj.Map](jupyter_map.png)
 
 [Learn more :material-arrow-right-bold:](jupyter_intro.md){ .md-button }
 

doc/jupyter_intro.md

@@ -58,7 +58,7 @@ The following examples will use the [North Carolina dataset](https://grass.osgeo
 ## Map
 
 The `gj.Map` class in `grass.jupyter` provides a way to create static maps in Jupyter.
-Here we create a map of elevation overlayed with streets:
+Here we create a map of elevation overlaid with streets:
 
 ```python
 # Create a new map
@@ -74,7 +74,7 @@ m.d_vect(map="streets", color="black")
 m.show()
 ```
 
-![Elevation map overlayed with streets with gj.Map](jupyter_map.png)
+![Elevation map overlaid with streets with gj.Map](jupyter_map.png)
 
 !!! grass-tip "Order Matters"
     <!-- markdownlint-disable-next-line MD046 -->

doc/python_intro.md

@@ -839,7 +839,7 @@ slope_aspect_tool.inputs
 ```
 
 The [grass.pygrass.modules](https://grass.osgeo.org/grass-stable/manuals/libpython/pygrass_modules.html)
-module provides an alterative approach to running GRASS tools.
+module provides an alternative approach to running GRASS tools.
 
 To learn more about the `Module` class, see the Full Documentation:
 

general/g.proj/g.proj.html

@@ -47,18 +47,18 @@ <h2>DESCRIPTION</h2>
 
 <dt>epsg=<em>number</em></dt>
 <dd><em>number</em> should correspond to the index number of a valid
-co-ordinate system in the <a href="https://epsg.org/search/by-name">EPSG
+coordinate system in the <a href="https://epsg.org/search/by-name">EPSG
 database</a>. EPSG code support is based upon a local copy of the GDAL CSV
-co-ordinate system and datum information files, stored in the directory
+coordinate system and datum information files, stored in the directory
 <code>$GISBASE/etc/proj/ogr_csv</code>. These can be updated if necessary
 to support future revisions of the EPSG database.</dd>
 </dl>
 
 <p>If datum information is incorrect or missing in the input
-co-ordinate system definition (e.g. PROJ descriptions have very limited
+coordinate system definition (e.g. PROJ descriptions have very limited
 support for specifying datum names), a GRASS datum abbreviation can instead be
 supplied using the <em>datum</em> parameter. This will override any
-datum contained in the input co-ordinate system, and discard
+datum contained in the input coordinate system, and discard
 any datum transformation parameters. Enter datum=<em>list</em> to return a
 list of all the datums supported by GRASS. Since any
 existing datum transformation parameters will have been discarded, the
@@ -80,12 +80,12 @@ <h2>DESCRIPTION</h2>
 
 <p>The final mode of operation of <em>g.proj</em> is to report on the datum
 information and datum transformation parameters associated with the
-co-ordinate system. The <b>-d</b> flag will report a human-readable summary of
+coordinate system. The <b>-d</b> flag will report a human-readable summary of
 this.
 
 <h2>NOTES</h2>
 
-<p>If the input co-ordinate system contains a datum name but no
+<p>If the input coordinate system contains a datum name but no
 transformation parameters, and there is more than one suitable parameter set
 available (according to the files datum.table and datumtransform.table in
 <code>$GISBASE/etc/proj</code>), <em>g.proj</em> will check the value of
@@ -99,17 +99,17 @@ <h2>NOTES</h2>
 (likely non-optimum) parameters for this datum if necessary in the future.</li>
 <li> <strong>Any other number less than or equal to the number of parameter sets
 available for this datum:</strong> Choose this parameter set and add it to the
-co-ordinate system description.</li>
+coordinate system description.</li>
 </ul>
 
 If the <b>-t</b> flag is specified, the module will attempt to change the
 datum transformation parameters using one of the above two methods
 <strong>even if</strong> a valid parameter set is already specified in the
-input co-ordinate system. This can be useful to change the datum information
+input coordinate system. This can be useful to change the datum information
 for an existing project.
 
 <p>Output is simply based on the input CRS information. g.proj does
-<strong>not</strong> attempt to verify that the co-ordinate system thus
+<strong>not</strong> attempt to verify that the coordinate system thus
 described matches a pre-defined existing system in use in the world. In
 particular, this means there may be no authority names and codes in the
 WKT output.

general/g.proj/g.proj.md

@@ -41,18 +41,18 @@ given for *description*, the PROJ description will be read from stdin
 rather than as a directly-supplied command-line parameter.
 
 epsg=*number*  
-*number* should correspond to the index number of a valid co-ordinate
+*number* should correspond to the index number of a valid coordinate
 system in the [EPSG database](https://epsg.org/search/by-name). EPSG
-code support is based upon a local copy of the GDAL CSV co-ordinate
+code support is based upon a local copy of the GDAL CSV coordinate
 system and datum information files, stored in the directory
 `$GISBASE/etc/proj/ogr_csv`. These can be updated if necessary to
 support future revisions of the EPSG database.
 
-If datum information is incorrect or missing in the input co-ordinate
+If datum information is incorrect or missing in the input coordinate
 system definition (e.g. PROJ descriptions have very limited support for
 specifying datum names), a GRASS datum abbreviation can instead be
 supplied using the *datum* parameter. This will override any datum
-contained in the input co-ordinate system, and discard any datum
+contained in the input coordinate system, and discard any datum
 transformation parameters. Enter datum=*list* to return a list of all
 the datums supported by GRASS. Since any existing datum transformation
 parameters will have been discarded, the *datumtrans* parameter should
@@ -72,12 +72,12 @@ be overwritten. The program will **not** warn before doing this.
 
 The final mode of operation of *g.proj* is to report on the datum
 information and datum transformation parameters associated with the
-co-ordinate system. The **-d** flag will report a human-readable summary
+coordinate system. The **-d** flag will report a human-readable summary
 of this.
 
 ## NOTES
 
-If the input co-ordinate system contains a datum name but no
+If the input coordinate system contains a datum name but no
 transformation parameters, and there is more than one suitable parameter
 set available (according to the files datum.table and
 datumtransform.table in `$GISBASE/etc/proj`), *g.proj* will check the
@@ -90,16 +90,16 @@ value of the *datumtrans* option and act according to the following:
   non-optimum) parameters for this datum if necessary in the future.
 - **Any other number less than or equal to the number of parameter sets
   available for this datum:** Choose this parameter set and add it to
-  the co-ordinate system description.
+  the coordinate system description.
 
 If the **-t** flag is specified, the module will attempt to change the
 datum transformation parameters using one of the above two methods
 **even if** a valid parameter set is already specified in the input
-co-ordinate system. This can be useful to change the datum information
+coordinate system. This can be useful to change the datum information
 for an existing project.
 
 Output is simply based on the input CRS information. g.proj does **not**
-attempt to verify that the co-ordinate system thus described matches a
+attempt to verify that the coordinate system thus described matches a
 pre-defined existing system in use in the world. In particular, this
 means there may be no authority names and codes in the WKT output.
 

general/g.setproj/g.setproj.html

@@ -16,7 +16,7 @@ <h2>NOTES</h2>
 Most projections are supported. The
 <a href="https://proj.org/">PROJ</a> abbreviations for the names are
 used with two exceptions, viz. 'll', for latitude / longitude geographic
-co-ordinates, and 'stp', for the State Plane Co-ordinate system (used in the
+coordinates, and 'stp', for the State Plane Coordinate system (used in the
 USA).
 
 <p>After the projection name, the user will be asked for a geodetic datum. If

general/g.setproj/g.setproj.md

@@ -14,7 +14,7 @@ can be run.
 The user will be prompted for the projection name. Most projections are
 supported. The [PROJ](https://proj.org/) abbreviations for the names are
 used with two exceptions, viz. 'll', for latitude / longitude geographic
-co-ordinates, and 'stp', for the State Plane Co-ordinate system (used in
+coordinates, and 'stp', for the State Plane Coordinate system (used in
 the USA).
 
 After the projection name, the user will be asked for a geodetic datum.

gui/xml/grass-interface.dtd

@@ -71,7 +71,7 @@
 	integer		: a numeric integer parameter.
 	float		: a numeric float parameter.
 	If multiple is "yes", then many values for the
-	parameter may be given in a comma-seperated list
+	parameter may be given in a comma-separated list
 -->
 <!ELEMENT parameter     (description?, keydesc?, gisprompt?, default?, values?, guisection?)>
 <!ATTLIST parameter	name		CDATA #REQUIRED

imagery/i.cluster/i.cluster.html

@@ -285,7 +285,7 @@ <h2>EXAMPLE</h2>
 <p>
 The signature file obtained in the example above will allow
 to classify the current imagery group only (lsat7_2002).
-If the user would like to re-use the signature file for the
+If the user would like to reuse the signature file for the
 classification of different imagery group(s), they can set
 semantic labels for each group member beforehand, i.e.,
 before generating the signature files.

imagery/i.cluster/i.cluster.md

@@ -205,7 +205,7 @@ used. See example in its manual page.
 
 The signature file obtained in the example above will allow to classify
 the current imagery group only (lsat7_2002). If the user would like to
-re-use the signature file for the classification of different imagery
+reuse the signature file for the classification of different imagery
 group(s), they can set semantic labels for each group member beforehand,
 i.e., before generating the signature files. Semantic labels are set by
 means of *r.support* as shown below:

imagery/i.smap/i.smap.html

@@ -181,7 +181,7 @@ <h2>EXAMPLE</h2>
 <p>
 The signature file obtained in the example above will allow
 to classify the current imagery group only (lsat7_2002).
-If the user would like to re-use the signature file for the
+If the user would like to reuse the signature file for the
 classification of different imagery group(s), they can set
 semantic labels for each group member beforehand, i.e.,
 before generating the signature files.

imagery/i.smap/i.smap.md

@@ -149,7 +149,7 @@ r.kappa -w classification=lsat7_2002_smap_classes reference=training
 
 The signature file obtained in the example above will allow to classify
 the current imagery group only (lsat7_2002). If the user would like to
-re-use the signature file for the classification of different imagery
+reuse the signature file for the classification of different imagery
 group(s), they can set semantic labels for each group member beforehand,
 i.e., before generating the signature files. Semantic labels are set by
 means of *r.support* as shown below:

include/grass/iostream/pqheap.h

@@ -163,7 +163,7 @@ class pqheap_t1 {
     inline void delete_min_and_insert(const T &x);
 
     // this function is a dirty way to allow building faster the heap
-    // in case we build it from a sorted array; in that case we dont need
+    // in case we build it from a sorted array; in that case we don't need
     // to 'insert' and then 'heapify', but it is enough to 'set'
     void set(long i, T &elt);
 
@@ -342,7 +342,7 @@ T pqheap_t1<T>::min()
 
 //************************************************************/
 // this function is a dirty hack to allow building faster the heap
-// in case we build it from a sorted array; in thiat case we dont need
+// in case we build it from a sorted array; in that case we don't need
 // to 'insert' and then 'heapify', but it is enough to 'set'
 template <class T>
 inline void pqheap_t1<T>::set(long i, T &elt)
@@ -472,7 +472,7 @@ inline void pqheap_t1<T>::heapify(unsigned int root)
     unsigned int rc = heap_rchild(root);
 
 #ifdef HEAPSTATUS
-    // already did the root, so dont do it again
+    // already did the root, so don't do it again
     if (lc < cur_elts) {
         heaptouch(lc);
     }

lib/cdhc/doc/goodness.tex

@@ -1674,7 +1674,7 @@ \section{Utility Functions}
 \clearpage
 
 \begin{table}
-\caption{Signficant Values of D'Agostino's D Test (\(y\) statistic
+\caption{Significant Values of D'Agostino's D Test (\(y\) statistic
 of eqn.~\protect\ref{eqn:xform-d}).}
 \centerline{Reproduced from D'Agostino~\protect\cite{dagostino86}.}
 \label{tbl:d-test}

misc/m.cogo/m.cogo.html

@@ -47,7 +47,7 @@ <h2>DESCRIPTION</h2>
 <h2>NOTES</h2>
 
 For those unfamiliar with the notation for bearings: Picture yourself in the
-center of a circle.  The first hemispere notation tell you whether you should
+center of a circle.  The first hemisphere notation tell you whether you should
 face north or south.  Then you read the angle and either turn that many
 degrees to the east or west, depending on the second hemisphere notation.
 Finally, you move &lt;distance&gt; units in that direction to get to the

misc/m.cogo/m.cogo.md

@@ -43,7 +43,7 @@ Unless specified with the **coord** option, calculations begin from
 ## NOTES
 
 For those unfamiliar with the notation for bearings: Picture yourself in
-the center of a circle. The first hemispere notation tell you whether
+the center of a circle. The first hemisphere notation tell you whether
 you should face north or south. Then you read the angle and either turn
 that many degrees to the east or west, depending on the second
 hemisphere notation. Finally, you move \<distance\> units in that

mswindows/external/rbatch/README.html

@@ -4,6 +4,6 @@ <h1>Batchfiles</h1>
 <p>
 Home Page: <a href="http://batchfiles.googlecode.com">batchfiles home page</a>.
 <p>
-Discuss: <a href="http://groups.google.com/group/sqldf">sqldf dicussion group</a> is being used for discussion of this software too.
+Discuss: <a href="http://groups.google.com/group/sqldf">sqldf discussion group</a> is being used for discussion of this software too.
 <p>
 SVN:  <a href="https://code.google.com/p/batchfiles/source/checkout">source</a>

mswindows/external/rbatch/README.md

@@ -2,7 +2,7 @@
 
 Home Page: [batchfiles home page](http://batchfiles.googlecode.com).
 
-Discuss: [sqldf dicussion group](http://groups.google.com/group/sqldf)
+Discuss: [sqldf discussion group](http://groups.google.com/group/sqldf)
 is being used for discussion of this software too.
 
 SVN: [source](https://code.google.com/p/batchfiles/source/checkout)

mswindows/external/rbatch/batchfiles.md

@@ -226,7 +226,7 @@ and then enter the same set command into the new window.  Now any use of R in
 the original window will use the default version whereas in the new `cmd` line
 window it will use the specified version.
 
-One can change the registry entry permanently to refer to a particlar version
+One can change the registry entry permanently to refer to a particular version
 like this:
 
 ```bash

ps/ps.map/README

@@ -23,7 +23,7 @@ The manual for ps.map says that fields width and hwidth
 specify the width of the line in pixels, which is not true:
 they were actually interpreted as width in user space PostScript
 coordinates: 1/72 of inch. I made the width double, added width options
-for outline and grid, and also now the width ni is isnterpreted as n inches.
+for outline and grid, and also now the width ni is interpreted as n inches.
 
 STATUS:
     FIXED and coming out with the next update

pyproject.toml

@@ -42,6 +42,18 @@ ignore-words-list = [
     "parms",
     "siz",
     "vizual",
+    "ETo",    # Evapotranspiration technical term
+    "Eto",    # Evapotranspiration technical term
+    "eto",    # Evapotranspiration technical term
+    "ist",    # Part of acronyms (IST-SUPSI, etc.)
+    "IHS",    # Color model: Intensity-Hue-Saturation
+    "ihs",    # Color model: Intensity-Hue-Saturation
+    "ALOG",   # Function name
+    "Redner", # Person's name in citation
+    "NED",    # Acronym/proper name
+    "linke",  # Linke turbidity factor parameter
+    "infex",  # Infiltration excess parameter
+    "alle",   # Italian word in references
 ]
 quiet-level = 3
 skip = [

python/grass/docs/README.md

@@ -10,7 +10,7 @@ Install the following dependencies from the `requirements.txt` file: in
 * [sphinx (v8.1.3)](https://www.sphinx-doc.org/en/master/changes/8.1.html)
 * [sphinx-material (v0.0.36)](https://bashtage.github.io/sphinx-material/)
 * [sphinx-sitemap (v2.6.0)](https://sphinx-sitemap.readthedocs.io/en/latest/)
-* [sphinx-last-updated-by-git](hhttps://github.com/mgeier/sphinx-last-updated-by-git/)
+* [sphinx-last-updated-by-git](https://github.com/mgeier/sphinx-last-updated-by-git/)
 
 ```bash
 pip install -r python/grass/docs/requirements.txt

python/grass/docs/_templates/header.html

@@ -1,5 +1,5 @@
-<!-- We need this becasue of the Sphinx variable changed names and Sphinx MkDocs hasn't merge the PR
-Fixing the the problem. See https://github.com/bashtage/sphinx-material/pull/133 -->
+<!-- We need this because of the Sphinx variable changed names and Sphinx MkDocs hasn't merged the PR
+Fixing the problem. See https://github.com/bashtage/sphinx-material/pull/133 -->
 <header class="md-header" data-md-component="header">
     <nav class="md-header-nav md-grid">
         <div class="md-flex navheader">

python/grass/tools/session_tools.py

@@ -604,7 +604,7 @@ def __getattr__(self, name):
         """Get a function representing a GRASS tool.
 
         Attribute should be in the form 'r_example_name'. For example, 'r.slope.aspect'
-        is used trough attribute 'r_slope_aspect'.
+        is used through attribute 'r_slope_aspect'.
         """
         if not self._name_resolver:
             self._name_resolver = ToolFunctionResolver(

raster/r.mapcalc/r.mapcalc.md

@@ -863,7 +863,7 @@ r.mapcalc is parallelized using OpenMP. The number of threads can be controlled
 with the **nprocs** parameter. Note that more complex expressions can benefit
 from more threads. By default (**nprocs=0**), r.mapcalc uses all available threads.
 Use the **--verbose** flag to display the number of threads in use.
-If you observe reduced performance when using many threads, try lowering ther number.
+If you observe reduced performance when using many threads, try lowering the number.
 
 Note: r.mapcalc may disable parallelization in certain cases, even when requested:
 

raster/r.neighbors/r.neighbors.html

@@ -231,7 +231,7 @@ <h3>OPTIONS</h3>
 text file. For example, to calculate the focal mean with a matrix
 <b>size</b> of 3,
 <div class="code"><pre>
-r.neigbors in=input.map out=output.map size=3 weighting_function=file \
+r.neighbors in=input.map out=output.map size=3 weighting_function=file \
 weight=weights.txt
 </pre></div>
 

raster/r.neighbors/r.neighbors.md

@@ -203,7 +203,7 @@ text file. For example, to calculate the focal mean with a matrix
 **size** of 3,
 
 ```sh
-r.neigbors in=input.map out=output.map size=3 weighting_function=file \
+r.neighbors in=input.map out=output.map size=3 weighting_function=file \
 weight=weights.txt
 ```