Valve chamber proposals

[tudorbarascu]

• add _no_valves column to depict the no of valves inside a) manually filled in case there isn't a polygon b) computed through spatial query in the case the valve chamber area (polygon) exists
• add depth or height (in meters or cm) or altitude_radier (in meters)

Thoughts?

PS. should we enable the bug and enhancement labels here also?

[3nids]

Labels already exists here. I would probably define the behavior as an option. we could create a table qwat_sys.config and have options in there.

otherwise, good idea!

[tudorbarascu]

Regarding the qwat_sys.config could you please be more specific as I cannot follow. Thanks

PS. You mean, have a config table that through a trigger activates deactivates the aforementioned behavior in the valves chamber etc.?

Hmm, I don't seem to be able to add labels after creating the issue. I think it's only possible at the issue creation time.

[3nids]

I mean the trigger would first read the option. If it is enabled, it updates the no_valve, if not it does nothing.

[tudorbarascu]

Ok, I had first thought that a boolean column in the qwat_sys.config would enable or disable the specific behaviour (trigger) on the valve chamber. Would have been clearer. It's clear that for more advanced configs (more than turning on/off a trigger) it's better like you first thought of it. Thanks!

I have thought of naming the field "height". Please say if you have another suggestion as I would like to work towards a pull request for this.

[3nids]

I thinkjust having the option is easier to implement and probably more stable. And it's obvious that we'll have all config at a single place. But, if you prefer the idea of enabling/disabling the trigger, I'm not totally against it.

what about using altitude + vl_altitude_reference? I believe we should add this field to all installation, no?

[tudorbarascu]

I think I might not have been enough explicit:

Your nice proposal:

• Change the trigger so that it checks for the qwat_sys.config if it should do whatever it supposed to be doing or simply ignore it

I just thought of:

• Having a trigger on the qwat_sys.config table. When a row in the qwat_sys.config table is modified, the trigger will disable/enable specific triggers (behaviours) in the valve chamber table etc Both of them look really nice to me. I saw a really small advantage to my addendum as it's cheaper to just disable the trigger (by editing the qwat_sys.config table of course) then to have the trigger check each time if he should ignore the behavior or do its bidding.

Your proposal is better as it can cope with the case where multiple behaviours are modeled by the same trigger.

altitude + vl_altitude_reference sounds good.

Yes, we probably should add it to all the installations, will check out reservoirs to see if its needed also there and not interfering with something already existing

[3nids]

yes, I understood correctly. For me the advantage is rather in term of model update. With the option proposal, if you restore on a blank qwat project you don't have anything to do. With yours, you have to re-run all the options. Moreover, I am not sure we're facing any performance problem.

What do you think?

[tudorbarascu]

How you envisioned it is clearly better. The performance will also clearly not be an issue.

I was now trying gather the options for the altitude_reference.. and I have run out of inspiration for the moment. I am trying to figure out if we'll ever need multiple values here, not necesarily altitude/height related? (vertical distance from x to bottom, width/length of the building, diameter etc.).

Basically, everything that is shape related. Choose the shape (like we have in materials):

• if base is square --> length of the side + height + whatever other special things for the specific building type
• if it's rectangle --> length + widht
• circle --> radius + diameter + height or etc..
• ellipse.. etc.
• irregular shaped: ..

It started from altitude perspective but as there may be more to it.

Does this make sense?

When I'll be making the pull request, please don't merge it untill we'll talk on it as it will probably not be as slick as we'd want it to be

Of course, every option for each building should be configurable form the config table. (e.g. valves chamber should only have some of the aforedmentioned properties ) Sorry for the noise.

[tudorbarascu]

Good morning, As far as the no_valves, we could also just have the no_valves (with manual input) and a field (maybe in a view) with _no_valves (spatial query) in order to show the valve chambers where there should be X valves but the system presents Y valves --> investigation.

[3nids]

I tend to prefer the first approach. The super user knows how he filled the data and the end-user has access to a single info withtout doubts. I don't like the idea of having twice the same info.

Otherwise, it can be easily done with a view to check this info (rather than the trigger).