Elevation query
Retrieve terrain elevations for all network nodes from an online elevation service and apply them as z-coordinates
Overview
The elevation query automatically assigns terrain elevations to all nodes of the active network. To do this, the node coordinates are sent to an online elevation service and the returned elevations are applied as z-coordinates.
The node elevations are the only elevation information VICUS Districts has - there is no terrain model in the proper sense. They produce the geodetic pressure component , and that component takes effect in three places:
- in the path profile and in the pressure quantities of the steady-state calculation, as soon as the option Consider geometric height is enabled,
- in the network report, which checks the pressure profile between energy center and index point against the nominal pressure rating and the minimum operating pressure and prints the geodetic height as a diagram of its own,
- in the dynamic simulation: the node elevations are transferred into the calculation model on export, each of them referred to the reference node of the pressure maintenance.
Why elevation differences govern the pressure balance, which data are suitable as a basis and how accurate they have to be is described in the knowledge article terrain elevation and topography in network planning.
How to open
The 
Query elevations button in the Topology editing group - 
Network tab, General & topology page.
Prerequisites
| Prerequisite | Explanation |
|---|---|
| Valid coordinate origin | The project must be georeferenced (coordinate origin with UTM zone). The origin is set automatically when importing OpenStreetMap or GIS data, but can also be defined manually. |
| Internet connection | The elevations are retrieved from an online service (Mapy.com Elevation API). |
Procedure
- VICUS Districts converts the position of each network node via the coordinate origin into absolute UTM coordinates and from there into geographic latitude and longitude.
- The coordinate list is sent to the elevation service; a progress dialog (Retrieving elevation data.) shows the ongoing retrieval.
- The smallest returned elevation is set as the new z-height of the project origin. Each node receives its elevation relative to this minimum as its z-coordinate:
- All remaining networks in the project are corrected by the origin shift so that they retain their absolute elevation.
- After successful completion, a confirmation message appears.
The query affects the active network only. Nodes you add later - drawn pipes, consumers connected afterwards, branch nodes inserted when creating intersections - keep z = 0 until you repeat the query.
The change is recorded as a single undo step (Updated elevation data.) and can be fully reverted with Ctrl+Z.
Absolute and relative elevation
Node positions are stored relative to the project origin in VICUS Districts. The absolute terrain elevation of a node only results from adding the z-coordinate of the origin:
Because the elevation query sets the lowest elevation it finds as the new origin, the lowest node of the active network afterwards sits at z = 0 - and the origin shifts with every repeated query as soon as the network has since been extended downhill or uphill. So do not rely on a z-coordinate you noted down still designating the same spot in the terrain after a second query.
Which of the two figures the interface shows depends on where you look:
| Display | Value shown |
|---|---|
| Node label in the 3D scene (Text labels: Elevation or Node name (elevation)) | absolute elevation |
| Summary of the steady-state calculation, section Height differences (highest point, position of the energy centers) | absolute elevation, followed by the difference to the highest point |
| Network report, diagram Geodetic height and section Height differences | absolute elevation |
| Path profile of the steady-state calculation, quantity Height and table column Height [m] | z-coordinate relative to the project origin |
| ΔZ input field when moving a selected node | z-coordinate relative to the project origin |
For the hydraulics the difference is irrelevant - only the difference between two node elevations enters the geodetic pressure component, and that is the same in both reference systems. When comparing against planning documents or against values from an official survey, however, you have to know the reference.
Data source and accuracy
The elevation service returns terrain elevations from a digital terrain model, that is from the earth’s surface without vegetation and buildings. For Germany, Austria and the Czech Republic it draws on national, LiDAR-based models; the accuracy there is in the metre range and is sufficient for preliminary and detailed design.
What is applied is the terrain surface exactly as the service returns it. VICUS Districts corrects neither the burial depth nor the vertical datum of the model: the node sits at terrain level, not on the pipe axis, and the elevations keep the datum of the service. As long as the route runs at a constant depth throughout and all elevations come from the same source, both cancel out again in every elevation difference.
To put the required accuracy into perspective: 1 m of elevation difference corresponds to roughly 0.1 bar, 10 m to roughly 1 bar. An elevation error of a few metres therefore shifts the pressure level noticeably. How terrain model, surface model and pipe axis differ, and when an official survey becomes necessary, is described in terrain elevation and topography in network planning.
Elevations from imports
Not every network needs an elevation query - depending on their origin, the imported data may already carry elevations:
| Source | Elevations |
|---|---|
| GIS import (GeoJSON, Shapefile, GeoPackage) | The z-values are taken from the geometry and transformed into the coordinate system of the project just like x and y. Purely two-dimensional geometries yield z = 0. |
| STANET import (CSV) | The geodetic height comes from the GEOH field of the node table. If the field is missing, 0 is assumed. |
| OpenStreetMap import | no elevations; the import only sets the georeferencing of the project |
| Drawing a network | no elevations; new nodes are created with z = 0 |
A subsequent elevation query completely overwrites the existing z-values of the active network. So do not run it as a matter of routine if your GIS or STANET data set already contains surveyed elevations - as a rule these are more accurate than an online elevation model.
When no elevations are queried
Without an elevation query and without elevations from an import, all nodes sit at z = 0. The network can still be calculated, but it is entirely flat:
- The geodetic pressure component is zero. The option Consider geometric height has no effect - whether it is set or not makes no difference to the pressure quantities.
- Under Height differences, the summary reports 0 m for the highest point and for all energy centers.
- The calculation runs through without a warning. There is no message pointing out missing elevations.
Results and the pressure limit check then apply to flat terrain only. So before assessing an operating point, check whether the elevation differences are plausible - a row showing 0 m in a topographically varied planning area is a sure sign that the elevation query is still outstanding.
Error cases
| Message | Cause and remedy |
|---|---|
| No valid coordinate origin set | The project is not georeferenced. Import OpenStreetMap or GIS data or set the coordinate origin manually. |
| Error in coordinate conversion | The computed latitudes/longitudes are invalid - check whether the origin coordinates and UTM zone are set correctly. The message names the affected node with the computed coordinates. |
| No elevation data could be retrieved from the server | No connection to the elevation service - check the internet connection; details may be in the attached error message. |
Checking and correcting
After the query, a visual check is worthwhile: leave 2D mode or rotate the view to check the elevation profile of the routes spatially. Outliers (e.g. from nodes on bridges or in excavation pits) stand out immediately in the side view. With Text labels: Elevation or Node name (elevation), VICUS Districts writes the absolute elevation next to every node.
For a check in numbers, use the path profile of the steady-state calculation: the quantity Height plots the elevation profile of the path over the route length, and the table column Height [m] lists the z-coordinate section by section. With 
Export table to CSV you take that column out of the program for a comparison with planning documents.
Individual nodes are corrected by hand: select the node in the 3D scene, choose world coordinates as the reference mode in the Move tool and enter the desired value in the ΔZ field. It is applied as a z-coordinate relative to the project origin.
A repeated elevation query overwrites all manual corrections of the active network. So only correct once topology and elevations are otherwise settled - or record the corrections in a way that lets you reapply them after a further query.
Practical tip
Run the elevation query only once the topology is essentially in place - that is, after Create intersections and Connect consumers. This way the automatically inserted branch nodes (mixers) also receive a correct terrain elevation. On topographically varied routes, the geodetic pressure heads have a major influence on the index point and the required pump head.