A unified, database-centred approach to GIS, hydraulic modelling, operational monitoring and field work with MAPtheYA©

WHITE PAPER •  CONSORTIS GEOSPATIAL  •  JULY 2026

1. The fragmentation problem

A water supply network is simultaneously a physical infrastructure system, a hydraulic system and an operating service. Its pipes, valves, pumps, tanks and reservoirs must be accurately located; their behaviour must be simulated under changing demand and operating conditions; and their performance must be observed through meters, sensors, inspections, faults and interventions.

Traditionally, each need has been addressed by a different application and data store. GIS teams maintain geometry and asset attributes. Hydraulic engineers work with a separate hydraulic model on a copy of the network. Operational teams use SCADA, IoT dashboards, spreadsheets, ticketing platforms, ERP or customer-management systems. Each tool may be effective in isolation, but the boundaries between them create recurring problems: duplicated data, mismatched identifiers, stale hydraulic models, manual exports and imports, and field events that cannot be reliably traced back to the affected asset.

The operational consequence is more serious than simple inconvenience. A pipe may be moved or split in the GIS but remain unchanged in the hydraulic model. A valve closure may be recorded in an incident system without being reflected in the scenario used for analysis. Sensor readings may be visible on a dashboard but not associated with the topology and characteristics of the network around them. Over time, the utility loses confidence in which representation is authoritative - and, with it, part of its institutional memory.

2. MAPtheYA©’s differentiator: one authoritative network

MAPtheYA© is designed around a different architectural principle: that the network should be represented once, in a central spatial database, and reused across workflows. PostgreSQL/PostGIS stores the geometry, attributes, connectivity and identifiers of network assets alongside the relational information needed by the application. PostGIS is specifically designed to keep spatial and conventional relational data together, using the same transactions, constraints, access controls, backup mechanisms and application connections [2].

This does not mean that MAPtheYA© must replace every corporate application. SCADA, ERP, billing and maintenance platforms can remain specialised systems. The difference is that integration occurs around a stable, shared network model exposed through REST APIs and open geospatial services. The database becomes the common spatial and asset-reference layer, rather than another isolated repository.

3. Four workflows, one data model

Editing: maintaining the network as it actually exists

In MAPtheYA©, the map is the primary working environment. Users create and update pipes, nodes, valves and other assets through structured forms and web-based drawing tools. Snapping, topology checks, required fields, controlled value lists and attribute validation are part of the workflow. These controls are particularly important in water networks: two objects may appear connected on screen while remaining disconnected mathematically, causing a hydraulic model to fail or produce misleading results. Multi-user editing allows technical teams to work on the same network without creating parallel local copies.

Modelling: deriving analysis from the authoritative network

EPANET is a widely used public-domain application for modelling water-distribution hydraulics and water quality. It can calculate flow in pipes, pressure at nodes, storage-tank levels and other system behaviour over time [1]. MAPtheYA© uses the EPANET engine through epanet-js, but changes the surrounding workflow: the simulation model is generated from the network held in the database, rather than maintained as an unrelated file.

What-if scenarios run in a sandboxed environment so that the live master network is not altered. Operators can test changes such as valve closures, out-of-service pipes or different demand patterns, then return results to the same map as thematic colours, reports and time-series charts. The map becomes both the starting point and the destination of the analysis. 

Monitoring: connecting measured and predicted behaviour

The monitoring pillar places sensor, IoT and metering information in the same spatial context as the assets and simulation results. A user can select a station, inspect current and historical readings, and understand where that measurement sits in the hydraulic system. The longer-term value comes from comparing observed and modelled behaviour: expected versus actual pressure or flow can support model calibration, anomaly detection and more focused investigation. The US EPA’s EPANET-RTX work similarly demonstrates the value of connecting operational data with hydraulic models for calibration, verification and real-time analysis [1].

Operate: turning faults and alerts into scheduled, crewed work

The fourth workflow closes the gap between recognising a problem and carrying out the response. Faults reported by phone, email or the utility portal enter MAPtheYA© through APIs and appear on the network, linked to the affected asset instead of remaining as detached tickets.

From there, any fault can become a Kaskal work order. Kaskal is Consortis Geospatial’s crew- and work-management app; its guided wizard lets the user select defects, add pay items, schedule the job, assign the crew and notify stakeholders. The result is a traceable chain from alert to field action, without re-keying information across systems.

4. Why the unified approach matters

•  A single source of truth. Geometry, topology, asset characteristics and hydraulic references no longer drift independently.

•  From alert to action. Faults move from API intake to network location, Kaskal work order, crew assignment and stakeholder notification in one connected process.

• Built-in data quality. Validation and topology rules are applied when information is created, not only during periodic syncing.

•  Lower integration overhead. The organisation reduces repeated file exchange, custom synchronisation scripts and reconciliation between competing identifiers.

•  Open interoperability. OGC standards support geospatial exchange, while modern OGC APIs use REST, JSON and OpenAPI patterns [3]. MAPtheYA© combines these with RESTful integration so external GIS and enterprise systems can exchange information without proprietary lock-in.

•  A realistic digital-twin foundation. A shared database, scenario engine, measured data and asset-linked work provide the progression from static mapping to an operational model.

5. A staged path to integrated network management

Adoption can be staged: establish authoritative geometry, identifiers and topology; generate hydraulic analysis from that network; associate sensors and events with the same assets; then close the loop by converting faults into Kaskal work orders. The workflows may mature at different speeds, but they retain one network reference and one chain of accountability.

Digitalisation in the water sector is increasingly an organisational capability, not a collection of isolated tools. The International Water Association promotes integrating digital approaches into water services [4]. MAPtheYA© makes this concrete through one database, a map-centred workspace and open links to specialist systems such as Kaskal.

References

[1] U.S. Environmental Protection Agency, “EPANET: Application for Modeling Drinking Water Distribution Systems.” https://www.epa.gov/water-research/epanet

[2] PostGIS Project, “What Is PostGIS?” https://postgis.net/docs/manual-dev/en/postgis_introduction.html

[3] Open Geospatial Consortium, “OGC Standards.” https://www.ogc.org/standards/

[4] International Water Association, “Digital Water Programme.” https://www.iwa-network.org/projects/digital-water

[5] epanet-js project, “EPANET in JavaScript / browser and Node environments.” https://github.com/modelcreate/epanet-js

[6] Consortis Geospatial, “MAPtheYA  – A Unified GIS Ecosystem for the Smart Water Network Management”, FOSS4G Europe 2026, Timisoara, Romania. https://talks.osgeo.org/foss4g-europe-2026/talk/NLX383/