fix a few typos in the docs

12 files changed, 16 insertions, 16 deletions

diff --git a/docs/source/community/code_contributions.rst b/docs/source/community/code_contributions.rst
index 17d358ee..7f8c88fa 100644
--- a/docs/source/community/code_contributions.rst
+++ b/docs/source/community/code_contributions.rst
@@ -60,7 +60,7 @@ Coding style
 ^^^^^^^^^^^^
 
 The parts of the code base that has started its life as C++ is formatted with
-``clang-format`` using the sript ``scripts/reformat_cpp.sh``. This is mostly
+``clang-format`` using the script ``scripts/reformat_cpp.sh``. This is mostly
 contained to the code in `src/iso19111/` but a few other `.cpp`-files are
 covered as well.
 
diff --git a/docs/source/development/reference/datatypes.rst b/docs/source/development/reference/datatypes.rst
index ed219daf..cb90e8db 100644
--- a/docs/source/development/reference/datatypes.rst
+++ b/docs/source/development/reference/datatypes.rst
@@ -824,7 +824,7 @@ Errors in class PROJ_ERR_INVALID_OP
 
 .. c:macro:: PROJ_ERR_INVALID_OP
 
-    Class of error codes typically related to coordinate operation initalization,
+    Class of error codes typically related to coordinate operation initialization,
     typically when creating a PJ* object from a PROJ string.
 
     .. note:: some of them can also be emitted during coordinate transformation,
diff --git a/docs/source/development/reference/functions.rst b/docs/source/development/reference/functions.rst
index 34fe59ed..d06179f3 100644
--- a/docs/source/development/reference/functions.rst
+++ b/docs/source/development/reference/functions.rst
@@ -180,7 +180,7 @@ paragraph for more details.
     coordinate reference systems.
 
     This is the same as :c:func:`proj_create_crs_to_crs` except that the source and
-    target CRS are passed as PJ* objects which must of the CRS variety.
+    target CRS are passed as PJ* objects which must be of the CRS variety.
 
     :param `options`: a list of NUL terminated options, or NULL.
 
@@ -285,7 +285,7 @@ Coordinate transformation
         3. of length one, i.e. a constant, which will be treated as a fully
            populated array of that constant value
 
-    .. note:: Even though he coordinate components are named :c:data:`x`, :c:data:`y`,
+    .. note:: Even though the coordinate components are named :c:data:`x`, :c:data:`y`,
               :c:data:`z` and :c:data:`t`, axis ordering of the to and from CRS
               is respected. Transformations exhibit the same behavior
               as if they were gathered in a :c:type:`PJ_COORD` struct.
diff --git a/docs/source/operations/conversions/cart.rst b/docs/source/operations/conversions/cart.rst
index 111eb7d2..239b1772 100644
--- a/docs/source/operations/conversions/cart.rst
+++ b/docs/source/operations/conversions/cart.rst
@@ -21,7 +21,7 @@ Convert geodetic coordinates to cartesian coordinates (in the forward path).
 This conversion converts geodetic coordinate values (longitude, latitude,
 elevation above ellipsoid) to their geocentric (X, Y, Z) representation, where
 the first axis (X) points from the Earth centre to the point of longitude=0,
-latitude=0, the second axis (Y) points from the Earth centrer to the point of
+latitude=0, the second axis (Y) points from the Earth centre to the point of
 longitude=90, latitude=0 and the third axis (Z) points to the North pole.
 
 Usage
diff --git a/docs/source/operations/operations_computation.rst b/docs/source/operations/operations_computation.rst
index f1453257..af177f6c 100644
--- a/docs/source/operations/operations_computation.rst
+++ b/docs/source/operations/operations_computation.rst
@@ -27,7 +27,7 @@ This document is meant as a plain text explanation of the code for developers,
 but also as a in-depth examination of what happens under the hood for curious PROJ
 users. It is important to keep in mind that it is not meant to be the ultimate
 source of truth of how coordinate operations should be computed. There are clearly
-implementation choices and compromises that can be questionned.
+implementation choices and compromises that can be questioned.
 
 Let us start with an example to research operations between the NAD27 and NAD83
 geographic CRS:
@@ -123,7 +123,7 @@ must be retained or discarded:
 
 The sorting algorithm determines the order of relevance of the operations we got.
 A comparison function compares pair of operations to determine which of the
-two is the most releavant. This is implemented by the :cpp:func:`operator ()`
+two is the most relevant. This is implemented by the :cpp:func:`operator ()`
 method of the SortFunction structure.
 When comparing two operations, the following criteria are used. The tests are
 performed in the order they are listed below:
@@ -163,7 +163,7 @@ In a number of situations, the source and/or target CRS do not have an identifie
 The first step is to try to find in the ``proj.db`` a CRS of the same nature of
 the CRS to identify and whose name exactly matches the one provided to the
 :c:func:`createOperations` method. If there is exactly one match and that the CRS are
-"computationnaly" equivalent, then use the code of the CRS for further computations.
+"computationally" equivalent, then use the code of the CRS for further computations.
 
 If this search did not succeed, or if the previous case with known CRS identifiers
 did not result in matches in the database, the search will be based on the
