QGIS: Show data for selected nodes

[visr]

In QGIS you can select one or more nodes:

This can be used to show the Node table for those nodes:

However, if you want to see the data associated with this node, you need several extra steps. For instance, open the "Basin / profile" table, apply a field filter on node_id, and enter the node ID you selected manually.

Ideally a user can directly see and edit all data for a selected node. Perhaps we can for a node of type X, automatically apply a field filter on all tables X / * to show this. Or perhaps some other way that integrates nicely with existing QGIS functionality exists? Like perhaps automatically doing some kind of joins between these tables.

It looks like this would also be needed for #790.

[deltamarnix]

We are looking for QGIS joining and relations: https://docs.qgis.org/3.34/en/docs/user_manual/working_with_vector/joins_relations.html#setting-relations-between-multiple-layers

I did some small tests. joining is nice when there is a 1-to-1 relation between features in different layers. For example: Basin / state or Basin / area.

I made a model and added Basin / area and Basin / state. Then I set a Joins property on the Basin / area layer. When I then create a layer, and fill in the node_id, it automatically matches the node_id and gives me the information about the node. And I also tried it the other way around. On Node I set a relation to Basin / state, and when you add a new node, it will automatically add a row in the Basin / state if it's not there.

The other option is useful for 1-to-N relations, like Basin / time. Then it's better to use relations and it looks more like this:

Both joins and relations are stored in QGIS project files, which means that we have to initialize all those relations every time we will open a toml file. The other option is that we start working with QGIS project files and let users open their projects that way, instead of the Open button in the Ribasim plugin.

[Huite]

Oh, the relations thing looks very good! Does it provide a good table view as well?

That is, what if you click this button:

[deltamarnix]

Clicking that button will just bring you to the table I guess.

Another option would be to add relationship tables with SQL queries inside of the geopackage. In that way it is not stored in a qgis project, but in the geopackage itself.

[Huite]

A possible risk with storing it inside of the geopackage is that QGIS / OGR will not be smart enough to see through it when it matters.

For example, if you have transient data associated with vector features, one way to make it known to QGIS is by simply duplicating the geometries for each timestamp and using the Temporal Controller to manage what to show. This has the unfortunate downside of making QGIS quite slow to draw the vector features. The reason is that it's filtering over all features whenever you pan the map view to decide which ones to show.

My guess is: if you store inside of the geopackage, it won't realize the geometries are duplicates. My second guess is: it will know the geometries are duplicated if you set it up via this relationship thing.

You could test it by mocking up e.g. 5 basins with a hundred thousand timestamps or something.

[deltamarnix]

More information:

• https://gis.stackexchange.com/questions/482335/how-to-store-relationships-in-geopackage-with-qgis
• https://github.com/qgis/QGIS/pull/49504

[Huite]

Looks like the second link disproves my guess! That would be excellent news and we would able to keep everything contained in a geopackage.

[evetion]

• [ ] Ideally we implement relationships in gpgk (manually writing those tables) as described here https://docs.ogc.org/is/18-000/18-000.html
• [ ] Test and document how this works in QGIS

[evetion]

So there are roughly three paths for getting the relationship info in QGIS:

• Implement foreign keys in SQLite and use discover relationships in QGIS
• Use the GPKG relation extension and populate all the required N-N tables.
• Make the relationship in QGIS (only)

I like the first option, but SQLite tables can't be altered after creation, so I need to generate the SQL statements myself. I've got it working for pure pandas (so all non-spatial tables), but spatial tables is another beast (ogr generates the schema, not pandas). Besides, it would require duplicating the functionality in PyQGIS (even harder) for all models created there. Still, we might even keep the non-spatial tables foreign key creation in Python, it makes the GPKG "better" imho.

However, I now implemented the third option, which works pretty well. I haven't yet found a way to quickly filter the attribute table, but this is already useful and should be merged:

Identification results

Form with table view (as asked by @Huite above

[evetion]

With a few events (changedselection) attribute tables are selected in sync with Node selection.

Note it needs a fix for the Edge, as only the (last) relationship to_node_id is used, not selecting all related edges.