Merge pull request #3566 from rouault/typo_fixes

Typo fixes and other changes to make ./scripts/fix_typos.sh happy

docs/plot/plot.py

@@ -184,12 +184,12 @@ def project_xy(x, y, proj_string):
     return a.T
 
 
-def meridian(lon, lat_min, lat_max):
+def meridian(longitude, lat_min, lat_max):
     '''
     Calculate meridian coordinates.
     '''
     coords = np.zeros((N_POINTS, 2))
-    coords[:, 0] = lon
+    coords[:, 0] = longitude
     coords[:, 1] = np.linspace(lat_min, lat_max, N_POINTS)
     return coords
 
@@ -215,8 +215,8 @@ def build_graticule(lonmin=-180, lonmax=180, latmin=-85, latmax=85):
     latmax = int(latmax)
     graticule = []
 
-    for lon in range(lonmin, lonmax+1, GRATICULE_WIDTH):
-        graticule.append(meridian(lon, latmin, latmax))
+    for longitude in range(lonmin, lonmax+1, GRATICULE_WIDTH):
+        graticule.append(meridian(longitude, latmin, latmax))
 
     for lat in range(latmin, latmax+1, GRATICULE_WIDTH):
         graticule.append(parallel(lat, lonmin, lonmax))
@@ -330,15 +330,15 @@ def plotproj(plotdef, data, outdir):
     # Plot interrupted boundaries if necessary
     interrupted_lines = []
     if 'top_interrupted_lons' in plotdef:
-        for lon in plotdef['top_interrupted_lons']:
+        for longitude in plotdef['top_interrupted_lons']:
             for delta in [-0.0001, 0.0001]:
-                merid = meridian(lon + delta, 0.0, plotdef['latmax'])
+                merid = meridian(longitude + delta, 0.0, plotdef['latmax'])
                 interrupted_lines.append(project(merid, plotdef['projstring']))
 
     if 'bottom_interrupted_lons' in plotdef:
-        for lon in plotdef['bottom_interrupted_lons']:
+        for longitude in plotdef['bottom_interrupted_lons']:
             for delta in [-0.0001, 0.0001]:
-                merid = meridian(lon + delta, plotdef['latmin'], 0)
+                merid = meridian(longitude + delta, plotdef['latmin'], 0)
                 interrupted_lines.append(project(merid, plotdef['projstring']))
 
     for line in interrupted_lines:

docs/source/apps/cs2cs.rst

@@ -310,7 +310,7 @@ To get those exact values, you have need to have all current grids installed
 locally or use networking capabilities mentioned above.
 
 To make sure you will get the optimal result, you may add :option:`--only-best`.
-Assuming the above mentionned grid is *not* available,
+Assuming the above mentioned grid is *not* available,
 
 ::
 

docs/source/apps/geod.rst

@@ -134,9 +134,9 @@ as program :program:`proj` by using *+ellps=*, *+a=*, *+es=*, etc.
 :program:`geod` may also be used to determine intermediate points along
 either a geodesic line between two points or along an arc of
 specified distance from a geographic point. In both cases an
-initial point must be specified with *+lat_1=lat* and *+lon_1=lon*
+initial point must be specified with *+lat_1=lat* and *+lon_1=long*
 parameters and either a terminus point *+lat_2=lat* and
-*+lon_2=lon* or a distance and azimuth from the initial point
+*+lon_2=long* or a distance and azimuth from the initial point
 with *+S=distance* and *+A=azimuth* must be specified.
 
 If points along a geodesic are to be determined then either

docs/source/community/rfc/rfc-2.rst

@@ -157,7 +157,7 @@ all classes, except the CoordinateOperation class that point to CRS for
 sourceCRS and targetCRS members, whereas DerivedCRS point to a Conversion
 instance (which derives from CoordinateOperation). This issue was detected in
 the ISO-19111 standard. The solution adopted here is to use std::weak_ptr
-in the CoordinateOperation class to avoid the cycle. This design artefact is
+in the CoordinateOperation class to avoid the cycle. This design artifact is
 transparent to users.
 
 Another important design point is that all ISO19111 objects are immutable after
@@ -636,7 +636,7 @@ Impacted files
 --------------
 
 New files (excluding makefile.am, CMakeLists.txt and other build infrastructure
-artefacts):
+artifacts):
 
     * include/proj/: Public installed C++ headers
         - `common.hpp`_: declarations of osgeo::proj::common namespace.

