FUNCTION: tww_app.update_wastewater_structure_label has old code for rainwater instead of surfacewater

[urskaufmann]

Describe the bug
If there is more than one output in a manhole, then the order of the the labels (O1, O2) is not calculated the same way as the inputs.
Look in FUNCTION: tww_app.update_wastewater_structure_label

Inputs: ORDER BY ST_Azimuth(RP.situation3d_geometry,ST_PointN(RE_to.progression3d_geometry,-2))/pi()*180 ASC)

Outputs: ORDER BY array_position(ARRAY[4522,4526,4524,4516,4514,4518,520,4571,5322], ch.usage_current),
ST_Azimuth(RP.situation3d_geometry,ST_PointN(RE_from.progression3d_geometry,2))/pi()*180 ASC),

I did no more know, that the usage_current is important for this order. To be corrected: the code for rainwater (before 520, now 9023 for surface water) has to be changed!

Before I describe this behaviour in the docu: Is it correct to have this output-order by usage_current or would it not be better to order like the inputs only with the Azimut?
I think today, it's confusing, if there are different rules for inputs and outputs.

Additional context
Are there other functions / triggers, where the code of usage_currrent for rainwater is used (and should for TWW be changed to code of surface water)?.

@cymed : Du hast einmal einen guten Vorschlag gemacht, dass der Filter mit der Funktion_Hierarchisch für die Einlauf-Labels nicht in der Funktion hartcodiert definiert wird. Ich finde diesen Vorschlag nicht mehr. Wie ist der Stand?

[cymed]

Hardcoding is fixed in #353. We have a flag tww_is_primary to filter pwwf.% entries.

I also recall suggesting a database extension "tww_use_in_labels" or similar to filter which functions_hierarchic are used, Easy to implement, is now included in #353

The difference in input and output order are partly desired. We calculate in #353, we now calculate the azimuth based on the orientation of the main outflow