Go through the docs, correct grammar, etc (#824)

* Go through the docs, correct grammar, etc

Sorry for the large PR but this is just the result of me running an AI over the docs.  Not urgent at all, feel free to merge/review or not.

* Update docs/src/cuda.md

Co-authored-by: Lazaro Alonso <lazarus.alon@gmail.com>

* Update docs/src/selectors.md

* Update docs/src/tables.md

---------

Co-authored-by: Rafael Schouten <rafaelschouten@gmail.com>
Co-authored-by: Lazaro Alonso <lazarus.alon@gmail.com>

docs/src/broadcasts.md

@@ -1,21 +1,20 @@
 # Dimensional broadcasts with `@d` and `broadcast_dims`
 
 Broadcasting over AbstractDimArray works as usual with Base Julia broadcasts,
-except that dimensions are checked for compatibility with eachother, and that
-values match. Strict checks can be turned of globally with
+except that dimensions are checked for compatibility with each other, and that
+values match. Strict checks can be turned off globally with
 `strict_broadcast!(false)`. 
 To avoid even dimension name checks, broadcast over `parent(dimarray)`.
 
-The [`@d`](@ref) macro is a dimension-aware extension to regular dot brodcasting.
-[`broadcast_dims`](@ref) and [`broadcast_dims`](@ref) are analagous to Base
-julia `broadcast`. 
+The [`@d`](@ref) macro is a dimension-aware extension to regular dot broadcasting.
+[`broadcast_dims`](@ref) is analogous to Base Julia's `broadcast`. 
 
-Because we know the names of the dimensions, there is no ambiguity in which one
+Because we know the names of the dimensions, there is no ambiguity in which ones
 we mean to broadcast together. This means we can permute and reshape dims so
 that broadcasts that would fail with a regular `Array` just work with a
 `DimArray`. 
 
-As an added bonus, `broadcast_dims` even works on `DimStack`s. Currently `@d` 
+As an added bonus, `broadcast_dims` even works on `DimStack`s. Currently, `@d` 
 does not work on `DimStack`.
 
 ## Example: scaling along the time dimension

docs/src/cuda.md

@@ -13,7 +13,7 @@ A = rand(Float32, X(1.0:1000.0), Y(1.0:2000.0))
 cuA = modify(CuArray, A)
 ```
 
-The result of a GPU broadcast is still a DimArray:
+The result of a GPU broadcast is still a `DimArray`:
 
 ```julia-repl
 julia> cuA2 = cuA .* 2
@@ -50,20 +50,20 @@ CuArray{Float32, 2, CUDA.Mem.DeviceBuffer}
 
 DimensionalData.jl has two GPU-related goals:
 
-1. Work seamlessly with Base julia broadcasts and other operations that already
+1. Work seamlessly with `Base` Julia broadcasts and other operations that already
    work on GPU.
 2. Work as arguments to custom GPU kernel functions.
 
 This means any `AbstractDimArray` must be automatically moved to the GPU and its
-fields converted to GPU friendly forms whenever required, using [Adapt.jl](https://github.com/JuliaGPU/Adapt.jl)).
+fields converted to GPU-friendly forms whenever required, using [Adapt.jl](https://github.com/JuliaGPU/Adapt.jl).
 
-- The array data must converts to the correct GPU array backend 
+- The array data must convert to the correct GPU array backend 
   when `Adapt.adapt(dimarray)` is called.
 - All DimensionalData.jl objects, except the actual parent array, need to be immutable `isbits` or
   convertible to them. This is one reason DimensionalData.jl uses `rebuild` and a functional style,
   rather than in-place modification of fields.
-- Symbols need to be moved to the type system `Name{:layer_name}()` replaces `:layer_name`
-- Metadata dicts need to be stripped, they are often too difficult to convert,
+- Symbols need to be moved to the type system, so `Name{:layer_name}()` replaces `:layer_name`.
+- Metadata dictionaries need to be stripped, as they are often too difficult to convert
   and not needed on GPU.
 
 As an example, [DynamicGrids.jl](https://github.com/cesaraustralia/DynamicGrids.jl) uses `AbstractDimArray` for auxiliary 

docs/src/dimarrays.md

@@ -84,7 +84,7 @@ order of our objects axes. These are the same:
 da[X(2), Y(1)] == da[Y(1), X(2)]
 ```
 
-We also can use Tuples of dimensions like `CartesianIndex`,
+We also can use `Tuples` of dimensions, like `CartesianIndex`,
 but they don't have to be in order of consecutive axes.
 
 ```@ansi dimarray

docs/src/dimensions.md

@@ -11,7 +11,7 @@ X(1)
 X(1), Y(2), Z(3)
 ```
 
-You can also make [`Dim`](@ref) dimensions with any name:
+You can also create [`Dim`](@ref) dimensions with any name:
 
 ```@ansi dimensions
 Dim{:a}(1), Dim{:b}(1)
@@ -25,14 +25,14 @@ val(X(1))
 
 DimensionalData.jl uses `Dimensions` everywhere: 
 
-- `Dimension` are returned from `dims` to specify the names of the dimensions of an object
-- they wrap [`Lookups`](@ref) to associate the lookups with those names
-- to index into these objects, they wrap indices like `Int` or a `Selector` 
+- `Dimension`s are returned from `dims` to specify the names of the dimensions of an object
+- They can wrap [`Lookups`](@ref) to associate the lookups with those names
+- To index into these objects, they can wrap indices like `Int` or a `Selector` 
 
-This symmetry means we can ignore how data is organised, 
+This symmetry means we can ignore how data is organized, 
 and label and access it by name, letting DD work out the details for us.
 
-Dimensions are defined in the [`Dimensions`](@ref) submodule, some 
+Dimensions are defined in the [`Dimensions`](@ref) submodule, and some 
 Dimension-specific methods can be brought into scope with:
 
 ```julia

docs/src/diskarrays.md

@@ -10,13 +10,13 @@
 
 It is rarely used directly, but is present in most 
 disk and cloud based spatial data packages in julia, including:
-ArchGDAL.jl, NetCDF.jl, Zarr.jl, NCDatasets.lj, GRIBDatasets.jl and CommonDataModel.jl
+ArchGDAL.jl, NetCDF.jl, Zarr.jl, NCDatasets.jl, GRIBDatasets.jl and CommonDataModel.jl
 
-The combination of DiskArrays.jl and DimensionalData.jl is Julias answer to
-pythons [xarray](https://xarray.dev/). Rasters.jl and YAXArrays.jl are user-facing 
+The combination of DiskArrays.jl and DimensionalData.jl is Julia's answer to
+python's [xarray](https://xarray.dev/). Rasters.jl and YAXArrays.jl are user-facing 
 tools building on this combination.
 
 
-They have no direct dependency relationships, with but are intentionally 
+They have no direct dependency relationships, but are intentionally 
 designed to integrate via both adherence to Julia's `AbstractArray` 
 interface, and by coordination during development of both packages.

docs/src/extending_dd.md

@@ -2,9 +2,9 @@
 
 Nearly everything in DimensionalData.jl is designed to be extensible.
 
-- `AbstractDimArray` are easily extended to custom array types. `Raster` or
+- `AbstractDimArray` is easily extended to custom array types. `Raster` or
   `YAXArray` are examples from other packages.
-- `AbstractDimStack` are easily extended to custom mixed array dataset.
+- `AbstractDimStack` is easily extended to custom mixed array datasets.
     `RasterStack` or `ArViZ.Dataset` are examples.
 - `Lookup` can have new types added, e.g. to `AbstractSampled` or
   `AbstractCategorical`. `Rasters.Projected` is a lookup that knows
@@ -20,7 +20,7 @@ a `Tuple` of constructed `Dimension`s from `dims(obj)`.
 
 ### `Dimension` axes
 
-Dimensions return from `dims` should hold a `Lookup` or in some cases 
+Dimensions returned from `dims` should hold a `Lookup` or in some cases 
 just an `AbstractArray` (like with `DimIndices`). When attached to 
 multi-dimensional objects, lookups must be the _same length_ as the axis 
 of the array it represents, and `eachindex(A, i)` and `eachindex(dim)` must 

docs/src/get_info.md

@@ -2,9 +2,9 @@
 
 DimensionalData.jl defines consistent methods to retrieve information
 from objects like `DimArray`, `DimStack`, `Tuple`s of `Dimension`,
-`Dimension` and `Lookup`.
+`Dimension`, and `Lookup`.
 
-First we will define an example `DimArray`.
+First, we will define an example `DimArray`.
 
 ```@example getters
 using DimensionalData
@@ -22,8 +22,8 @@ A = rand(x, y)
 
 `dims` retrieves dimensions from any object that has them.
 
-What makes it so useful is you can filter which dimensions
-you want in what order, using any `Dimension`, `Type{Dimension}`
+What makes it so useful is that you can filter which dimensions
+you want, and specify in what order, using any `Dimension`, `Type{Dimension}`
 or `Symbol`.
 
 ```@ansi getters
@@ -113,8 +113,8 @@ span(lookup(A, Y))
 Get the locus of a `Lookup`, or a `Tuple`
 from a `DimArray` or `DimTuple`.
 
-(locus is our term for distinguishing if an lookup value
-specifies the start, center or end of an interval)
+(`locus` is our term for distinguishing if an lookup value
+specifies the start, center, or end of an interval)
 
 ```@ansi getters
 locus(A)
@@ -166,7 +166,7 @@ extent(dims(A, Y))
 ## Predicates
 
 These always return `true` or `false`. With multiple
-dimensions, `fale` means `!all` and `true` means `all`.
+dimensions, `false` means `!all` and `true` means `all`.
 
 `dims` and all other methods listed above can use predicates
 to filter the returned dimensions.

docs/src/groupby.md

@@ -1,19 +1,19 @@
 # Group By
 
 DimensionalData.jl provides a `groupby` function for dimensional
-grouping. This guide will cover:
+grouping. This guide covers:
 
 - simple grouping with a function
 - grouping with `Bins`
-- grouping with another existing `AbstractDimArry` or `Dimension`
+- grouping with another existing `AbstractDimArray` or `Dimension`
 
 
 ## Grouping functions
 
-Lets look at the kind of functions that can be used to group `DateTime`.
+Let's look at the kind of functions that can be used to group `DateTime`.
 Other types will follow the same principles, but are usually simpler.
 
-First load some packages:
+First, load some packages:
 
 ````@example groupby
 using DimensionalData
@@ -29,9 +29,9 @@ Now create a demo `DateTime` range
 tempo = range(DateTime(2000), step=Hour(1), length=365*24*2)
 ````
 
-Lets see how some common functions work.
+Let's see how some common functions work.
 
-The `hour` function will transform values to hour of the day - the integers `0:23`
+The `hour` function will transform values to the hour of the day - the integers `0:23`
 
 :::tabs
 
@@ -86,7 +86,7 @@ yearmonthday.(tempo)
 
 == custom
 
-We can create our own function that return tuples
+We can create our own function that returns tuples
 
 ````@example groupby
 yearday(x) = (year(x), dayofyear(x))
@@ -104,7 +104,7 @@ yearday.(tempo)
 
 ## Grouping and reducing
 
-Lets define an array with a time dimension of the times used above:
+Let's define an array with a time dimension of the times used above:
 
 ````@ansi groupby
 A = rand(X(1:0.01:2), Ti(tempo))
@@ -195,15 +195,15 @@ mean.(groupby(A, Ti=>Bins(month, [1, 3, 5])))
 == bin groups
 
 We can also specify an `AbstractArray` of grouping `AbstractArray`:
-Her we group by month, and bin the summer and winter months:
+Here we group by month, and bin the summer and winter months:
 
 ````@ansi groupby
 groupby(A, Ti => Bins(month, [[12, 1, 2], [6, 7, 8]]; labels=x -> string.(x)))
 ````
 
 == range bins
 
-First, lets see what [`ranges`](@ref) does:
+First, let's see what [`ranges`](@ref) does:
 
 ````@ansi groupby
 ranges(1:8:370)
@@ -285,15 +285,15 @@ We can also select by `Dimension`s and any objects with `dims` methods.
 
 == groupby dims
 
-Trivially, grouping by an objects own dimension is similar to `eachslice`:
+Trivially, grouping by an object's own dimension is similar to `eachslice`:
 
 ````@ansi groupby
 groupby(A, dims(A, Ti))
 ````
 
 == groupby AbstractDimArray
 
-But we can also group by other objects dimensions:
+But we can also group by other objects' dimensions:
 
 ````@ansi groupby
 B = A[:, 1:3:100]

docs/src/integrations.md

@@ -2,33 +2,22 @@
 
 ## Rasters.jl
 
-[Rasters.jl](https://rafaqz.github.io/Rasters.jl/stable) extends DD
-for geospatial data manipulation, providing file load/save for
-a wide range of raster data sources and common GIS tools like
-polygon rasterization and masking. `Raster` types are aware
-of `crs` and their `missingval` (which is often not `missing`
-for performance and storage reasons).
+[Rasters.jl](https://rafaqz.github.io/Rasters.jl/stable) extends DimensionalData for geospatial data manipulation, providing file load/save capabilities for a wide range of raster data sources and common GIS tools like polygon rasterization and masking. `Raster` types are aware of their `crs` and their `missingval` (which is often not `missing` for performance and storage reasons).
 
-Rasters.jl is also the reason DimensionalData.jl exists at all! 
-But it always made sense to separate out spatial indexing from
-GIS tools and dependencies.
+Rasters.jl is also the reason DimensionalData.jl exists at all! But it always made sense to separate out spatial indexing from GIS tools and dependencies.
 
-A `Raster` is a `AbstractDimArray`, a `RasterStack` is a `AbstractDimStack`,
-and `Projected` and `Mapped` are `AbstractSample` lookups.
+A `Raster` is a `AbstractDimArray`, a `RasterStack` is a `AbstractDimStack`, and `Projected` and `Mapped` are `AbstractSampled` lookups.
 
 ## YAXArrays.jl
 
-[YAXArrays.jl](https://juliadatacubes.github.io/YAXArrays.jl/dev/) is another
-spatial data package aimed more at (very) large datasets. It's functionality
-is slowly converging with Rasters.jl (both wrapping DiskArray.jl/DimensionalData.jl)
-and we work closely with the developers.
+[YAXArrays.jl](https://juliadatacubes.github.io/YAXArrays.jl/dev/) is another spatial data package aimed more at (very) large datasets. Its functionality is slowly converging with Rasters.jl (both wrapping DiskArrays.jl/DimensionalData.jl) and we work closely with the developers.
 
 `YAXArray` is a `AbstractDimArray` and inherits its behaviours.
 
 ## ClimateBase.jl
 
 [ClimateBase.jl](https://juliaclimate.github.io/ClimateBase.jl/dev/)
-Extends DD with methods for analysis of climate data.
+Extends DimensionalData.jl with methods for analysis of climate data.
 
 ## ArviZ.jl
 

docs/src/object_modification.md

@@ -1,4 +1,4 @@
-# Modifying objects
+# Modifying Objects
 
 DimensionalData.jl objects are all `struct` rather than
 `mutable struct`. The only things you can modify in-place
@@ -28,7 +28,7 @@ parent(A_mod)
 
 == stack
 
-For a stack this applied to all layers, and is where `modify`
+For a stack, this applies to all layers, and is where `modify`
 starts to be more powerful:
 
 ````@ansi helpers