docs/source/community/rfc/rfc-4.rst

@@ -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 explicit lon and lat variables with all values taken by the grid.
+  to write explicit long and lat variables with all values taken by the grid.
   GDAL has for many years supported a simpler syntax, using a GeoTransform
   attribute.
 

docs/source/community/rfc/rfc-7.rst

@@ -69,7 +69,7 @@ the build process using generators, including Unix Makefiles and Ninja among
 other command-based and IDE tools. The CMake software has been under active
 development since its origins in 2000. The CMake language is carefully
 developed with backwards-compatible policies that aim to provide consistent
-behaviour across different versions. CMake is currently the preferred build
+behavior across different versions. CMake is currently the preferred build
 tool for PROJ for the following reasons:
 
 - It has existed in the PROJ code base since 2014, and is familiar to active

docs/source/development/reference/functions.rst

@@ -290,7 +290,7 @@ Coordinate transformation
 
     .. versionadded:: 9.1.0
 
-    Return the operation used during the last invokation of proj_trans().
+    Return the operation used during the last invocation of proj_trans().
     This is especially useful when P has been created with proj_create_crs_to_crs()
     and has several alternative operations.
     The returned object must be freed with proj_destroy().

docs/source/news.rst

@@ -35,7 +35,7 @@ Bug fixes
 
 * Implement ``Geographic/Vertical Offset`` conversions (`#3413 </~https://github.com/OSGeo/PROJ/issues/3413>`_)
 
-* ``vandg`` projection: handle ``+over`` to extend the validity domain outside of ``|lon|>180deg`` (`#3427 </~https://github.com/OSGeo/PROJ/issues/3427>`_)
+* ``vandg`` projection: handle ``+over`` to extend the validity domain outside of ``|long|>180deg`` (`#3427 </~https://github.com/OSGeo/PROJ/issues/3427>`_)
 
 * ``eqdc`` projection: avoid floating point division by zero in non-nominal case (`#3415 </~https://github.com/OSGeo/PROJ/issues/3415>`_)
 
@@ -193,7 +193,7 @@ Bug fixes
 
 * ``unitconvert``: round to nearest date when converting to yyyymmdd (`#3111 </~https://github.com/OSGeo/PROJ/issues/3111>`_)
 
-* Fix comparison of GeodeticRefrenceFrame vs DynamicGeodeticReferenceFrame (`#3120 </~https://github.com/OSGeo/PROJ/issues/3120>`_)
+* Fix comparison of GeodeticReferenceFrame vs DynamicGeodeticReferenceFrame (`#3120 </~https://github.com/OSGeo/PROJ/issues/3120>`_)
 
 * :cpp:func:`createOperations`: fix transformation involving CompoundCRS, ToWGS84
   and PROJ4_GRIDS (`#3124 </~https://github.com/OSGeo/PROJ/issues/3124>`_)
@@ -412,7 +412,7 @@ Bug fixes
 
 * Detect ESRI WKT better in certain circumstances (`#2823 </~https://github.com/OSGEO/PROJ/issues/2823>`_)
 
-* Fix performance issue on pipeline instanciation of huge (broken)
+* Fix performance issue on pipeline instantiation of huge (broken)
   pipelines (`#2824 </~https://github.com/OSGEO/PROJ/issues/2824>`_)
 
 * Make sure to re-order projection parameters according to their canonical
@@ -423,7 +423,7 @@ Bug fixes
 * Fix error in implementation of Inverse ellipsoidal orthographic projection
   that cause convergence to sometimes fail (`#2853 </~https://github.com/OSGEO/PROJ/issues/2853>`_)
 
-* Fix handling of edge-case coordinates in invers ortho ellipsoidal
+* Fix handling of edge-case coordinates in inverse ortho ellipsoidal
   oblique (`#2855 </~https://github.com/OSGEO/PROJ/issues/2855>`_)
 
 * :c:func:`proj_normalize_for_visualization()`: set input and output units when there
@@ -485,7 +485,7 @@ Bug Fixes
 * Make sure that :c:func:`proj_crs_promote_to_3D` returns a derived CRS (`#2806 </~https://github.com/OSGeo/PROJ/issues/2806>`_)
 
 * :cpp:func:`createOperations`: fix missing deg<-->rad conversion when transforming with a
