Reports and Papers
River basin objects
WaterWare describes a river basin by sets of interacting objects, which are spatially referenced. RiverBasinObjects represent real world entities: such as catchments, reservoirs, cities, or treatment plants. NetworkObjects represent a different layer of (model specific) abstraction, including the nodes and reaches of a network representation of the surface water system. ScenarioObjects represent model oriented collections of instantiations of NetworkObjects that are partially derived from, and linked to, the RiverBasinObjects.
All objects are spatially referenced, that is, they are known by location, both through their coordinates as well as through being members of larger geographical object classes such as administrative units (states, provinces, communities) or hydrographic units (subcatchments). This allows their display on the various maps and the selection of objects from the map, as a single point (observation station), as a reference point designating a larger object (lake, city), as a rectangle including one or several points or polygons (irrigation district), or a as polygon (subcatchment). It also makes it possible to aggregate or average their behaviour over these units. The GIS provides the base layer of data, as well as a set of display functions (Figure 1, Figure 2)
Objects have two main functions:
For example, subcatchment objects (Figure 3) use the rainfall-runoff model RRM (Figure 4) to obtain the runoff from the catchment under a set of landuse, internal water use, and meteorological conditions (the latter are obtained as time series from one or several climate station objects); this runoff, in turn, is used by the water resources model WRM as input for a start node (subcatchment node). In the same way, demand nodes in WRM are linked to various river basin objects (settlement, industries, irrigation districts), and obtain their detailed behavior over time (eg., water demand, consumptive use coefficients, losses, etc.) from these objects. Through the location of objects, the linkage to the GIS layers is established, so that spatial concepts (such as catchment, river reach, or the neighborhood of a point location, elevation, slope, and distance) can be used for calculations (methods) by the objects.
The RiverBasinObjects in WaterWare are grouped by classes.
Classes currently supported are:
Each class has a set of specific attributes, organized in a set of data structures and associated methods. Individual objects (instantiations) inherit their basic properties from their class. They may be linked to other objects, for example, a treatment plant may lead on to a flow and a water quality observation station and its data, and objects have links to hypertext files that provide further explanation, meta data, and context. Objects have methods available, which allow them to obtain some of their dynamic or derived individual properties in a specific context. Many object properties are static and can be stored in their respective data bases and files; since methods are arbitrary functions, these references can be simple read statements from local files, an embedded SQL call to a local or network-accessible data base, or a URL for a call to an http server over local or wide-are networks, or any remote procedure call ( rpc ) that can utilize a remote information resource.
Other object properties, such as the outflow from a subcatchment or the monthly water requirements of an irrigation district, depend on numerous controlling variables or plans, decisions, and assumptions, that is they have their own context and possibly need to update their state if the context has changed. Models such as the RRM rain-runoff model or the irrigation water demand estimation model can be triggered by the respective objects (i.e., subcatchments, irrigation districts) to estimate such values as their attributes. They can in turn be fed to a subcatchment start node or an irrigation demand node in the river network, and provide input the corresponding simulation models. Alternatively, the context can be defined by a model specific scenario (including, for example, the selection of a specific year or period and its hydrometeorological characteristics), and, within this constraint, by a set of user specified assumptions.