fix: small error in docs (uber#577)

* Update regions.mdx

* Update regions.mdx

* Update uniedge.mdx

* Update h3indexing.md

* Update misc.mdx

* Update h3ToGeoDesc.md

* Update cellToLatLngDesc.md

website/docs/api/regions.mdx

@@ -69,7 +69,7 @@ polygonToCells takes a given GeoJSON-like data structure and preallocated,
 zeroed memory, and fills it with the hexagons that are contained by
 the GeoJSON-like data structure.
 
-Containment is determined by the cells' centroids. A partioning
+Containment is determined by the cells' centroids. A partitioning
 using the GeoJSON-like data structure, where polygons cover an area
 without overlap, will result in a partitioning in the H3 grid, where
 cells cover the same area without overlap.

website/docs/core-library/cellToLatLngDesc.md

@@ -11,7 +11,7 @@ The conversion is performed as a series of coordinate system conversions describ
 
 1.  The function `_h3ToFaceIjk` then converts the H3 index to the appropriate icosahedron face number and normalized *ijk* coordinate's on that face's coordinate system as follows:
    * We start by assuming that the cell center point falls on the same icosahedron face as its base cell.
-   * It is possible that the the cell center point lies on an adjacent face (termed an *overage* in the code), in which case we would need to use a projection centered on that adjacent face instead. We recall that normalized *ijk* coordinates have at most two non-zero components, and that in a face-centered Class II system the sum of those components is a resolution-specific constant value for cells that lie on the edge of that icosahedral face.
+   * It is possible that the cell center point lies on an adjacent face (termed an *overage* in the code), in which case we would need to use a projection centered on that adjacent face instead. We recall that normalized *ijk* coordinates have at most two non-zero components, and that in a face-centered Class II system the sum of those components is a resolution-specific constant value for cells that lie on the edge of that icosahedral face.
      We determine whether an overage exists by taking the sum of the *ijk* components, and if there is an overage the positive *ijk* components indicate which adjacent face the cell center lies on. A lookup operation is then performed to find the appropriate rotation and translation to transform the *ijk* coordinates into the adjacent face-centered *ijk* system.
 
 <div align="center">

website/versioned_docs/version-3.x/api/misc.mdx

@@ -413,13 +413,13 @@ double edgeLength(int res, LengthUnit unit);
 <TabItem value="javascript">
 
 ```js
-h3.edgeLength(res, h3.UNITS.km)
+h3.edgeLength(res, h3.UNITS.m)
 ```
 
 ```js live
 function example() {
   const res = 5;
-  return h3.edgeLength(res, h3.UNITS.km);
+  return h3.edgeLength(res, h3.UNITS.m);
 }
 ```
 

website/versioned_docs/version-3.x/api/regions.mdx

@@ -69,7 +69,7 @@ polyfill takes a given GeoJSON-like data structure and preallocated,
 zeroed memory, and fills it with the hexagons that are contained by
 the GeoJSON-like data structure.
 
-Containment is determined by the cells' centroids. A partioning
+Containment is determined by the cells' centroids. A partitioning
 using the GeoJSON-like data structure, where polygons cover an area
 without overlap, will result in a partitioning in the H3 grid, where
 cells cover the same area without overlap.

website/versioned_docs/version-3.x/api/uniedge.mdx

@@ -383,7 +383,7 @@ function example() {
 </Tabs>
 
 Provides all of the unidirectional edges from the current H3Index. `edges` must be of length 6,
-and the number of undirectional edges placed in the array may be less than 6.
+and the number of unidirectional edges placed in the array may be less than 6.
 
 ## getH3UnidirectionalEdgeBoundary
 

website/versioned_docs/version-3.x/core-library/h3ToGeoDesc.md

@@ -11,7 +11,7 @@ The conversion is performed as a series of coordinate system conversions describ
 
 *  The function `_h3ToFaceIjk` then converts the H3 index to the appropriate icosahedron face number and normalized *ijk* coordinate's on that face's coordinate system as follows:
    * We start by assuming that the cell center point falls on the same icosahedron face as its base cell.
-   * It is possible that the the cell center point lies on an adjacent face (termed an *overage* in the code), in which case we would need to use a projection centered on that adjacent face instead. We recall that normalized *ijk* coordinates have at most two non-zero components, and that in a face-centered Class II system the sum of those components is a resolution-specific constant value for cells that lie on the edge of that icosahedral face.
+   * It is possible that the cell center point lies on an adjacent face (termed an *overage* in the code), in which case we would need to use a projection centered on that adjacent face instead. We recall that normalized *ijk* coordinates have at most two non-zero components, and that in a face-centered Class II system the sum of those components is a resolution-specific constant value for cells that lie on the edge of that icosahedral face.
      We determine whether an overage exists by taking the sum of the *ijk* components, and if there is an overage the positive *ijk* components indicate which adjacent face the cell center lies on. A lookup operation is then performed to find the appropriate rotation and translation to transform the *ijk* coordinates into the adjacent face-centered *ijk* system.
 
 <div align="center">

website/versioned_docs/version-3.x/core-library/h3indexing.md

@@ -50,7 +50,7 @@ The three bits for each unused digit are set to 7.
 
 ### H3 Unidirectional Edge Index
 
-An H3 Undirectional Edge index (mode 2) represents a single directed edge between two cells (an "origin" cell and a neighboring "destination" cell). The components of the H3 Unidirectional Edge index are packed into a 64-bit integer in order, highest bit first, as follows:
+An H3 Unidirectional Edge index (mode 2) represents a single directed edge between two cells (an "origin" cell and a neighboring "destination" cell). The components of the H3 Unidirectional Edge index are packed into a 64-bit integer in order, highest bit first, as follows:
 
 * 1 bit reserved and set to 0,
 * 4 bits to indicate the H3 Unidirectional Edge index mode,