fix a few typos (again)

17 files changed, 54 insertions, 54 deletions

diff --git a/docs/source/contributing.rst b/docs/source/contributing.rst
index 5e198ae7..5f55ed9a 100644
--- a/docs/source/contributing.rst
+++ b/docs/source/contributing.rst
@@ -84,8 +84,8 @@ Note that not all feature requests are accepted.
 Write documentation
 -------------------
 
-PROJ is in dire need of better documentation. Any contributiions of
-documentation are greatly appreaciated. The PROJ documentation is
+PROJ is in dire need of better documentation. Any contributions of
+documentation are greatly appreciated. The PROJ documentation is
 available on `proj4.org <ttp://proj4.org>`__. The website is generated
 with `Sphinx <http://www.sphinx-doc.org/en/stable/>`__. Contributions to
 the documentation should be made as `Pull
@@ -157,7 +157,7 @@ The general rule is to keep whitespace in whatever form it is in the
 file you are currently editing. If the file has a mix of tabs and space
 please convert the tabs to space in a separate commit before making any
 other changes. This makes it a lot easier to see the changes in diffs
-when evaulating the changed code. New files should use spaces as
+when evaluating the changed code. New files should use spaces as
 whitespace.
 
 File names
@@ -237,6 +237,6 @@ Acknowledgements
 
 The *code contribution* section of this CONTRIBUTING file is inspired by
 `PDAL's <https://github.com/PDAL/PDAL/blob/master/CONTRIBUTING.md>`__
-and the *legalese* section is modified from `GDAL contributer
+and the *legalese* section is modified from `GDAL commiter
 guidelines <https://trac.osgeo.org/gdal/wiki/rfc3_commiters>`__
 
diff --git a/docs/source/development/migration.rst b/docs/source/development/migration.rst
index eb509bcf..1ab0a91d 100644
--- a/docs/source/development/migration.rst
+++ b/docs/source/development/migration.rst
@@ -144,7 +144,7 @@ example with the old API the source system is described as
 ``+proj=latlon +ellps=clrk66`` and the destination system is described as
 ``+proj=merc +ellps=clrk66 +lat_ts=33``. Since the Mercator projection accepts
 geodetic coordinates as its input, the description of the source in this case
-is superflous. We use that to our advantage in the new API and simply state
+is superfluous. We use that to our advantage in the new API and simply state
 the destination. This is simple at a glance, but is actually a big conceptual
 change. We are now focused on the path between two systems instead of what the
 source and destination systems are.
diff --git a/docs/source/development/reference/datatypes.rst b/docs/source/development/reference/datatypes.rst
index 7f2c4b41..7ed2da49 100644
--- a/docs/source/development/reference/datatypes.rst
+++ b/docs/source/development/reference/datatypes.rst
@@ -8,7 +8,7 @@ This section describes the numerous data types in use in PROJ.4. As a rule
 of thumb PROJ.4 data types are prefixed with ``PJ_``, or in one particular case,
 is simply called :c:type:`PJ`. A few notable exceptions can be traced
 back to the very early days of PROJ.4 when the ``PJ_`` prefix was not
-consistenly used.
+consistently used.
 
 Transformation objects
 --------------------------------------------------------------------------------
@@ -234,7 +234,7 @@ domain.
 
 .. c:type:: PJ_XYZT
 
-    Generic spatiotemporal coordinate. Usefull for e.g. cartesian coordinates with
+    Generic spatiotemporal coordinate. Useful for e.g. cartesian coordinates with
     an attached time-stamp.
 
     .. code-block:: C
diff --git a/docs/source/development/reference/functions.rst b/docs/source/development/reference/functions.rst
index 38ddbde3..18149139 100644
--- a/docs/source/development/reference/functions.rst
+++ b/docs/source/development/reference/functions.rst
@@ -15,7 +15,7 @@ Threading contexts
 
 .. c:function:: void proj_context_destroy(PJ_CONTEXT *ctx)
 
-    Deallacote a threading-context.
+    Deallocate a threading-context.
 
     :param PJ_CONTEXT* ctx: Threading context.
 
@@ -182,15 +182,15 @@ Coordinate transformation
     :param double* y: Array of y-coordinates
     :param double* z: Array of z-coordinates
     :param double* t: Array of t-coordinates
-    :param size_t sx: Step lenght, in bytes, between consecutive elements of the corresponding array
+    :param size_t sx: Step length, in bytes, between consecutive elements of the corresponding array
     :param size_t nx: Number of elements in the corresponding array
