Setup of a Timflow model: elementwise or in tabular form?

[MattBrst]

Yesterday at the TIM meeting in Delft I had an interesting talk with @Huite about ways to set up a model. I would like to share the thoughts here as I think these might be useful in the further development.

As an illustration, let's take a steady-state model where we want to add many wells.

Elementwise (current Timflow approach) looks like this:

well1 = tfs.Well(model=ml, xw=0, yw=0, Qw=100, rw=0.2)
well2 = tfs.Well(model=ml, xw=10, yw=0, Qw=100, rw=0.2)
well3 = tfs.Well(model=ml, xw=20, yw=0, Qw=100, rw=0.2)
well4 = tfs.Well(model=ml, xw=30, yw=0, Qw=100, rw=0.2)

Tabular (current QGIS-TIM approach) would be:

1. Create a GeoDataframe for all wells (with geometries and discharges):
2. Loop over the rows to add the wells to the Tim model

In the tabular approach, a Timflow model consists of no more than:

• A table (Dataframe) with the geohydrological properties for all inhomogeneities
• Some tables (GeoDataframes) with wells, rivers and other spatial element types
• A script which assembles the TIM model from the tabular data.

According to Huite, he already has much of the requested functionality in the 'gistim' part. He suggested the first step would be to document the 'gistim' API. We think the tabular approach would also make it possible to 'convert' a TIM-python model into a QGIS-TIM model, so it might be worth to consider the tabular approach for Timflow as well.

---

And here some illustrations from the QGIS TIM tutorial to show what these tables look like in QGIS:

[MattBrst]

Today I got the suggestion that a TIM model could even be a geopackage containing the different layers. This is the current way of defining a model in the QGIS-TIM plugin.

A geopackage is a small sqlite database file: open standards and easy to use.

[Huite]

Indeed, I think this is feasible. It's worth identifying that there are two steps:

• From a Tim entity to table (e.g. pandas DataFrame). Because the number of layers is constant across a model, this is relatively straightforward, but it does require a number of somewhat arbitrary choices.
• From a collection of tables to a canonical model definition in file form (anything that supports multiple tables).

In principle, the translation to table form isn't necessary for the second step. Model input can be stored in an unstructured format as well (e.g. JSON). For input that has both geometric data and time series data, the translation to table isn't entirely straightforward and requires a level of indirection (e.g. a linking ID). But tables have the benefit of imposing some structure and making it generally easier to inspect.

Anyway, my thinking now is along the following lines. We currently have a one-way conversion from QGIS to Tim Python structures. In principle we can adapt this slightly and also allow conversion the other way around:

• We isolate and adapt the current schemas from the QGIS part
• We then utilize these to generate QGIS specific schemas (concretely: vector layers)
• We also utilize them to generate pandas specific schemes (dataframes)
• gistim contains some logic to write geopackage tables without GDAL/OGR to lighten the dependency tree of the pyinstaller executable I bake
• We can probably add geopandas as an optional dependency to add convenience
• Expose the API properly, documented
• Publish it under gistim (https://pypi.org/project/gistim/)

So:

QGIS vector layers <--> geopackage <--> table <--> Tim

To serve your goal, I think you'd want the ability to present the tables as e.g. Excel tables. This is easily done by converting to pandas DataFrames; you're then free to write them to whatever format, with the geopackage being the "blessed" form.

[MattBrst]

Maybe one more thing to keep in mind: The form that I am working with are the 1D-models, which as far as I know are not included in QGIS-TIM.

[Huite]

That's indeed an important detail -- it requires some extra schemas and they can converted to tables just as easily.