Document altitudes handling in data model

[3nids]

Now, that QGIS is ready to deal with 3D and that the data model was updated to 3D geometry, the question regarding workflows arises.

There is basically 3 places where altitudes are stored: nodes (valves, hydrants, installations, etc.), pipes and survey points.

In point tables (nodes and survey points), we have the information on the precision and we might provide further information such as the source of measure (gps, interpolation, dtm, etc.). In the pipe table, since it's a linestring geometry, one can't save such information there.

Hence, my proposition is that 3D in pipes shall not be considered as the place to store the altitude values but instead a process will generate automatically the 3D values based on the points tables.

One advantage of this, is that no question is needed when one moves a vertex of a pipe: what should it do? keep it? ask for new value? set it to null? With the proposed approach it will be set to null and later automatically regenerated.

One open question, is what to do when a node is inserted without any altitude on a pipe which has altitude information at both ends.One approach here would be to ask the user if altitude shall be interpolated from the pipe. Though questions about precision are a bit complex (precise point at one end, unprecise at the other end).

I would be in favor of not doing any interpolation at start. It can still be generated on the fly with views: if the node has no Z but its pipe does, just do the interpolation.

Thoughts?

[3nids]

@tudorbarascu @ldgeo @vmora thoughts?

[tudorbarascu]

In my opinion, the point tables and the geometry should be tightly coupled so that:

• changing a pipe geometry should propagate to the point/nodes tables of that pipe
• viceversa, changing a node/point altitude -> 3d geometry is changed
• when drawing a new vertex, the corresponding point altitude should automatically be calculated using interpolation (actually, if it's interpolated, we shouldn't have an altitude point for it, and always extract the altitude from the geometry)
• when updating the pipe geometry: the geometry can leave the x,y of an attached vertex if it's interpolated but cannot leave in the case if it's a survey point (fixed point)
• for an interpolated vertex, if any (left or right) vertex/node/point changes, it's altitude value should be recalculated
• the pipe geometry precision should be presented in function of all constituent vertexes

So I would be in favor of interpolating all the vertexes between two fixed nodes/points/vertexes and have an option to turn some of those vertexes into fixed points.

Thoughts?

[tudorbarascu]

One open question, is what to do when a node is inserted without any altitude on a pipe which has altitude information at both ends

IMHO it should create an interpolated vertex with altitude stored only in the geometry. Another point shouldn't be created anywhere else because any vertex that's not in the nodes/survey points table should be considered interpolated by convention.

Moreover, we should have a tool that creates a fixed point/node/survey point out of a pipe's vertex and the users will give the precision there.

[3nids]

@tudorbarascu Thanks a lot for the feedback

I believe we agree on the main lines. Indeed things are coupled. I would just make sure we don't lose any information on altitude on nodes. To ensure that, I think that we need a survey point or a node at each location where we have an altitude, then all the rest can be interpolated from that. Hence, Z values in pipes are volatile.

For nodes, the idea is to add a new value list for altitude measure origin (with measure or interpolation). That way, we can keep altitude field and Z geometry synchronized all the time.

