fix a few typos (again)

4 files changed, 15 insertions, 15 deletions

diff --git a/docs/source/operations/transformations/deformation.rst b/docs/source/operations/transformations/deformation.rst
index 2489f18e..4ae56f54 100644
--- a/docs/source/operations/transformations/deformation.rst
+++ b/docs/source/operations/transformations/deformation.rst
@@ -28,7 +28,7 @@ The deformation operation is used to adjust coordinates for intraplate deformati
 Usually the transformation parameters for regional plate-fixed reference frames such as
 the ETRS89 does not take intraplate deformation into account. It is assumed that
 tectonic plate of the region is rigid. Often times this is true, but near the plate
-boundary and in areas with post-glacial uplift the assumption breaks. Tntraplate
+boundary and in areas with post-glacial uplift the assumption breaks. Intraplate
 deformations can be modelled and then applied to the coordinates so that
 they represent the physical world better. In PROJ this is done with the deformation
 operation.
@@ -43,10 +43,10 @@ Example
 
 In [Häkli2016]_ coordinate transformation including a deformation model is described.
 The paper describes how coordinates from the global ITRFxx frames are transformed to the
-local Nordic realisations of ERTS89. Scandinavia is an area with significant post-glacial
+local Nordic realisations of ETRS89. Scandinavia is an area with significant post-glacial
 rebound. The deformations from the post-glacial uplift is not accounted for in the
-offcial ETRS89 transformations so in order to get accurate transformations in the Nordic
-countries it is necesarry to apply the deformation model. The transformation from ITRF2008
+official ETRS89 transformations so in order to get accurate transformations in the Nordic
+countries it is necessary to apply the deformation model. The transformation from ITRF2008
 to the Danish realisation of ETRS89 is in PROJ described as::
 
     proj =  pipeline ellps = GRS80
@@ -121,7 +121,7 @@ Corrections are done in cartesian space.
 Coordinates of the gridded model are in ENU (east, north, up) space because it would
 otherwise require an enormous 3 dimensional grid to handle the corrections in cartesian
 space. Keeping the correction in lat/long space reduces the complexity of the grid
-significantly. Consequentyly though, the input coordinates needs to be converted to
+significantly. Consequently though, the input coordinates needs to be converted to
 lat/long space when searching for corrections in the grid. This is done with *cart*
 operation. The converted grid corrections can then be applied to the input coordinates
 in cartesian space. The conversion from ENU space to cartesian space is done in the
diff --git a/docs/source/operations/transformations/helmert.rst b/docs/source/operations/transformations/helmert.rst
index 03e5db15..8c862866 100644
--- a/docs/source/operations/transformations/helmert.rst
+++ b/docs/source/operations/transformations/helmert.rst
@@ -25,7 +25,7 @@ anoether by means of 3-, 4-and 7-parameter shifts, or one of their 6-, 8- and
 +----------------+--------------------------------------------------------------------+
 | `rx`           | X-axis rotation in the 3D Helmert [arc seconds]. *Optional*.       |
 +----------------+--------------------------------------------------------------------+
-| `ry`           | Y-axis rotatoin in the 3D Helmert [arc seconds]. *Optional*.       |
+| `ry`           | Y-axis rotation in the 3D Helmert [arc seconds]. *Optional*.       |
 +----------------+--------------------------------------------------------------------+
 | `rz`           | Z-axis rotation in the 3D Helmert [arc seconds]. *Optional*.       |
 +----------------+--------------------------------------------------------------------+
@@ -65,13 +65,13 @@ kinematic transformations from global reference frames to local static frames.
 All of the parameters described in the table above are marked as optional. This is true
 as long as at least one parameter is defined in the setup of the transformation.
 The behaviour of the transformation depends on which parameters are used in the setup.
-For instance, if a rate of change paramater is specified a kinematic version of the
+For instance, if a rate of change parameter is specified a kinematic version of the
 transformation is used.
 
 The kinematic transformations require an observation time of the coordinate, as well
 as a central epoch for the transformation. The latter is usually documented
 alongside the rest of the transformation parameters for a given transformation.
-The central eopch is controlled with the parameter `t_epoch`. The observation
+The central epoch is controlled with the parameter `t_epoch`. The observation
 time can either by stated as part of the coordinate when using PROJ's
 4D-functionality or it can be controlled in the transformation setup by the
 parameter `t_obs`. When `t_obs` is specified, all transformed coordinates are
@@ -131,7 +131,7 @@ The simplest version of the Helmert transform is the 2D case. In the 2-dimension
 case only the horizontal coordinates are changed. The coordinates can be
 translated, rotated and scale. Translation is controlled with the `x` and `y`
 parameters. The rotation is determined by `theta` and the scale is controlled with
-the `s` paramaters.
+the `s` parameters.
 
 .. note::
 
@@ -338,9 +338,9 @@ Applying :eq:`propagation` we get the kinematic version of the approximated
 
 
 The Helmert transformation can be applied without using the rotation parameters,
-in which case it becomes a simlpe translation of the origin of the coordinate
+in which case it becomes a simple translation of the origin of the coordinate
 system. When using the Helmert in this version equation :eq:`general-helmert`
-simplies to:
+simplifies to:
 
 .. math::
     :label: 3param
@@ -364,7 +364,7 @@ simplies to:
     \end{align}
 
 That after application of :eq:`propagation` has the following kinematic
-countpart:
+counterpart:
 
 .. math::
     :label: 6param
diff --git a/docs/source/operations/transformations/hgridshift.rst b/docs/source/operations/transformations/hgridshift.rst
index 7f3c9895..63fa5122 100644
--- a/docs/source/operations/transformations/hgridshift.rst
+++ b/docs/source/operations/transformations/hgridshift.rst
@@ -31,7 +31,7 @@ of the continental US, Alaska and Canada is loaded at the same time::
 
 The ``@`` in the above example states that the grid is optional, in case the grid
 is not found in the PROJ search path. The list of grids is prioritized so that
-grids in the start of the list takes presedence over the grids in the back of the
+grids in the start of the list takes precedence over the grids in the back of the
 list.
 
 PROJ supports CTable2, NTv1 and NTv2 files for horizontal grid corrections. Details
diff --git a/docs/source/operations/transformations/vgridshift.rst b/docs/source/operations/transformations/vgridshift.rst
index e9f78310..c583b273 100644
--- a/docs/source/operations/transformations/vgridshift.rst
+++ b/docs/source/operations/transformations/vgridshift.rst
@@ -26,14 +26,14 @@ reference from the ellipsoid to the global geoid model, EGM96::
 
 More than one grid can be loaded at the same time, for instance in the case where
 a better geoid model than the global is available for a certain area. Here the
-gridshift is set up so that the local DVR90 geoid model takes presedence over
+gridshift is set up so that the local DVR90 geoid model takes precedence over
 the global model::
 
     +vgridshift +grids=@dvr90.gtx,egm96_16.gtx
 
 The ``@`` in the above example states that the grid is optional, in case the grid
 is not found in the PROJ search path. The list of grids is prioritized so that
-grids in the start of the list takes presedence over the grids in the back of the
+grids in the start of the list takes precedence over the grids in the back of the
 list.
 
 PROJ supports the GTX file format for vertical grid corrections. Details