refactor forcing setup functions

[xldeltares]

Kind of request

Changing existing functionality

Enhancement Description

With more and more forcing types being supported (1D boundary, 1D lateral, 2D boundary, 2D meteo and in the future 2D source sink), we foresee limitations of current way of setting up forcing. Good to discuss that and refactor the functions into modular functions that are optimized in code and easy for the user.

Currently the workflow is like this:

• setup forcings (1D boundary + lateral, 2D boundary + sourcesink; 2D meteo): currently being done by hydromt-delft3dfm functions setup_1dboundary, setup_1dlateral_from_points, setup_1dlateral_from_polygons , setup_2dboundary , setup_rainfall_from_constant , setup_rainfall_from_uniform_timeseries --> this clearly can be improved as they are obviously not following the same approach.

  the setup functions contain two main part:

  1. reading geodataset (constant, spatially variant constant, spatially invariant timeseries, spatially variant timeseries): currently being done by a private function wrapper '_read_forcing_geodataset' wrapper --> this can be better supported by hydromt-core function read_geodataset.
  2. Internal preprocessing to model geometry: currently being done by several functions in hydromt-delft3dfm boundaries workflow: compute_boundary_values, compute_2dboundary_values, compute_meteo_forcings, compute_forcing_values_points, compute_forcing_values_polygon --> this can be better harmonized into smaller functions that can be reused more easily.
     In this function, we conduct the following:
     1. we compute new time indexes (e.g. 0,1,2,3,4) that are supported by Delft3D FM and hydrolib-core writer; we compute spatial indexes from geodataset.vector that are supported by Delft3D FM and hydrolib-core (for example, we add "x","y" to point geometry, we compute "xcoordinates" ,"ycoordinates" and "numcoordinates" for line and polygon type of geometry, we compute new data dimention accoding to those new spatial indexes; and finally we add attributes that are needed for the Delft3D FM forcing files (.ext and .bc). --> in the near furture, Delft3DFM will better support netcdf files. so we might be able to simplify this.
     2. In addition, we create the new forcing dataset: currently we reinitiate xr.DataArray or xr.DataSet because the computed info is flat (in comparison with GeoDataSet. --> we might want to think if this step should be done as preprocessing or move to post processing (because the main purpose of these are to support the writting of forcing into Delft3DFM formats). Then in the preprocessing we can just do hydromt.vector.GeoDataArray.from_gdf

• set hydromt forcing object: currently we set forcing for each setup function, type of forcings distinguished using certain convention (not harmonized), including "boundary1d_{da_out.name}{branch_type}", "lateral1d_points", "lateral1d_polygons", "boundary2d{bnd_id}", "meteo_{meteo_type}" --> this convention should be harmonized

• write forcing into Delft3D FM format: this is currently done in hydromt-delft3dfm writer functions write_1dboundary,write_2dboundary , write_1dlateral, write_meteo --> this looks sufficient for now but many of the codes are duplicated, thus can be simplified.
  These writers mainly do two things:

  1. filter the forcing objects and find targeted forcing type to write
  2. write the forcing --> duplicated codes

• Additionally read forcing is done in a similar manner as write forcing, first filtering which type of forcing it is in the .ext file, then use different reading functions read_1dboundary, read_2dboundary, read_1dlateral, read_meteo.

Things to consider (to be discussed):

• 1D boundary needs branchid and chainage
• 1D lateral at points needs branchid and chainage;
• 1D lateral at polygons requires x and y coordinates;
• 2D boundary for 1D2D applications requires a line and a single timeseries; 2D boundary for 2D3D applications requires a line and multiple timeseries.
• 2D meteo requires point(s) and one or multiple timeseries

Also good to discuss the the harmonization of forcing names, which is in the same objectives of hydromt. Issue has been created #114

Use case

No response

Additional Context

Follow up pf PR #81