-  CRS that has a fallback-to-PROJ4-string behaviour and is a BoundCRS of a
+  CRS that has a fallback-to-PROJ4-string behavior and is a BoundCRS of a
   GeographicCRS (`#2808 </~https://github.com/OSGeo/PROJ/issues/2808>`_)
 
 * WKT2 import/export: preserve PROJ.4 CRS extension string in REMARKS[] (`#2812 </~https://github.com/OSGeo/PROJ/issues/2812>`_)
@@ -595,7 +595,7 @@ Bug fixes
   code) (`#2661 </~https://github.com/OSGeo/PROJ/issues/2661>`_)
 
 * :cpp:func:`createOperation()`: make sure no to discard deprecated operations if the
-  replacement uses an unknow grid (`#2623 </~https://github.com/OSGeo/PROJ/issues/2623>`_)
+  replacement uses an unknown grid (`#2623 </~https://github.com/OSGeo/PROJ/issues/2623>`_)
 
 * Fix build on Solaris 11.4 (`#2621 </~https://github.com/OSGeo/PROJ/issues/2621>`_)
 

docs/source/operations/projections/calcofi.rst

@@ -47,7 +47,7 @@ The figure depicts some commonly sampled locations from line 40 to line 156.7 an
 Usage
 ###############################################################################
 
-A typical forward CalCOFI projection would be from lon/lat coordinates on the
+A typical forward CalCOFI projection would be from long/lat coordinates on the
 Clark 1866 ellipsoid.
 For example::
 
@@ -59,7 +59,7 @@ Output of the above command::
 
     -121.15 34.15   80.00   60.00
 
-The reverse projection from line/station coordinates to lon/lat would be entered
+The reverse projection from line/station coordinates to long/lat would be entered
 as::
 
     proj +proj=calcofi +ellps=clrk66 -I -E -f "%.2f" <<EOF

docs/source/operations/projections/cea.rst

@@ -32,7 +32,7 @@ Named specializations
 ################################################################################
 
 The Equal Area Cylindrical projection is sometimes known under other names when
-it is instanciated with particular values of the ``lat_ts`` parameter:
+it is instantiated with particular values of the ``lat_ts`` parameter:
 
 +----------------------------------+------------+
 | **Name**                         | **lat_ts** |

docs/source/operations/transformations/horner.rst

@@ -236,7 +236,7 @@ Optional
 
     Coordinate of origin for the inverse mapping.
     Without this option iterative polynomial evaluation is used for
-    the inverse tranformation.
+    the inverse transformation.
 
 .. option:: +inv_u=<u_11,u_12,...,u_ij,..,u_mn>
 
@@ -245,7 +245,7 @@ Optional
     Coefficients for the inverse transformation i.e. latitude to northing
     as described in :eq:`real_poly`. Only applies for real polynomials.
     Without this option iterative polynomial evaluation is used for
-    the inverse tranformation.
+    the inverse transformation.
 
 .. option:: +inv_v=<v_11,v_12,...,v_ij,..,v_mn>
 
@@ -254,7 +254,7 @@ Optional
     Coefficients for the inverse transformation i.e. longitude to easting
     as described in :eq:`real_poly`. Only applies for real polynomials.
     Without this option iterative polynomial evaluation is used for
-    the inverse tranformation.
+    the inverse transformation.
 
 .. option:: +inv_c=<c_1,c_2,...,c_N>
 
@@ -263,7 +263,7 @@ Optional
     Coefficients for the complex inverse transformation
     as described in :eq:`complex_poly`. Only applies for complex polynomials.
     Without this option iterative polynomial evaluation is used for
-    the inverse tranformation.
+    the inverse transformation.
 
 .. option:: +range=<value>
 

docs/source/operations/transformations/tinshift.rst

@@ -171,7 +171,7 @@ fallback_strategy
   specified triangles. This item is available for ``format_version`` >= 1.1.
   Possible values are ``none``, ``nearest_side`` and ``nearest_centroid``. The
   default is ``none`` and signifies, that points that fall outside the
-  specified triangles are not transformed. This is also the behaviour for
+  specified triangles are not transformed. This is also the behavior for
   ``format_version`` before 1.1. If ``fallback_strategy`` is set to
   ``nearest_side``, then points that do not fall into any triangle are 
   transformed according to the triangle closest to them by euclidean distance.