-    :param size_t sy: Step lenght, in bytes, between consecutive elements of the corresponding array
+    :param size_t sy: Step length, in bytes, between consecutive elements of the corresponding array
     :param size_t nv: Number of elements in the corresponding array
-    :param size_t sz: Step lenght, in bytes, between consecutive elements of the corresponding array
+    :param size_t sz: Step length, in bytes, between consecutive elements of the corresponding array
     :param size_t nz: Number of elements in the corresponding array
-    :param size_t st: Step lenght, in bytes, between consecutive elements of the corresponding array
+    :param size_t st: Step length, in bytes, between consecutive elements of the corresponding array
     :param size_t nt: Number of elements in the corresponding array
-    :returns: Number of transformations succesfully completed
+    :returns: Number of transformations successfully completed
 
 
 
@@ -201,7 +201,7 @@ Coordinate transformation
     :param PJ* P:
     :param `direction`: Transformation direction
     :type `direction`: PJ_DIRECTION
-    :param size_t n: Number of cordinates in :c:data:`coord`
+    :param size_t n: Number of coordinates in :c:data:`coord`
     :returns: :c:type:`size_t` 0 if all observations are transformed without error, otherwise returns error number
 
 
diff --git a/docs/source/operations/conversions/unitconvert.rst b/docs/source/operations/conversions/unitconvert.rst
index 73e517bd..50ac832c 100644
--- a/docs/source/operations/conversions/unitconvert.rst
+++ b/docs/source/operations/conversions/unitconvert.rst
@@ -34,7 +34,7 @@ in Vermont::
     +step +proj=tmerc +lat_0=42.5 +lon_0=-72.5 +k=0.999964286 +x_0=500000.00001016 +y_0=0
     +step +proj=unitconvert +xy_in=m +xy_out=us-ft
 
-Often when working with GNNS data the timestamps are presented in GPS-weeks,
+Often when working with GNSS data the timestamps are presented in GPS-weeks,
 but when the data transformed with the `helmert` operation timestamps are
 expected to be in units of decimalyears. This can be fixed with `unitconvert`::
 
@@ -103,7 +103,7 @@ Time units
 In the table below all time units supported by PROJ is listed.
 
 +--------------+-----------------------------+
-| mjd          | Modfied Julian date         |
+| mjd          | Modified Julian date        |
 +--------------+-----------------------------+
 | decimalyear  | Decimal year                |
 +--------------+-----------------------------+
diff --git a/docs/source/operations/pipeline.rst b/docs/source/operations/pipeline.rst
index 18637712..d7694041 100644
--- a/docs/source/operations/pipeline.rst
+++ b/docs/source/operations/pipeline.rst
@@ -41,8 +41,8 @@ been swapped:
 
 Here the first step is applying the :ref:`merc` projection and the second step is
 applying the :ref:`axisswap` conversion. Note that the `+ellps=GRS80` is specified
-before the first occurence of `+step`. This means that the GRS80 ellipsoid is used
-in both steps, since any parameter stated before the first occurence of `+step` is
+before the first occurrence of `+step`. This means that the GRS80 ellipsoid is used
+in both steps, since any parameter stated before the first occurrence of `+step` is
 treated as a global parameter and is transferred to each individual steps.
 
 
diff --git a/docs/source/operations/projections/tpers.rst b/docs/source/operations/projections/tpers.rst
index 345a5faa..13d49cd7 100644
--- a/docs/source/operations/projections/tpers.rst
+++ b/docs/source/operations/projections/tpers.rst
@@ -32,7 +32,7 @@ Tilted perspective
 
 
 Tilted Perspective is similar to :ref:`nsper` (``nsper``) in that it simulates a
