search

teksi / wastewater

[DEV] Future TEKSI wastewater module, adapted data model to fit VSA-DSS 2020 new standard
https://teksi.github.io/wastewater
GNU General Public License v3.0
0 stars 5 forks source link

dataowner, provider in vw_tww_reach #225

Open urskaufmann opened 3 months ago

urskaufmann commented 3 months ago

there is no attribute ws_fk_dataowner and ws_fk_provider. there are the attributes for the reachpoints and for the reach (means for the networkelement). But the more important (in my opinion) is the one of the wastewater_structure. like that I can not manually set dataowner or provider for the wastewater_structure. I hope I have got the actual datamodel (tww_dev_structure_with_value_lists.sql 09.04.2024 16:19)

ponceta commented 3 months ago

That's an issue linked to how we actually want to use the actual datamodel implementation What is the use case of having fk_dataowner and fk_provider on both :

as I understand it so far, it is better to user the networkelement which is then the same for :

If required they can be added easily but it's good for everyone to understand their usage.

ponceta commented 3 months ago
sjib commented 3 months ago

The question is, if we still have cases where the cadastre is done by one engineering company and the hydraulics by an other? Or different experts using TEKSI. And that we want to distinguish this between wastewater_structure (meanging the constructive part) and wastewater_network_elements (wastewater_node / reach as hydraulic parts)?

urskaufmann commented 3 months ago

Im do not think it's good do set these attributs dataowner and provider through the nodes and reaches, just because we use there geometry in QGIS. If I add a second wastewater-node and forget to set the dataowner -> will it then change the dataowner of the wastewater_structure or ask me, which one is correct? We can do it like this, if the dataowner is set automatic in the connected classes as @ponceta describes. For me it's more logical, that normally the wastewater_structure is the class to define the dataowner and the other classes will inherit (if there is no entry).

I can not underwrite, that there will never be a case, where a node must have another dataowner than the wastewater_structure. If this case occures and there is no dataowner-field for this case in the view, you will have to go to postgres or load the table itself or something else not userfriendly to be able to change the value. If the fields are in the view, they must not be in the attribut-form, but I can easly set a new value with the field-calculator.

In vw_tww_wastewater_structure we have both fields (fk_dataowner = wastewater_structure.fk_dataowner, wn_fk_dataowner = wastewater_networkelement.fk_dataowner).

In vw_tww_reach we have fk_dataowner = wastewater_networkelement.fk_dataowner and should have also ws_fk_dataowner = wastewater_structure.fk_dataowner. The other two reachpoint-fields (rpfrom/rp_to_fk_dataowner should be skiped, because I'm shure, there will never be a reachpoint with a dataowner that is not the same as the reach-dataowner... All I wrote above for dataowner is similar to the provider-attribute.

I agree, that it must be well documented, how TEKSI fills dataowner and provider from default-value, from user entry and without user-entry and what happens, if we manually change a value after

cymed commented 2 months ago

The solution I suggest in #173 is to

Also, the PR includes the fields in vw_tww_reach

ponceta commented 2 months ago

@cymed I like this approach because it fills the information correctly in all classes of the datamodel and keeps it up to date.

ponceta commented 2 months ago

Last step is to include this table and settings to the .qgs project