fix typos

docs/guides/plugin_dev/custom_component.rst

@@ -19,7 +19,7 @@ Initialisation
 There are generally two types of components you might want to implement:
 `ModelComponent` and `SpatialModelComponent`. They are similar but the
 `SpatialModelComponent` is meant to hold spacial data. A model MUST have at least one
-`SpatialModelComponent` for it's region functionality to funciton properly.
+`SpatialModelComponent` for it's region functionality to function properly.
 
 Components of any kind, should take a reference to the model they are a part of at
 initialization so that components can access other components through the model as is
@@ -66,13 +66,13 @@ derive the region.
 Required attributes
 -------------------
 
-Asside form initialisation the components are expected to have some other properties
+Aside form initialisation the components are expected to have some other properties
 (`data`, `model`, `data_catalog` and `root`) and functions (`read` and `write`).
 Functions annotated with the `@hydromt_step` decorator will be available to users of a
 workflow yaml. Depending on the context your component may also want to implement the
-functions `set` (which is typcially not annotaed with the `@hydromt_step` decorator
-since it cannot be sued in a yaml workflow)`, and `test_equal`. `set` is typcially used
+functions `set` (which is typically not annotaed with the `@hydromt_step` decorator
+since it cannot be sued in a yaml workflow)`, and `test_equal`. `set` is typically used
 by python users to overwrite data in the component after they have done something with
-it outside of your component. `test_equal` is purely for testin purposes and should test
-whether the comopnent provided (including potential data) is equal to the component it
+it outside of your component. `test_equal` is purely for testing purposes and should test
+whether the component provided (including potential data) is equal to the component it
 is being run on. This is very useful for testing that includes data.

docs/guides/plugin_dev/custom_driver.rst

@@ -4,8 +4,8 @@ Custom Drivers
 ==============
 
 Drivers are the second ingredient necessary to read (custom) datasets. Where as
-`URIResovler`s (discussed previously) determen _what_ to read, drivers determin _how_ to
-read and slice it. For exmaple, you might use the same `ConventionResolver` to determine
+`URIResolver`s (discussed previously) determines _what_ to read, drivers determine _how_ to
+read and slice it. For example, you might use the same `ConventionResolver` to determine
 which files to read, but different drivers to read `.nc`, `.zarr` or `.tiff` files. Vice
 versa you might also use the same driver but different resolvers to read data depending
 on how it was organised. It should therefore be noted that to read a particular dataset

docs/guides/plugin_dev/custom_model.rst

@@ -25,7 +25,7 @@ implement much or even any of the basic functionalities.
 
 If you wish to provide default behaviour for your users, such as providing default
 components that your model will always need, you can do so by overriding the `__init__`
-funciton on your model like so:
+function on your model like so:
 
 ```python
 class AwesomeModel:
@@ -148,7 +148,7 @@ hypothetical landuse grid from a raster input data:
 Processes
 ^^^^^^^^^
 We encourage developers and users to define their functionality using functions that can
-be organised into seperate modules or scripts. This can keep your class definitions from
+be organised into separate modules or scripts. This can keep your class definitions from
 becoming very large unwieldy to work with as well as making it easier to make sure all
 the functionalities are properly tested (which we encourage even more strongly!)
 Because the python script defining your plugin Model class can get quite long and it  In

docs/guides/plugin_dev/custom_resolver.rst

@@ -5,12 +5,12 @@ Custom Resolver
 ===============
 
 In addition to data which may or may not be in custom file formats, to be able to read
-data, we must also know how it is layed out. For example the AWS Copernicus DEM data
+data, we must also know how it is laid out. For example the AWS Copernicus DEM data
 (https://registry.opendata.aws/copernicus-dem/) is provided as Cloud Optimised GeoTiff,
 but has no spacial index. Instead the files are divided in tiles covering the globe and
 must be queried using the desired resolution, nothing and easting to find the correct
 files. To be able to query this data set effectively we need a way to translate geo
-spacial data into a list of files which we shoudl load to get the data we want. This is
+spacial data into a list of files which we should load to get the data we want. This is
 exactly where `URIResolver`s come in.
 
 A `URIResolver` is what we use to generate a list of uris to the files we wish to query.

docs/guides/plugin_dev/plugin_quickstart.rst

@@ -14,10 +14,10 @@ section.
 .. NOTE::
 
   Most of this section of the docs is dedicated to creating *new* functinoality. If you
-  already have a plugin and want to know how to port that to the new V1 archetecture
+  already have a plugin and want to know how to port that to the new V1 architecture
   please refer to :ref:`migrating_to_v1` specifically.
 
-The new V1 archetecture of HdydroMT already offers a lot more flexibility to customise
+The new V1 architecture of HdydroMT already offers a lot more flexibility to customise
 the behaviour of HydroMT without the need for a plugin, by adding `ModelComponents`
 however there are still plenty of use cases you might want to make a plugin, including
 but not limited to:
@@ -46,7 +46,7 @@ customise or create new variants of any of the following objects:
 Please see `_register_plugins` for more detail on how to make sure that HydroMT will
 find your implementation. Currently the only real requirement for making a HydroMT
 plugin is that it is a Python Package that uses one of the above entrypoints and
-inherets from the appropriate base class so hydroMT will know how to operate it.
+inherits from the appropriate base class so hydroMT will know how to operate it.
 
 This does not mean that your plugin must necessarily be written entirely in python, but
 if it isn't you will have to make python bindings for it. This can help with performance