Your idea that nodes associated to a pipe shall move accordingly is really interesting. I just wonder if it should be done on the server side (data model) or client side (QGIS map tool). The question could be brought to the user. There could be a new map tool (kind of extended topological editing) where you could move several objects at once (pipe vertex with its valve). The other way around might makes more sense: if you move a valve, its attached pipe will follow. That would be quite easy to do with triggers. The potential problem is that you have no direct feedback in QGIS (it doesn't know the pipe changed). Anyway, this is an external problem from altitude, it might be good to create its own issue.

[tudorbarascu]

@3nids Indeed, a survey point/node should be required at each location where we have altitude (that's not interpolated). Your idea that nodes associated to a pipe shall move accordingly is really interesting. I just wonder if it should be done on the server side (data model) or client side (QGIS map tool).

This question has bugged me a lot, and I think in the future we will need both as:

• having the logic client side provides the means to use other containers for the data (sqlite etc.) which in the long run would permit the work on Scenarios/Different Analyses for Hydraulics etc. decoupled from the main database.
• having the logic server side provides makes it easier to connect with other software to modify and analyze the data (Web applications, other GIS Desktop editors etc.).

So, the path would be to have both approaches. For now, I am inclining a little for the server side as it offers more flexibility but any approach would be fine to start with as I believe that in time the need for both will become more and more apparent.

Thanks also for everything!

[alexandrebosshard]

Hi Tudor and Denis,

The opinion of Pully team is:

• The survey points are the basis of the mesure (control points)
• After that, we can associate the mesure to a node
• And after that, the z of the pipe can be interpolated based on the node or survey points

If an element moves, we mesure it on the terrain, and we have a new control point.

[rogermaurer]

@3nids @tudorbarascu @alexandrebosshard

OK for:

• Z coordinate introduced manualy or recovered from mesurement on geometrie of nodes and survey point
• Attributs on nodes and survey points for precision_planimetric, precision_altimetric and measure_origin
• Z coordiante on geometrie of pipes recovered from nodes and survey points

But:

• Definition of a default altitude (for example: 0) must be avoid, because not real, false interpolation, etc.

While inserting or moving nodes or survey points it should be asked if the user introduces an altitude manualy, altitude should be interpolated from the end points of the pipe or has to be null (empty).

[3nids]

@rogermaurer you have no choice but to define a default altitude since PostGIS does not handle NULL values in Z.

Otherwise, I believe we agree on the general workflow.

[tudorbarascu]

@alexandrebosshard Hello and nice to have your team here. We have a general consensus then and I would like to add to your second point that survey measures should also be linked to a vertex. And by that I mean that a measure it's not necessarily a node. How does that sound to your team?

@rogermaurer Hello and welcome also. Please also take a look and maybe your opinion on http://github.com/qwat/qwat-data-model/issues/82

[dsavary]

Hi, The opinion of Lausanne team :

We agree the proposal of Denis “Hence, my proposition is that 3D in pipes shall not be considered as the place to store the altitude values but instead a process will generate automatically the 3D values based on the points tables “

When we move the element of the network (valve, part, hydrant …), it is necessary that the pipe geometry keep the topological link and move at the same position to regenerate the 3D geometry at any time and vice versa.
We agree this :

There could be a new map tool (kind of extended topological editing) where you could move several objects at once (pipe vertex with its valve). The other way around might makes more sense: if you move a valve, its attached pipe will follow. That would be quite easy to do with triggers. The potential problem is that you have no direct feedback in QGIS (it doesn't know the pipe changed)

In our current database system (topobase), the z coordinate is handled at the following objects: valve, part, hydrant, subscriber, installation and construction point. The subscriber, installation, hydrant are necessarily placed on a node where a 3D geometry is defined in the data model QWAT. However, in our case, the valve, part and construction point are not always positioned on a node. They can be positioned on a pipe vertex (passing point) and then have an influence over the automatic geometry 3D generation.

Concerning the interpolation, it’s important to have a semi-automatic tool (small user operation) that can calculate an interpolated altitude in the following cases: • If the altitude is unknown on an network element (valve, hydrant …), it should be possible to calculate a interpolated altitude by using the nearest points having known and measured altitude. • When the pipe is curved, we insert several construction points along a reference curve measured by 3 survey points. It’s necessary to be able to calculate an interpolated altitude for each construction point over which the pipe passes.

For Lausanne, we would use the table “surveypoint” to store and archive all the measure taken on the field and to preserve the traceability (link) with the network objects. These points are fix and control points and the survey point table should not be edit by the users (not to move point position). On the other hand, it’s possible that some survey points are used as construction point to draw a precisely pipe path (curved pipe) and don’t belong in the category of node or network element. Therefore, it would be great to have a 3D geometry in the table construction point and to use also this table to generate the pipe 3D geometry.

Concerning the information on the precision and reliability of altitude, we agree with the proposal : “ In point tables (nodes and survey points), we have the information on the precision and we might provide further information such as the source of measure (gps, interpolation, dtm, etc.). “ It’s important to have also the information on the precision and reliability for each pipe. We could create a trigger that describes the precision estimated on the basis of the precision at each vertex/ node of the pipe.

[vpicavet]

Full summary / documentation here, to be reviewd :  https://github.com/qwat/QWAT/wiki/Elevation-in-qWAT

[vpicavet]

Linked issues :

• implementation in model : #112
• end-user tools in #113 #114 and #115