scripts/fix_typos.sh: fix URLs to dictionaries, and fix typos spotted

20 files changed, 42 insertions, 42 deletions

diff --git a/docs/source/apps/projsync.rst b/docs/source/apps/projsync.rst
index 9756e0c4..d79bd87b 100644
--- a/docs/source/apps/projsync.rst
+++ b/docs/source/apps/projsync.rst
@@ -110,7 +110,7 @@ The following control parameters can appear in any order:
 
 .. option:: --dry-run
 
-    Simulate the behaviour of the tool without downloading resource files.
+    Simulate the behavior of the tool without downloading resource files.
 
 .. option:: --list-files
 
diff --git a/docs/source/community/rfc/rfc-2.rst b/docs/source/community/rfc/rfc-2.rst
index df6f742d..4cea339d 100644
--- a/docs/source/community/rfc/rfc-2.rst
+++ b/docs/source/community/rfc/rfc-2.rst
@@ -405,7 +405,7 @@ be combined together.
     - `alias_names`: list possible alias for the `name` field of object table
     - `link_from_deprecated_to_non_deprecated`: to handle the link between old ESRI to new ESRI/EPSG codes
 
-- Commmon:
+- Common:
     - `unit_of_measure`: table with UnitOfMeasure definitions.
     - `area`: table with area-of-use (bounding boxes) applicable to CRS and coordinate operations.
 
diff --git a/docs/source/community/rfc/rfc-3.rst b/docs/source/community/rfc/rfc-3.rst
index d3e3d14c..ae4bff95 100644
--- a/docs/source/community/rfc/rfc-3.rst
+++ b/docs/source/community/rfc/rfc-3.rst
@@ -120,7 +120,7 @@ development, but it is allowed in case future development of PROJ warrants an
 update. Changes in minimum version requirements are allowed to happen with
 minor version releases of PROJ.
 
-At the time of writing the minimum version requried for SQLite it 3.7 which was
+At the time of writing the minimum version required for SQLite it 3.7 which was
 released in 2010. CMake currently is required to be at least at version 2.8.3
 which was also released in 2010.
 
diff --git a/docs/source/community/rfc/rfc-4.rst b/docs/source/community/rfc/rfc-4.rst
index 88abbe9e..0819c6f1 100644
--- a/docs/source/community/rfc/rfc-4.rst
+++ b/docs/source/community/rfc/rfc-4.rst
@@ -70,7 +70,7 @@ Summary of work planned by this RFC
   implemented.
 
 The use of grids locally available will of course still be available, and will
-be the default behaviour. 
+be the default behavior. 
 
 Network access to grids
 -------------------------------------------------------------------------------
@@ -220,7 +220,7 @@ The preliminary C API for the above is:
 To make network access efficient, PROJ will internally have a in-memory cache
 of file ranges to only issue network requests by chunks of 16 KB or multiple of them,
 to limit the number of HTTP GET requests and minimize latency caused by network
-access. This is very similar to the behaviour of the GDAL
+access. This is very similar to the behavior of the GDAL
 `/vsicurl/ <https://gdal.org/user/virtual_file_systems.html#vsicurl-http-https-ftp-files-random-access>`_
 I/O layer. The plan is to mostly copy GDAL's vsicurl implementation inside PROJ, with
 needed adjustmeents and proper namespacing of it.
@@ -495,7 +495,7 @@ Several formats exist depending on the ad-hoc needs and ideas of the original
 data producer. It would be appropriate to converge on a common format able to
 address the different use cases.
 
-- Not tiled. Tiling is a nice to have propery for cloud-friendly access to
+- Not tiled. Tiling is a nice to have property for cloud-friendly access to
   large files.
 - No support for compression
 - The NTv2 structures is roughly: header of main grid, data of main grid,
@@ -511,13 +511,13 @@ Discussion on choice of format
 We have been made recently aware of other initiatives from the industry to come
 with a common format to store geodetic adjustment data. Some discussions have
 happen recently within the OGC CRS Working group. Past efforts include the
-Esri's proposed Geodetic data Grid eXchange Format, GGXF, briefly mentionned at
+Esri's proposed Geodetic data Grid eXchange Format, GGXF, briefly mentioned at
 page 86 of
 https://iag.dgfi.tum.de/fileadmin/IAG-docs/Travaux2015/01_Travaux_Template_Comm_1_tvd.pdf
 and page 66 of ftp://ftp.iaspei.org/pub/meetings/2010-2019/2015-Prague/IAG-Geodesy.pdf
 The current trend of those works would be to use a netCDF / HDF5 container.
 