@@ -195,7 +195,7 @@ one can define a geographic 2D CRS (latitude, longitude), a geographic 3D crs
 case, the EPSG dataset has also included two extra definitions corresponding to a
 longitude, latitude, [ellipsoidal height] coordinate system, as found in the official
 French IGNF registry. This IGNF registry has also definitions for a geographic 2D
-CRS (with an extra subtelty with an entry using decimal degree as unit and another
+CRS (with an extra subtlety with an entry using decimal degree as unit and another
 one degree-minute-second), geographic 3D and geocentric.
 
 For EPSG:6258, there are 7 matching (non-deprecated) geodetic CRSs: 
diff --git a/docs/source/operations/transformations/affine.rst b/docs/source/operations/transformations/affine.rst
index 8b1681b3..d2a4e26b 100644
--- a/docs/source/operations/transformations/affine.rst
+++ b/docs/source/operations/transformations/affine.rst
@@ -7,7 +7,7 @@ Affine transformation
 .. versionadded:: 6.0.0
 
 The affine transformation applies translation and scaling/rotation terms on the
-x,y,z coordinates, and translation and scaling on the temporal cordinate.
+x,y,z coordinates, and translation and scaling on the temporal coordinate.
 
 +---------------------+----------------------------------------------------------+
 | **Alias**           | affine                                                   |
diff --git a/docs/source/operations/transformations/defmodel.rst b/docs/source/operations/transformations/defmodel.rst
index a3f75d93..77906924 100644
--- a/docs/source/operations/transformations/defmodel.rst
+++ b/docs/source/operations/transformations/defmodel.rst
@@ -56,7 +56,7 @@ Required
 Example
 -------------------------------------------------------------------------------
 
-Transformating a point with the LINZ NZGD2000 deformation model:
+Transforming a point with the LINZ NZGD2000 deformation model:
 
 ::
 
diff --git a/docs/source/operations/transformations/deformation.rst b/docs/source/operations/transformations/deformation.rst
index e6cb9b88..84b87949 100644
--- a/docs/source/operations/transformations/deformation.rst
+++ b/docs/source/operations/transformations/deformation.rst
@@ -167,7 +167,7 @@ represented as a grid of velocities in three dimensions. Coordinate corrections
 applied in cartesian space. For a given coordinate, :math:`(X, Y, Z)`, velocities
 :math:`(V_X, V_Y, V_Z)` can be interpolated from the gridded model. The time span
 between :math:`t_{obs}` and :math:`t_c` determine the magnitude of the coordinate
-correcton as seen in eq. :eq:`apply_velocity` below.
+correction as seen in eq. :eq:`apply_velocity` below.
 
 .. math::
     :label: apply_velocity
diff --git a/docs/source/operations/transformations/helmert.rst b/docs/source/operations/transformations/helmert.rst
index 34acc332..c0f6934f 100644
--- a/docs/source/operations/transformations/helmert.rst
+++ b/docs/source/operations/transformations/helmert.rst
@@ -349,7 +349,7 @@ For :math:`\mathbf{R}`, this yields:
      \end{bmatrix}
 
 
-Using the small angle approxition the rotation matrix can be simplified to
+Using the small angle approximation the rotation matrix can be simplified to
 
 .. math::
     :label: rot_approx
diff --git a/docs/source/operations/transformations/horner.rst b/docs/source/operations/transformations/horner.rst
index 5c88c292..ad09e8ab 100644
--- a/docs/source/operations/transformations/horner.rst
+++ b/docs/source/operations/transformations/horner.rst
@@ -17,7 +17,7 @@ Horner polynomial evaluation
 +-----------------+-------------------------------------------------------------------+
 
 The Horner polynomial evaluation scheme is used for transformations between reference
-frames where one or both are inhomogenous or internally distorted. This will typically
+frames where one or both are inhomogeneous or internally distorted. This will typically
 be reference frames created before the introduction of space geodetic techniques such
 as GPS.
 
diff --git a/docs/source/operations/transformations/tinshift.rst b/docs/source/operations/transformations/tinshift.rst
index c29d233a..ee7ae4a6 100644
--- a/docs/source/operations/transformations/tinshift.rst
+++ b/docs/source/operations/transformations/tinshift.rst
@@ -43,7 +43,7 @@ Required
 Example
 -------------------------------------------------------------------------------
 
-Transformating a point with the Finland EPSG:2393 ("KKJ / Finland Uniform
+Transforming a point with the Finland EPSG:2393 ("KKJ / Finland Uniform
 Coordinate System") projected CRS to EPSG:3067 ("ETRS89 / TM35FIN(E,N)")
 
 ::
diff --git a/docs/source/operations/transformations/vgridshift.rst b/docs/source/operations/transformations/vgridshift.rst
index d4f1f97f..5a31ae8f 100644
--- a/docs/source/operations/transformations/vgridshift.rst
+++ b/docs/source/operations/transformations/vgridshift.rst
@@ -126,7 +126,7 @@ Optional
         Z_{target} = Z_{source} + multiplier \times gridvalue
 
     The multiplier can be used to control whether the gridvalue should be added
-    or sustracted, and if unit conversion must be done (the multiplied gridvalue
+    or subtracted, and if unit conversion must be done (the multiplied gridvalue
     must be expressed in metre).
 
     Note that the default is `-1.0` for historical reasons.