doc rfc: codespell [ci skip]

OSGeo · Mar 1, 2025 · 5f45cd5 · 5f45cd5
1 parent c7006db
commit 5f45cd5
Show file tree

Hide file tree

Showing 12 changed files with 14 additions and 14 deletions.
diff --git a/doc/source/development/rfc/rfc33_gtiff_pixelispoint.rst b/doc/source/development/rfc/rfc33_gtiff_pixelispoint.rst
@@ -37,7 +37,7 @@ software developers and data producers. This was based on the authors
 interpretation of something said once by the GeoTIFF author. However, a
 recent review of section [`section
 2.5.2.2 <http://www.remotesensing.org/geotiff/spec/geotiff2.5.html#2.5.2.2>`__]
-of the GeoTIFF specificaiton has made it clear that GDAL behavior is
+of the GeoTIFF specification has made it clear that GDAL behavior is
 incorrect and that PixelIsPoint georeferencing needs to be offset by a
 half a pixel when transformed to the GDAL georeferencing model. This
 issue is documented in the following tickets including #3837, #3838,

diff --git a/doc/source/development/rfc/rfc3_commiters.rst b/doc/source/development/rfc/rfc3_commiters.rst
@@ -201,8 +201,8 @@ repository:
    contribute to the code base, please seek more information from the
    project steering committee, or the foundation legal counsel.
 
-Bootstraping
-------------
+Bootstrapping
+-------------
 
 The following existing committers will be considered authorized GDAL/OGR
 committers as long as they each review the committer guidelines, and

diff --git a/doc/source/development/rfc/rfc40_enhanced_rat_support.rst b/doc/source/development/rfc/rfc40_enhanced_rat_support.rst
@@ -7,7 +7,7 @@ RFC 40: Improving performance of Raster Attribute Table implementation for large
 Summary:
 --------
 
-Raster Attrbute Tables from some applications (notably segmentation) can
+Raster Attribute Tables from some applications (notably segmentation) can
 be very large and are slow to access with the current API due to the way
 only one element can get read or written at a time. Also, when an
 attribute table is requested by the application the whole table must be

diff --git a/doc/source/development/rfc/rfc46_gdal_ogr_unification.rst b/doc/source/development/rfc/rfc46_gdal_ogr_unification.rst
@@ -252,7 +252,7 @@ Drivers and driver registration
                    "group of the S-57 file" default="YES" />
      <Option name="RETURN_LINKAGES" type="boolean"
        description="Should additional attributes relating features to their underlying "
-                   "geometric primtives be attached" default="NO" />
+                   "geometric primitives be attached" default="NO" />
      <Option name="RECODE_BY_DSSI" type="boolean"
        description="Should attribute values be recoded to UTF-8 from the character "
                    "encoding specified in the S57 DSSI record." default="NO" />

diff --git a/doc/source/development/rfc/rfc5_unicode.rst b/doc/source/development/rfc/rfc5_unicode.rst
@@ -69,7 +69,7 @@ the file encoding to UTF-8. So we need a way to get file encoding in
 some way on per datasource basis. The natural solution of the problem is
 to introduce optional open parameter "ENCODING" to GDALOpen/OGROpen
 functions. Unfortunately, those functions do not accept options. That
-should be introduced in another RFC. Fortunately, tehre is no need to
+should be introduced in another RFC. Fortunately, there is no need to
 add encoding parameter immediately, because it is independent from the
 general i18n process. We can add UTF-8 support as it is defined in this
 RFC and add support for forcing per-datasource encoding later, when the

diff --git a/doc/source/development/rfc/rfc6_sqlgeom.rst b/doc/source/development/rfc/rfc6_sqlgeom.rst
@@ -69,7 +69,7 @@ for the field names and types in ogrfeaturequery.cpp as
    swq_field_type SpecialFieldTypes[SPECIAL_FIELD_COUNT]
        = {SWQ_INTEGER, SWQ_STRING, SWQ_STRING, SWQ_STRING};
 