-So, for the sake of completness, we list hereafter a few potential candidate
+So, for the sake of completeness, we list hereafter a few potential candidate
 formats and their pros and cons.
 
 TIFF/GeoTIFF
@@ -610,7 +610,7 @@ Weak points:
   metadata <http://cfconventions.org/>`_
   but there is nothing really handy in them for simple georeferencing with
   the coordinate of the upper-left pixel and the resolution. The practice is
-  to write explict lon and lat variables with all values taken by the grid.
+  to write explicit lon and lat variables with all values taken by the grid.
   GDAL has for many years supported a simpler syntax, using a GeoTransform
   attribute.
 
@@ -652,7 +652,7 @@ Weak points:
   is more complex than netCDF v3, and likely more than TIFF. We do not have
   in-depth expertise of it to assess its cloud-friendliness.
 
-* The ones mentionned for netCDF v3 regarding georeferencing and security apply.
+* The ones mentioned for netCDF v3 regarding georeferencing and security apply.
 
 
 GeoPackage
@@ -719,7 +719,7 @@ Build requirements
 
 The minimum libtiff version will be 4.0 (RHEL 7 ships with libtiff 4.0.3).
 To be able to read grids stored on the CDN, libtiff will need to build against
-zlib to have DEFLATE and LZW suport, which is met by all known binary distributions
+zlib to have DEFLATE and LZW support, which is met by all known binary distributions
 of libtiff.
 
 The libtiff dependency can be disabled at build time, but this must be
diff --git a/docs/source/community/rfc/rfc-5.rst b/docs/source/community/rfc/rfc-5.rst
index 99fec5f7..6e9bf5b7 100644
--- a/docs/source/community/rfc/rfc-5.rst
+++ b/docs/source/community/rfc/rfc-5.rst
@@ -96,7 +96,7 @@ Backward compatibility
 This change is considered to be *mostly* backward compatible. There might be
 impacts for software using :cpp:func:`proj_coordoperation_get_grid_used` and
 assuming that the url returned is one of the proj-datumgrid-xxx files at
-https://download.osgeo.org. As mentionned in
+https://download.osgeo.org. As mentioned in
 https://lists.osgeo.org/pipermail/proj/2020-January/009274.html , this
 assumption was not completely bullet-proof either.
 There will be impacts on software checking the value of PROJ pipeline strings
diff --git a/docs/source/development/reference/functions.rst b/docs/source/development/reference/functions.rst
index 960ed57e..d5611c9a 100644
--- a/docs/source/development/reference/functions.rst
+++ b/docs/source/development/reference/functions.rst
@@ -276,7 +276,7 @@ Coordinate transformation
 
     .. note:: Even though he 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 behaviour
+              is respected. Transformations exhibit the same behavior
               as if they were gathered in a :c:type:`PJ_COORD` struct.
 
 
diff --git a/docs/source/faq.rst b/docs/source/faq.rst
index cd545036..5a6763bc 100644
--- a/docs/source/faq.rst
+++ b/docs/source/faq.rst
@@ -188,6 +188,6 @@ was no longer aligned with the version number. As a consequence, it was
 decided to decouple the name from the version number and once again simply
 call the software PROJ.
 
-Use of name PROJ.4 is now strictly reserved for describing legacy behaviour
+Use of name PROJ.4 is now strictly reserved for describing legacy behavior
 of the software, e.g. "PROJ.4 strings" as seen in :program:`projinfo`
 output.
diff --git a/docs/source/install.rst b/docs/source/install.rst
index f6ca0d5d..dd57d22c 100644
--- a/docs/source/install.rst
+++ b/docs/source/install.rst
@@ -212,7 +212,7 @@ Autotools configure options
 
 Most POSIX systems may not require any options to ``./configure`` if all
 PROJ requirements are met, installed into common directories, and a
-"default" behaviour is desired.
+"default" behavior is desired.
 
 Some influential environment variables are used by ``./configure``,
 with no expected defaults:
diff --git a/docs/source/news.rst b/docs/source/news.rst
index c54232ef..3e135cba 100644
--- a/docs/source/news.rst
+++ b/docs/source/news.rst
@@ -167,7 +167,7 @@ Bug fixes
 The major feature in PROJ 7 is significantly improved handling of gridded
 models. This was implemented in :ref:`RFC4`.
 The main features of the RFC4 work is that PROJ now implements a new grid format,
-Geodetic TIFF grids, for exchaning gridded transformation models. In addition
+Geodetic TIFF grids, for exchanging gridded transformation models. In addition
 to the new grid format, PROJ can now also access grids online using a data
 store in the cloud.
 