-perspective view from a hight. Where ``nsper`` projects onto a plane tangent to
+perspective view from a height. Where ``nsper`` projects onto a plane tangent to
 the surface, Tilted Perspective orients the plane towards the direction of the
 view. Thus, extra parameters azi and tilt are required beyond `nsper``'s ``h``.
 As with ``nsper``, ``lat_0`` & ``lon_0`` are also required
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
diff --git a/docs/source/resource_files.rst b/docs/source/resource_files.rst
index f39604a2..7a961a1a 100644
--- a/docs/source/resource_files.rst
+++ b/docs/source/resource_files.rst
@@ -350,12 +350,12 @@ Init files are used for preconfiguring proj-strings for often used
 transformations, such as those found in the EPSG database. Most init files contain
 transformations from a given coordinate reference system to WGS84. This makes
 it easy to transformations between any two coordinate reference systems with
-``cs2cs``. Init files can however contain any proj-string and don't necesarily
+``cs2cs``. Init files can however contain any proj-string and don't necessarily
 have to follow the *cs2cs* paradigm where WGS84 is used as a pivot datum. The
 ITRF init file is a good example of that.
 
 A number of init files come pre-bundled with PROJ but it is also possible to
-add your own custom init files. PROJ looks for the init files in the directoty
+add your own custom init files. PROJ looks for the init files in the directory
 listed in the ``PROJ_LIB`` environment variable.
 
 The format of init files made up of a identifier in angled brackets and a
@@ -401,7 +401,7 @@ the ellipsoid as in the following example
 
 where the Hayford ellipsoid is used instead of the predefined GRS80 ellipsoid.
 It is also possible to add additional parameters not specified in the init file,
-for instance by adding an obervation epoch when transforming from ITRF2000 to
+for instance by adding an observation epoch when transforming from ITRF2000 to
 ITRF2005:
 
 ::
diff --git a/docs/source/usage/apps/cct.rst b/docs/source/usage/apps/cct.rst
index e6f94526..014e7732 100644
--- a/docs/source/usage/apps/cct.rst
+++ b/docs/source/usage/apps/cct.rst
@@ -15,7 +15,7 @@ program, performs transformation coordinate systems on a set of input points.
 The coordinate system transformation can include  translation  between
 projected  and geographic coordinates as well as the application of datum shifts.
 
-cct is an acromyn meaning *Coordinate Conversion and Transformation*.
+cct is an acronym meaning *Coordinate Conversion and Transformation*.
 
 The acronym refers to definitions given in the OGC 08-015r2/ISO-19111
 standard "Geographical Information -- Spatial Referencing by Coordinates",
@@ -33,7 +33,7 @@ professor of Geodesy at the University of Copenhagen, mentor and advisor
 for a generation of Danish geodesists, colleague and collaborator for
 two generations of global geodesists, Secretary General for the
 International Association of Geodesy, IAG (1995--2007), fellow of the
-Amercan Geophysical Union (1991), recipient of the IAG Levallois Medal
+American Geophysical Union (1991), recipient of the IAG Levallois Medal
 (2007), the European Geosciences Union Vening Meinesz Medal (2008), and
 of numerous other honours.
 
@@ -43,7 +43,7 @@ the development of geodesy -- both through his scientific contributions,
 comprising more than 250 publications, and by his mentoring and teaching
 of the next generations of geodesists.
 
-As Christian was an avid Fortran programmer, and a keen Unix connoiseur,
+As Christian was an avid Fortran programmer, and a keen Unix connoisseur,
 he would have enjoyed to know that his initials would be used to name a
 modest Unix style transformation filter, hinting at the tireless aspect
 of his personality, which was certainly one of the reasons he accomplished
diff --git a/docs/source/usage/environmentvars.rst b/docs/source/usage/environmentvars.rst
index e1d63543..24954158 100644
--- a/docs/source/usage/environmentvars.rst
+++ b/docs/source/usage/environmentvars.rst
@@ -4,7 +4,7 @@
 Environment variables
 ================================================================================
 
-PROJ can be crontrolled by setting environment variables. Most users will
+PROJ can be controlled by setting environment variables. Most users will
 have a use for the :envvar:`PROJ_LIB`.
 
 On UNIX systems environment variables can be set for a shell-session with::
diff --git a/docs/source/usage/projections.rst b/docs/source/usage/projections.rst
index 871bc161..f5f46f46 100644
--- a/docs/source/usage/projections.rst
+++ b/docs/source/usage/projections.rst
@@ -93,7 +93,7 @@ Prime Meridian
 
 A prime meridian may be declared indicating the offset between the prime
 meridian of the declared coordinate system and that of greenwich.  A prime
-meridian is clared using the "pm" parameter, and may be assigned a symbolic
+meridian is declared using the "pm" parameter, and may be assigned a symbolic
 name, or the longitude of the alternative prime meridian relative to greenwich.
 
 Currently prime meridian declarations are only utilized by the
diff --git a/docs/source/usage/quickstart.rst b/docs/source/usage/quickstart.rst
index 077e970c..89ac2172 100644
--- a/docs/source/usage/quickstart.rst
+++ b/docs/source/usage/quickstart.rst
@@ -33,7 +33,7 @@ utility ``proj`` we can convert the geodetic coordinates to projected space:
     $ proj +proj=merc +lat_ts=56.5 +ellps=GRS80
 
 If called as above ``proj`` will be in interactive mode, letting you type the
-input data manually and getting a responce presented on screen. ``proj``
+input data manually and getting a response presented on screen. ``proj``
 works as any UNIX filter though, which means that you can also pipe data to
 the utility, for instance by using the ``echo`` command:
 
@@ -44,7 +44,7 @@ the utility, for instance by using the ``echo`` command:
 
 
 PROJ also comes bundled with the ``cs2cs`` utility which is used to transform
-from onecoordinate reference system to another. Say we want to convert
+from one coordinate reference system to another. Say we want to convert
 the above Mercator coordinates to UTM, we can do that with ``cs2cs``:
 
 ::
@@ -52,10 +52,10 @@ the above Mercator coordinates to UTM, we can do that with ``cs2cs``:
     $ echo 3399483.80 752085.60 | cs2cs +proj=merc +lat_ts=56.5 +ellps=GRS80 +to +proj=utm +zone=32
     6103992.36      1924052.47 0.00
 
-Notice the ``+to`` parameter that seperates the source and destination
+Notice the ``+to`` parameter that separates the source and destination
 projection definitions.
 
-If you happen to know the EPSG identifiers for the two cordinates reference
+If you happen to know the EPSG identifiers for the two coordinates reference
 systems you are transforming between you can use those with ``cs2cs``:
 
 ::
diff --git a/docs/source/usage/transformation.rst b/docs/source/usage/transformation.rst
index fd1f2f94..bd32bcd9 100644
--- a/docs/source/usage/transformation.rst
+++ b/docs/source/usage/transformation.rst
@@ -6,11 +6,11 @@ Geodetic transformation
 
 PROJ can do everything from the most simple projection to very complex
 transformations across many reference frames. While originally developed as a
-tool for cartographic projections, PROJ has over time evolved into a powerfull
+tool for cartographic projections, PROJ has over time evolved into a powerful
 generic coordinate transformation engine that makes it possible to do both
 large scale cartographic projections as well as coordinate transformation at a
 geodetic high precision level. This chapter delves into the details of how
-geodetec transformations of varying complexity can be performed.
+geodetic transformations of varying complexity can be performed.
 
 In PROJ, two frameworks for geodetic transformations exists, the *cs2cs*
 framework and the *transformation pipelines* framework. The first is the original,
@@ -69,7 +69,7 @@ solutions for a wide spectrum of geodetic tasks.
 
 As a first example, let us take a look at the iconic
 *geodetic → Cartesian → Helmert → geodetic* case (steps 2 to 4 in the example in
-the itroduction). In PROJ it can be implemented as
+the introduction). In PROJ it can be implemented as
 
 ::
 
@@ -161,11 +161,11 @@ specified in the input proj-string. The most common is ``+towgs84``, which is us
 define a 3- or 7-parameter Helmert shift from the input reference frame to WGS84.
 Exactly which realization of WGS84 is not specified, hence a fair amount of
 uncertainty is introduced in this step of the transformation. With the +nadgrids
-parameter a non-lineaer planar correction derived from interpolation in a
+parameter a non-linear planar correction derived from interpolation in a
 correction grid can be applied. Originally this was implemented as a means to
-transform coordinates between the american datums NAD27 and NAD83, but corrections
-can be applied for any datum for which a correction grid exists. The inverse
-transform for the horizontal grid shift is "dumb", in the sense that the
+transform coordinates between the North American datums NAD27 and NAD83, but
+corrections can be applied for any datum for which a correction grid exists. The
+inverse transform for the horizontal grid shift is "dumb", in the sense that the
 correction grid is applied verbatim without taking into account that the inverse
 operation is non-linear. Similar to the horizontal grid correction, ``+geoidgrids``
 can be used to perform grid corrections in the vertical component.
@@ -203,7 +203,7 @@ using an approximated 7 parameter transformation.
 Grid Based Datum Adjustments
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-In many places (notably North America and Austrialia) national geodetic
+In many places (notably North America and Australia) national geodetic
 organizations provide grid shift files for converting between different datums,
 such as NAD27 to NAD83.  These grid shift files include a shift to be applied
 at each grid location. Actually grid shifts are normally computed based on an