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

4 files changed, 11 insertions, 11 deletions

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