@@ -530,7 +530,7 @@ Bug Fixes
 * Do not include :envvar:`PROJ_LIB` in ``proj_info().searchpath`` when context
   search path is set (`#1498 <https://github.com/OSGeo/PROJ/issues/1498>`_)
 
-* Use correct delimeter for the current platform when parsing
+* Use correct delimiter for the current platform when parsing
   PROJ_LIB (`#1497 <https://github.com/OSGeo/PROJ/issues/1497>`_)
 
 * Do not confuse 'ID74' CRS with WKT2 ID[] node (`#1506 <https://github.com/OSGeo/PROJ/issues/1506>`_)
@@ -691,15 +691,15 @@ UPDATES
 * Removed :c:func:`proj_geocentric_latitude` from `proj.h` API
   (`#1170 <https://github.com/OSGeo/proj.4/issues/1170>`_)
 
-* Changed behaviour of :program:`proj`: Now only allow initialization of
+* Changed behavior of :program:`proj`: Now only allow initialization of
   projections (`#1162 <https://github.com/OSGeo/proj.4/issues/1162>`_)
 
-* Changed behaviour of :ref:`tmerc <tmerc>`: Now defaults to the Extended
+* Changed behavior of :ref:`tmerc <tmerc>`: Now defaults to the Extended
   Transverse Mercator algorithm (``etmerc``). Old implementation available
   by adding ``+approx``
   (`#404 <https://github.com/OSGeo/proj.4/issues/404>`_)
 
-* Chaged behaviour: Default ellipsoid now set to GRS80 (was WGS84) (`#1210 <https://github.com/OSGeo/proj.4/issues/1210>`_)
+* Chaged behavior: Default ellipsoid now set to GRS80 (was WGS84) (`#1210 <https://github.com/OSGeo/proj.4/issues/1210>`_)
 
 * Allow multiple directories in :envvar:`PROJ_LIB` environment variable (`#1281 <https://github.com/OSGeo/proj.4/issues/1281>`_)
 
diff --git a/docs/source/operations/operations_computation.rst b/docs/source/operations/operations_computation.rst
index 2836b75c..f1453257 100644
--- a/docs/source/operations/operations_computation.rst
+++ b/docs/source/operations/operations_computation.rst
@@ -135,7 +135,7 @@ performed in the order they are listed below:
    ballpark vertical transformation (occurs when there is a geoid model).
 3. if both operations evaluate identically with respect to the above criterion,
    consider as more relevant an operation that does not include a synthetic
-   ballpark horizontal tranformation.
+   ballpark horizontal transformation.
 4. consider as more relevant an operation that refers to shift grids that are locally available.
 5. consider as more relevant an operation that refers to grids that are available
    in one of the proj-datumgrid packages, but not necessarily locally available
@@ -149,7 +149,7 @@ performed in the order they are listed below:
 10. in case of same accuracy, consider as more relevant an operation that does
     not use grids (operations that use only parameters will be faster)
 11. consider as more relevant an operation that involves less transformation steps