-So as to make this array accessible to the other files the followings
+So as to make this array accessible to the other files the following
 will be added to ogr_p.h
 
 ::

diff --git a/doc/source/development/rfc/rfc71_github_migration.rst b/doc/source/development/rfc/rfc71_github_migration.rst
@@ -92,7 +92,7 @@ from other GDAL developers/contributors would be welcome:
 Exit strategy
 -------------
 
-GitHub is a closed platform. In case it would close or would start askin
+GitHub is a closed platform. In case it would close or would start asking
 to pay unreasonable fees, some backup strategy of the tickets would be
 needed. The solutions might be:
 

diff --git a/doc/source/development/rfc/rfc76_ogrpythondrivers.rst b/doc/source/development/rfc/rfc76_ogrpythondrivers.rst
@@ -409,7 +409,7 @@ Security implications
 
 Similar to the existing native code plugin mechanism of GDAL. If the user
 defines the GDAL_PYTHON_DRIVER_PATH environment variable or GDAL_DRIVER_PATH,
-annd put .py scripts in them (or in {prefix}/lib/gdalplugins/python as a fallback),
+and puts .py scripts in them (or in {prefix}/lib/gdalplugins/python as a fallback),
 they will be executed.
 
 However, opening a .py file with GDALOpen() or similar mechanisms will not

diff --git a/doc/source/development/rfc/rfc83_use_of_project_sponsorship.rst b/doc/source/development/rfc/rfc83_use_of_project_sponsorship.rst
@@ -51,8 +51,8 @@ Scope
   identifying issues reported by Continuous Integration, asking for new tests
   to be developed whenever possible, etc. When the contributor is not in capacity
   to polish his/her contribution, the co-maintainer may do it themself.
-- Ensuring that fixes that are appropriate for backporting in stable branche(s)
-  are backported.
+- Ensuring that fixes that are appropriate for backporting in stable branch /
+  branches are backported.
 - Monitoring of project communication channels (mailing list, IRC, Slack
   channels, etc.). The co-maintainer will in particular identify issues that are
   reported through those means and ensures that they are captured by a

diff --git a/doc/source/development/rfc/rfc86_column_oriented_api.rst b/doc/source/development/rfc/rfc86_column_oriented_api.rst
@@ -75,7 +75,7 @@ two main callbacks to get:
   a set of values for a specific column/field in a subset of features.
   This is the equivalent of a
   `Series <https://arrow.apache.org/docs/python/pandas.html#series>`_ in a Pandas DataFrame.
-  This is a potentially hiearchical structure that can aggregate
+  This is a potentially hierarchical structure that can aggregate
   sub arrays, and in OGR usage, the main array will be a StructArray which is
   the collection of OGR attribute and geometry fields.
   The layout of buffers and children arrays per data type is detailed in the

diff --git a/doc/source/development/rfc/rfc91_dataset_close.rst b/doc/source/development/rfc/rfc91_dataset_close.rst
@@ -62,7 +62,7 @@ A new virtual method GDALDataset::Close() is added.
      * destroying a dataset. It should not be called on a shared dataset whose
      * reference count is greater than one.
      *
-     * It gives a last chance to the closing processus to return an error code if
+     * It gives a last chance to the closing process to return an error code if
      * something goes wrong, in particular in creation / update scenarios where
      * file write or network communication might occur when finalizing the dataset.
      *

diff --git a/doc/source/development/rfc/rfc92_wkb_only_geometries.rst b/doc/source/development/rfc/rfc92_wkb_only_geometries.rst
@@ -194,7 +194,7 @@ runs in 15.8 second in WKBOnlyGeometry mode vs 19.1 second without it (master),
 hence a 17% speed-up.
 
 With spatial index creation enabled (multi-threaded), the wall clock time
-difference is within measurement noise. And for singe threaded creation, the
+difference is within measurement noise. And for single threaded creation, the
 WKBOnlyGeometry mode is 5% faster.
 
 Discussion