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

reach points do not move when moving a wastewater_structure #313

Open urskaufmann opened 1 month ago

urskaufmann commented 1 month ago

Describe the bug I try to rewrite the chapter 3.3.2 Moving... and I do not understand what really happens when I move a wastewater structure (point in vw_tww_wastewater_structures). Look the pictures. I turned the topology on to show the move. image

As a result of the move, the Input-levels should change. Before is I1=2736.51, I2=2736.52, after it should be I1=2736.52, I2=2736.51. But the label does not change. image

I then save all edits, and I refresh network topology (SQL-button). The label does not change. image

Really strange is, that the network_nodes (vw_network_node) stay at the old place. After the move, there is no node or cover at the place, where there are still the network_nodes. I choose again refresh network topology, close QGIS and restart, refresh, but the network_nodes stay at the old place....

What happens here? Why this behaviour? How to correct this? If I change e.g. the vertex of the reach with to-level 2736.51, then this network node changes with the SQL-button and the label changes as described above. But this can not be a solution...

Desktop (please complete the following information):

cymed commented 1 month ago

When moving a tww_app.vw_tww_wastewater_structure instance, the following geometries are translated in x and y direction:

There is no changing of the field values of reach_point.level, thus no alterations to the labels. Also, a corresponding detail geometry is not moved either (which imho is a bug).

You write that the labels should be updated for the input and output geometries. Did you alter the corresponding values in tww_app.vw_tww_reach?

ponceta commented 1 month ago

@urskaufmann on this precise spot in the demo data from VSA (2645121.91, 1149929.21), I could reproduce some very strange issues. The reach points are not moving correctly and then it breaks the refresh sql function.

2024-07-16T15:47:31     WARNING    Traceback (most recent call last):
              File "C:\Users/pulpoar/AppData/Roaming/QGIS/QGIS3\profiles\pulpoar/python/plugins\teksi_wastewater\teksi_wastewater_plugin.py", line 374, in refreshNetworkTopologyActionClicked
              self.network_analyzer.refresh()
              File "C:\Users/pulpoar/AppData/Roaming/QGIS/QGIS3\profiles\pulpoar/python/plugins\teksi_wastewater\tools\twwnetwork.py", line 163, in refresh
              transaction = self.nodeLayer.dataProvider().transaction()
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
             RuntimeError: wrapped C/C++ object of type QgsVectorLayer has been deleted

If I move other wastewater structures or reaches it works well.

ponceta commented 1 month ago

I think I got it :

image

But if you move the reaches separately, reach point should follow.

image

urskaufmann commented 1 month ago

You write that the labels should be updated for the input and output geometries. Did you alter the corresponding values in tww_app.vw_tww_reach?

No, I did not change the level-values. I wanted to show with this example also the rules, how I1, I2 etc are defined. This works with the azimut of the latest reach-segment before the wastewater node. With the move in the example, the reach from manhole EK2 has new an azimut, that is bigger than the azimut of reach 1000 CS. So the I1 and I2 labels should change and this would also show, that every thing is calculated as expected. Because this labels did not change (not the levels, but the order of the input-reaches), it showed me, that some thing is wrong/not as expected.

PS: the mentioned rule with the azimuts works in most cases, but it shows not always the correct order of the reaches in the manhole (starting with azimut=0(north) and then clockwise).

cymed commented 1 month ago

0 is not north, but azimuth of O1

urskaufmann commented 1 month ago

Sorry, forget this thing about the labels... Imo we have really a big problem if this reachpoints are not where the should be. There are four ways to move a record in vw_tww_wastewater_structure: with tool "Move Feature" or "Vertex Tool", both of them with Topological editing on or off. I tried all 4 possibilities and restarted QGIS after every try, because if I continue several tries, I got not always the same result and I don't no why (what is of course also not good). A try means: start TWW-project, enable editing of vw_tww_wastewater_structure, select topological editing on or off, choose the tool. Move the manhole 1.062 to the right. Take a screenshot. Click the TWW-SQL-button and refresh the screen that you can see the topology-layers (vw_network_segement and vw_network_node). Screenshot. Repair the whole thing, that every thing is as at the start (move back, SQL again, save, Quit QGIS).