-12. and for completness, if two operations are comparable given all the above criteria,
+12. and for completeness, if two operations are comparable given all the above criteria,
     consider as more relevant the one which has the shorter name, and if they
     have the same length, consider as more relevant the one whose name comes first in
     lexicographic order (obviously completely arbitrary, but a sorting
@@ -403,7 +403,7 @@ following results for the AGD84 to GDA2020 coordinate operations lookup:
                    +step +proj=axisswap +order=2,1
 
 One can see that the selected intermediate CRS that has been used is GDA94.
-This is a completely novel behaviour of PROJ 6 as opposed to the logic of PROJ.4 
+This is a completely novel behavior of PROJ 6 as opposed to the logic of PROJ.4 
 where datum transformations implied using EPSG:4326 / WGS 84 has the mandatory
 datum hub. PROJ 6 no longer hardcodes it as the mandatory datum hub, and relies
 on the database to find the appropriate hub(s).
@@ -468,7 +468,7 @@ techniques, we would only find one non-ballpark operation taking the route:
 
 This is not bad, but the global validity area of use is "Australia - onshore and EEZ",
 whereas GDA94 has a larger area of use.
-There is another road that can be taken by going throug GDA2020 instead of ITRF2008.
+There is another road that can be taken by going through GDA2020 instead of ITRF2008.
 The GDA94 to GDA2020 transformations operate on the respective geographic CRS,
 whereas GDA2020 to WGS 84 (G1762) operate on the geocentric CRS. Consequently,
 GDA2020 cannot be identifier as a hub by a "simple" self-join SQL request on
@@ -508,7 +508,7 @@ particular case. Such transformations are done in 2 steps:
 
 This is implemented by the ``createOperationsDerivedTo`` method
 
-For the symetric case, source CRS to a derived CRS, the above algorithm is applied
+For the symmetric case, source CRS to a derived CRS, the above algorithm is applied
 by switching the source and target CRS, and then inverting the resulting operation(s).
 This is mostly a matter of avoiding to write very similar code twice. This logic
 is also applied to all below cases when considering the transformation between 2 different
@@ -659,7 +659,7 @@ CompoundCRS to CompoundCRS
 There is some similarity with the previous paragraph. We first research the
 vertical transformations between the two vertical CRS.
 
-1. If there is such a tranformation, be it direct, or if both vertical CRS
+1. If there is such a transformation, be it direct, or if both vertical CRS
    relate to a common intermediate CRS.
    If it has a registered interpolation geographic CRS, then it is used.
    Otherwise we fallback to the geographic CRS of the source CRS.
diff --git a/docs/source/operations/transformations/helmert.rst b/docs/source/operations/transformations/helmert.rst
index 51784bdb..34acc332 100644
--- a/docs/source/operations/transformations/helmert.rst
+++ b/docs/source/operations/transformations/helmert.rst
@@ -33,7 +33,7 @@ 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.
+The behavior of the transformation depends on which parameters are used in the setup.
 For instance, if a rate of change parameter is specified a kinematic version of the
 transformation is used.
 
diff --git a/docs/source/operations/transformations/molodensky.rst b/docs/source/operations/transformations/molodensky.rst
index 347165c8..df0b00a2 100644
--- a/docs/source/operations/transformations/molodensky.rst
+++ b/docs/source/operations/transformations/molodensky.rst
@@ -10,7 +10,7 @@ The Molodensky transformation resembles a :ref:`Helmert` with zero
 rotations and a scale of unity, but converts directly from geodetic coordinates to
 geodetic coordinates, without the intermediate shifts to and from cartesian
 geocentric coordinates, associated with the Helmert transformation.
-The Molodensky transformation is simple to implement and to parameterize, requiring
+The Molodensky transformation is simple to implement and to parametrize, requiring
 only the 3 shifts between the input and output frame, and the corresponding
 differences between the semimajor axes and flattening parameters of the reference
 ellipsoids. Due to its algorithmic simplicity, it was popular prior to the
diff --git a/docs/source/resource_files.rst b/docs/source/resource_files.rst
index cef22f84..ab8b149c 100644
--- a/docs/source/resource_files.rst
+++ b/docs/source/resource_files.rst
@@ -23,7 +23,7 @@ PROJ will attempt to locate its resource files - database, transformation grids
 or init-files - from several directories.
 The following paths are checked in order:
 
-- For resource files that have an explict relative or absolute path,
+- For resource files that have an explicit relative or absolute path,
   the directory specified in the filename.
 
 - Path resolved by the callback function set with
diff --git a/docs/source/specifications/geodetictiffgrids.rst b/docs/source/specifications/geodetictiffgrids.rst
index 479d6ca9..861e8b82 100644
--- a/docs/source/specifications/geodetictiffgrids.rst
+++ b/docs/source/specifications/geodetictiffgrids.rst
@@ -90,7 +90,7 @@ is an easy way to inspect such grid files:
   half-pixel shift regarding to the coordinates stored in the original grid file. On
   the reading side, PROJ will accept both conventions (for equivalent georeferencing,
   the value of the origin in a PixelIsArea convention is shifted by a half-pixel
-  towards the upper-left direction). Unspecified behaviour if this GeoKey is absent.
+  towards the upper-left direction). Unspecified behavior if this GeoKey is absent.
 
 - Files hosted on the CDN will be tiled, presumably with 256x256 tiles (small
   grids that are smaller than 256x256 will use a single strip). On the reading
@@ -601,9 +601,9 @@ will be followed by:
 .. note::
 
     TIFF has another mechanism to link IFDs, the SubIFD tag. This potentially
-    enables to define a hiearchy of IFDs (similar to HDF5 groups). There is no
+    enables to define a hierarchy of IFDs (similar to HDF5 groups). There is no
     support for that in most TIFF-using software, notably GDAL, and no compelling
-    need to have a nested hiearchy, so "flat" organization with the standard IFD chaining
+    need to have a nested hierarchy, so "flat" organization with the standard IFD chaining
     mechanism is adopted.
 
 Examples of multi-grid dataset
