Multi‐Scale Support for GIS and Groundwater Modeling

<Figure 3> Modified Data Model showing feedback to the spatial

database from the Field. Attributes (An) are separate entities managed by the database objects (On).

proximity to wells, can effect the resulting selection of elements. These higher‐level operations are not currently part of off‐the‐shelf GIS, but were built as extensions to commercial software. Although generalized line simplification is already implemented in ArcAEM, multicriteria refinement of this simplification is still in a development stage and will be based in regions of anomalously high or low error. An important aspect to these simplification algorithms is that they are fully automated. By simplifying objects rather than the raster, resolution variation is repeatable by different users and can be related in the database to resulting field calculations. In this multi‐criteria line‐generalization scheme, attributes such as segment length that would be affected by the geometric simplification can be maintained as an attribute of the feature rather than a value calculated by the AEM software.

<Figure 4> Generalization of digital line graph (DLG) of hydrology (a) to analytic elements (b) which were used to compute the ground‐water potential field (c).

After simplification of the line elements, surface water stage information was extracted at each line‐segment junction from a georeferenced 30 m digital elevation model. This stage was communicated to the AEM code as a constant head boundary or, in AEM parlance, a constant‐head line element (Haitjema, 1995). Changes in hydraulic conductivity were estimated from existing geologic maps. An existing hard‐copy surficial geology map was digitized and georegistered to the GIS database. Surficial geology was manually interpreted to polygons that represented regions of varying hydraulic conductivity (K in Equation 2). In AEM parlance, changes in hydraulic conductivity are represented as equations referred to as conductivity “heterogeneities”. AEM heterogeneities were simplified from the hydraulic conductivity polygons through a scheme similar to the line‐simplification scheme noted above (Figure 4). With the hydraulic conductivity and hydraulic head boundaries thus

4a 4b 4c

represented, the ground‐water potential field was calculated. As one of the important parameters for aquifer protection is depth to water table, the ground‐water potential was calculated at the center of each digital elevation model pixel, and subtracted from the surface elevation. The depth‐to‐water‐table map was produced is shown in Figure 5 (Fredrick et al., 2004).

<Figure 5> Analytic element representation of the Ischua Creek Watershed (5a) and the resulting depth ‐to‐water‐table map (5b).

The hydraulic conductivities corresponding to each of the AEM heterogeneities displayed in Figure 5a were not known prior to creation of the model. Only rough estimates were available from well yield and literature values for similar sediments. In practice, however, even when point measurements are available, regional‐scale hydraulic conductivity is usually derived from ground‐water flow models. In this example, hydraulic conductivity of each of the elements was manually varied until the measured potential matched water levels observed in wells distributed throughout the watershed. Computation of the potential field implies fluxes from the streams (line elements) in the modeling domain. As is the case in all available GIS ground‐water interfaces, the calibrated hydraulic conductivity values, the measured fluxes to the streams, and errors between measured and calculated potential were not returned to the database. Consequently, we cannot query the database to separate gaining and losing streams, find the most conductive sediments, or to determine where the

5b 5a

model error was greatest. Nor can we relate this information to the particular water table map shown in Figure 5a. In the course of this study, many realizations of the potential were generated based upon different assumptions about geology and confidence in available hydraulic data. The parameters that led to the water table were lost to the database after the field was generated.

If the model parameters had been returned to the database, each water table realization could have been referenced to object in the model using a unique identifier. For example, if the water table in Figure 4a was designated WT10, then the input parameters such as stream stage and conductivity, as well as calculated values such as stream flux, could be referenced by this unique identifier. Referencing becomes more complicated, however, when objects are created, destroyed, or moved. In this case, multiple versions of objects must be referenced to the computed field. Since each each field is associated to its objects through the model that created it (figure 2) it will be necessary to retain objects in the database even when they are no longer needed.

These versioning issues are often dealt with by temporal databases (Elmasri and Navathe, 2000), but with a slight advantage since time is a 1‐dimensional ordered attribute. We can always answer the question of which version came after another and therefore is most current. Values derived from analyses are not necessarily ordered by time; more valid (more reliable) versions may occur at any time.

There are several approaches to creating multiple version databases. The first is to simply maintain multiple copies of the entire database whenever significant changes are made.

However this creates significant consistency challenges since there are multiple copies of objects that have not changed. A second approach would record a transaction log in which changes to objects are recorded, it the same way a transaction log is used in some database management systems to support data integrity and prevent data loss in the event of a system failure. For analyses that required testing of several different hypotheses there would be a significant overhead to reconstructing to the database to any given version.

Our approach will maintain separate versions of attributes for each object and maintain the versions through methods associated with each class of object. Each attribute will also carry information about its origin as a measurement, estimate, or calculation from a model.

As shown in Figure 6, this approach will extend the object model shown in Figure 2 by having attributes be a separate database object that is related to a spatial object and a specific source. When a model is being created the user decides how to deal with multiple attribute value versions. In some applications it would be acceptable to take the mean of all

the measurements, but ignore the estimates and calculated values. In other cases, where measured values are unavailable, the calculated values might be chosen over those estimated from the literature.