docs/source/specifications/geodetictiffgrids.rst

@@ -227,7 +227,7 @@ is an easy way to inspect such grid files:
     - ``ELLIPSOIDAL_HEIGHT_OFFSET``: implies the presence of one sample with
       the ellipsoidal height difference. Generally used in combination with
       another grid of type ``HORIZONTAL_OFFSET`` to perform Geographic 3D
-      offseting when the horizontal and vertical grids do not have the same
+      offsetting when the horizontal and vertical grids do not have the same
       resolution, as found in some NADCON5 grids.
       Added in PROJ 9.2
       Corresponds to PROJ :ref:`gridshift` method.

docs/source/specifications/projjson.rst

@@ -81,7 +81,7 @@ member, the ``type`` may be omitted. However, the value of the ``datum`` object
 a GeographicCRS the ``type`` should be specified, as it can be either a GeodeticReferenceFrame
 or a DynamicGeodeticReferenceFrame.
 More formally, the ``type`` should be specified if the JSON schema specifies alternative
-types for the value of a member using the oneOf constrct and those alternative
+types for the value of a member using the oneOf construct and those alternative
 types have a ``type`` member. Otherwise it may be omitted.
 
 High level objects
@@ -169,7 +169,7 @@ of a "object usage" class. An object usage has the following optional members:
   The coordinates are expressed in a unspecified datum, with the longitudes
   relative to the international reference meridian.
 - ``remarks``: (optional) value of type string with an informative text that does
-  not modify the definining parameters of the object. e.g "Use NTv2 file for better accuracy"
+  not modify the defining parameters of the object. e.g "Use NTv2 file for better accuracy"
 - ``id`` (mutually exclusive with ``ids``): (optional) Identifier of the object, as defined in :ref:`identifiers`
 - ``ids`` (mutually exclusive with ``id``): (optional) Identifiers of the object, as defined in :ref:`identifiers`
 
@@ -479,7 +479,7 @@ of the PROJ software version 9.0.0
 .. note::
 
     PROJ versions prior to PROJ 8.0.0 used versions of the EPSG dataset that
-    did not have the datum ensemble concept. Consquently they used a ``datum``
+    did not have the datum ensemble concept. Consequently they used a ``datum``
     member instead of a ``datum_ensemble``. The number of elements in the
     datum ensemble may also vary over time when new realizations of WGS 84 are
     added to the ensemble.
@@ -1085,7 +1085,7 @@ PROJJSON extensions
 
 This specification allows a Bound CRS to be used wherever a CRS object is allowed
 in the OGC Topic 2 abstract specification / ISO-19111:2019. In particular,
-the members of a coumpound CRS can be a Bound CRS in this specification, whereas
+the members of a compound CRS can be a Bound CRS in this specification, whereas
 OGC Topic 2 abstract specification restricts it to single CRS. A Bound CRS can
 also be used as the source or target of a coordinate operation.
 

docs/source/tutorials/EUREF2019/exercises/projections3.gie

@@ -34,7 +34,7 @@ expect      1506742.2481    6535299.3398
 2. Use the Transverse Mercator to model the UTM projection
 -------------------------------------------------------------------------------
   The backbone of the UTM projection is a Transverse Mercator projection. In
-  this exercise we will model the behaviour of the UTM projection using the
+  this exercise we will model the behavior of the UTM projection using the
   Transverse Mercator.
 
 
@@ -87,7 +87,7 @@ faster, less accurate transverse mercator algorithm.
 We will try to determine the approximate roundtrip accuracy of the +approx
 algorithm several UTM zones away from the actual zone for the given coordinate.
 For all the exercises below the aim is to find the lowest tolerance for each
-roundtrip test. You can of course make alle tests pass by setting a tolerance of
+roundtrip test. You can of course make all tests pass by setting a tolerance of
 1000 km - that's not the point: How low can you go?
 
 After you have answered all ex. 3 questions below, based on your findings

docs/source/tutorials/EUREF2019/exercises/projections3.rst

@@ -26,7 +26,7 @@ Exercise 2: Use the Transverse Mercator to model the UTM projection
 ----------------------------------------------------------------------
 
 The backbone of the UTM projection is a Transverse Mercator projection. In