diff --git a/docs/source/specifications/projjson.rst b/docs/source/specifications/projjson.rst
index 6bcce585..3484fce9 100644
--- a/docs/source/specifications/projjson.rst
+++ b/docs/source/specifications/projjson.rst
@@ -75,7 +75,7 @@ Examples
 GeographicCRS
 +++++++++++++
 
-The following invokation
+The following invocation
 
 ::
 
@@ -132,7 +132,7 @@ will output:
 ProjectedCRS
 ++++++++++++
 
-The following invokation
+The following invocation
 
 ::
 
diff --git a/docs/source/usage/differences.rst b/docs/source/usage/differences.rst
index 2a262232..11bab0b5 100644
--- a/docs/source/usage/differences.rst
+++ b/docs/source/usage/differences.rst
@@ -4,10 +4,10 @@
 Known differences between versions
 ================================================================================
 
-Once in a while, a new version of PROJ causes changes in the existing behaviour.
+Once in a while, a new version of PROJ causes changes in the existing behavior.
 In this section we track deliberate changes to PROJ that break from previous
-behaviour. Most times that will be caused by a bug fix. Unfortunately, some bugs
-have existed for so long that their faulty behaviour is relied upon by software
+behavior. Most times that will be caused by a bug fix. Unfortunately, some bugs
+have existed for so long that their faulty behavior is relied upon by software
 that uses PROJ.
 
 Behavioural changes caused by new bugs are not tracked here, as they should be
@@ -57,7 +57,7 @@ rotation of the circle larger than :math:`\lambda=-70^{\circ}` and hence
 should return the same output for both.
 
 Adding the ``+over`` flag to the projection definition provides
-the old behaviour.
+the old behavior.
 
 Version 6.0.0
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diff --git a/docs/source/usage/environmentvars.rst b/docs/source/usage/environmentvars.rst
index 31a74e9a..e519a80b 100644
--- a/docs/source/usage/environmentvars.rst
+++ b/docs/source/usage/environmentvars.rst
@@ -48,7 +48,7 @@ done by setting the variable with no content::
 
     Starting with PROJ version 6.1.0, the paths set by
     :func:`proj_context_set_search_paths` will have priority over the
-    :envvar:`PROJ_LIB` to allow for mutliple versions of PROJ
+    :envvar:`PROJ_LIB` to allow for multiple versions of PROJ
     resource files on your system without conflicting.
 
 .. envvar:: PROJ_DEBUG
diff --git a/docs/source/usage/network.rst b/docs/source/usage/network.rst
index 1b42d0aa..98461c69 100644
--- a/docs/source/usage/network.rst
+++ b/docs/source/usage/network.rst
@@ -43,7 +43,7 @@ Authorizing network access can be done in multiple ways:
     Instead of using the `libcurl` implementation, an application using the PROJ
     API can supply its own network implementation through C function callbacks
     with :cpp:func:`proj_context_set_network_callbacks`. Enabling network use
-    must still be done with one of the above mentionned method.
+    must still be done with one of the above mentioned method.
 
 Setting endpoint
 ----------------
diff --git a/docs/source/usage/projections.rst b/docs/source/usage/projections.rst
index 8f1ccd50..464451c9 100644
--- a/docs/source/usage/projections.rst
+++ b/docs/source/usage/projections.rst
@@ -46,7 +46,7 @@ name for a unit (ie. ``us-ft``).  Alternatively the translation to meters can be
 specified with the ``+to_meter`` keyword (ie. 0.304800609601219 for US feet).  The
 ``-lu`` argument to ``cs2cs`` or ``proj`` can be used to list symbolic unit names.
 The default unit for projected coordinates is the meter.
-A few special projections deviate from this behaviour, most notably the
+A few special projections deviate from this behavior, most notably the
 latlong pseudo-projection that returns degrees.
 
 Vertical (Z) units can be specified using the ``+vunits`` keyword with a
diff --git a/docs/source/usage/transformation.rst b/docs/source/usage/transformation.rst
index a11992cf..1db63a21 100644
--- a/docs/source/usage/transformation.rst
+++ b/docs/source/usage/transformation.rst
@@ -150,7 +150,7 @@ PROJ 4.x/5.x paradigm
     ============   ==============================================================
 
 .. warning::
-    This section documents the behaviour of PROJ 4.x and 5.x. In PROJ 6.x,
+    This section documents the behavior of PROJ 4.x and 5.x. In PROJ 6.x,
     :program:`cs2cs` has been reworked to use :c:func:`proj_create_crs_to_crs` internally,
     with *late binding* capabilities, and thus is no longer constrained to using
     WGS84 as a pivot (also called as *early binding* method).