The result:

  1. try, vertex tool and topology editing on: I get error messages, because the topology-layers can not be changed by the tool. Node and vw_tww_wastewater_structure-record do not move similar with cover and reaches. 1Fehler2 After SQL, there are several vw_network_node-nodes missing: 1SQL

  2. try, vertex tool and topology editing off: no errors. After Moving it looks as expected: 2move after sql it shows, that the reach points have not moved: 2SQL

  3. try, move features tool, topology editing on: no errors. After Move the same as try 2, means ok: 3move

After sql, the same as try 2, not ok: 3sql

  1. try, move features tool, topology editing off: same results as try 2 and 3...
urskaufmann commented 1 month ago

one of the mysterys of this tries was, that at some cases, I was not able to move back the manhole 1.062 with the vertex tool, and that in these cases it was not possible to move the vertex points of the reaches, because the vertex tool did snap to the reaches at the old place and not at the place where the lines are drawn!: snap_not_where_line

At the end, I did an export of these lines after a try 3 (SIA405 export, only selected reaches, saving after the move). Export was successful: export_successful

I did open this xtf-file with QGIS: xtf_file

There are five reach-points at the old place and the reach-lines do not end at the reach-points place! It's a no-go!!

urskaufmann commented 1 month ago

I think I got it :

  • Move a wastewater structure linked to reaches without having QGIS topology editing "ON" will adapt reach geometries but will not update reach points.

Topology editing on or off: it's always the same behaviour: reach geometries do update, reach points do not update.

cymed commented 1 month ago

The result:

1. try, vertex tool and topology editing on: I get error messages, because the topology-layers can not be changed by the tool. Node and vw_tww_wastewater_structure-record do not move similar with cover and reaches.

I see two problems here: first, you try to update a materialized view and second, the geometry type of tww_od.network_segment should be CompoundCurve. We should set the topology layer to "not editable" in the project file.

   After SQL, there are several vw_network_node-nodes missing:

No clue why this happens, maybe due to the error message.

4. try, move features tool, topology editing off: same results as try 2 and 3...

This can be solved in the trigger function, Pull request following

urskaufmann commented 1 month ago
  1. I set vw_network_segment and vw_network_node in project/properties/data sources to "read only". This works, there is no error when using topological editing for moving.
  2. I updated my ft_vw_tww_wastewater_structure_update in the database with the new lines (move reach point nodes as well) and it works.
  3. When using the vertex tool to move the manhole (vw_tww_wastewater_structure) with topological editing, I have the situation, that wastewater_node and vw_tww_wastewater_structure points move as expected, the cover and the reach line-endpoints that where at the manholes place move twice the distance, the reach points follow the reach line-endpoints. I then use the undo-button, the points move back, but the reach line-endpoints move just one distance back, means the are then at the place, where I have moved the vw_tww_wastewater_structure-point before

image Start situation

image move with vertex tool, topological editing, cover and reaches I1, I2 move double distance

image after undo-button: reaches I1 and I2 and cover are half way back nomore undo possible (just discard saving helps).

This behaviour only with vertex tool and topological editing. Without topological editing and with move features tool it works

cymed commented 1 month ago

The problem is that with topology_editing, we move the reach position in the qgis project first and then apply the dx/dy on the wastewater structure afterwards. We cannot support both ways of editing.

For me, using the topology setting is more intuitive than having a blackbox on the database move your geometries.

urskaufmann commented 1 month ago

It should work if the reach ends/starts at the wastewater_node and also if the reach ends/starts not at the wastewater_node (nicht Pickelloch-Modell). Topological_editing works with Pickelloch. Does it really work also with "not-Pickelloch"?

cymed commented 1 month ago

With "not-Pickelloch", QGIS does not detect the topology, so only the db side triggers are used. Should we trigger the movement of reach/reach_point on the db only if there is a detail geometry?

urskaufmann commented 1 month ago

I have a not-Pickelloch Werkplan, where node, cover and reachpoints have each seperate geometry also with manholes (Normschacht NW 800, 1000, 1100/900 etc) without detailgeometry. For me, this triggers are necessary.

I think it would be nice/should be the goal, that the way the user moves a manhole (vertex tool or move features tool, with/without topological editing) does not matter, the result should always be the same. If this is not possible, we have to write it in the docu very clear (the docu must be rewriten anyway).

cymed commented 1 month ago

I think having the same result with and without topological editing is not feasible