-this exercise we will model the behaviour of the UTM projection using the
+this exercise we will model the behavior of the UTM projection using the
 Transverse Mercator.
 
 
@@ -67,7 +67,7 @@ faster, less accurate transverse mercator algorithm.
 We will try to determine the approximate roundtrip accuracy of the +approx
 algorithm several UTM zones away from the actual zone for the given coordinate.
 For all the exercises below the aim is to find the lowest tolerance for each
-roundtrip test. You can of course make alle tests pass by setting a tolerance of
+roundtrip test. You can of course make all tests pass by setting a tolerance of
 1000 km - that's not the point: How low can you go?
 
 After you have answered all exercise 3 questions below, based on your findings

docs/source/usage/projections.rst

@@ -69,7 +69,7 @@ parameter.
 Input units for parameters that can be understood to be either decimal degrees or
 radians are interpreted to be decimal degrees by convention.
 
-Explict specification of input units can be accomplished by adding the appropriate
+Explicit specification of input units can be accomplished by adding the appropriate
 suffix to input values.
 
 
@@ -87,7 +87,7 @@ suffix to input values.
     | R              |                     |
     +----------------+---------------------+
 
-Example of use.  The longitude of the central meridian ``+lon_0=90``, can also be expressed more explictly
+Example of use.  The longitude of the central meridian ``+lon_0=90``, can also be expressed more explicitly
 with units of decimal degrees as ``+lon_0=90d`` or in radian
 units as ``+lon_0=1.570796r`` (approximately).
 

include/proj/coordinateoperation.hpp

@@ -1384,15 +1384,15 @@ class PROJ_GCC_DLL Conversion : public SingleOperation {
     PROJ_DLL static ConversionNNPtr
     createGeographic2DOffsets(const util::PropertyMap &properties,
                               const common::Angle &offsetLat,
-                              const common::Angle &offsetLon);
+                              const common::Angle &offsetLong);
 
     PROJ_DLL static ConversionNNPtr createGeographic3DOffsets(
         const util::PropertyMap &properties, const common::Angle &offsetLat,
-        const common::Angle &offsetLon, const common::Length &offsetHeight);
+        const common::Angle &offsetLong, const common::Length &offsetHeight);
 
     PROJ_DLL static ConversionNNPtr createGeographic2DWithHeightOffsets(
         const util::PropertyMap &properties, const common::Angle &offsetLat,
-        const common::Angle &offsetLon, const common::Length &offsetHeight);
+        const common::Angle &offsetLong, const common::Length &offsetHeight);
 
     PROJ_DLL static ConversionNNPtr
     createVerticalOffset(const util::PropertyMap &properties,
@@ -1588,19 +1588,19 @@ class PROJ_GCC_DLL Transformation : public SingleOperation {
     PROJ_DLL static TransformationNNPtr createGeographic2DOffsets(
         const util::PropertyMap &properties, const crs::CRSNNPtr &sourceCRSIn,
         const crs::CRSNNPtr &targetCRSIn, const common::Angle &offsetLat,
-        const common::Angle &offsetLon,
+        const common::Angle &offsetLong,
         const std::vector<metadata::PositionalAccuracyNNPtr> &accuracies);
 
     PROJ_DLL static TransformationNNPtr createGeographic3DOffsets(
         const util::PropertyMap &properties, const crs::CRSNNPtr &sourceCRSIn,
         const crs::CRSNNPtr &targetCRSIn, const common::Angle &offsetLat,
-        const common::Angle &offsetLon, const common::Length &offsetHeight,
+        const common::Angle &offsetLong, const common::Length &offsetHeight,
         const std::vector<metadata::PositionalAccuracyNNPtr> &accuracies);
 
     PROJ_DLL static TransformationNNPtr createGeographic2DWithHeightOffsets(
         const util::PropertyMap &properties, const crs::CRSNNPtr &sourceCRSIn,
         const crs::CRSNNPtr &targetCRSIn, const common::Angle &offsetLat,
-        const common::Angle &offsetLon, const common::Length &offsetHeight,
+        const common::Angle &offsetLong, const common::Length &offsetHeight,
         const std::vector<metadata::PositionalAccuracyNNPtr> &accuracies);
 
     PROJ_DLL static TransformationNNPtr createVerticalOffset(