The recent rise in the use of the Internet and web browsers has prompted a shift in the way computing, and consequently hydrologic modeling, is being done. Currently, there are a number of techniques that can be used for performing simple computer modeling on the Internet. Hypertext Markup Language (HTML) provides the foundation for web pages. Embedded into the HTML coding can be server-side Common Gateway Interface (CGI) script, client-side JavaScript, and Java object-oriented programming language. In addition, third-party software in the form of helper applications, Plug-Ins and ActiveX components, and server-side software can be used to enhance web page features. The main limitation of most of these techniques is the ability to write files to the client’s computer. Currently there exists only a few web sites primarily focused on Internet versions of pre-existing hydrologic models. Several examples show how Internet-based hydrologic modeling is still in its infancy. The Internet Watershed Educational Tool (InterWET) is an educational site that provides a multi-perspective approach to water resource modeling by using JavaScript representations of the GWLF model and Java geographic information systems (GIS). SWAT On Line delivers the SWAT model over the Internet using a combination of Java, JavaScript, and CGI scripting. Most other existing web pages containing hydrologic modeling are focused on only education and database management and retrieval. The USGS Water Resources web site provides both education and database access using mostly CGI scripts. The US-EPA’s Enviromapper for Watersheds contains server-side GIS access to environmental databases. These examples show just the beginning. To expand hydrologic modeling on the Internet, the different modeling techniques will need to be developed to allow for more data and computing intensive models.
Hydrologic modeling has changed as computer technologies have changed. First, mainframes were required to run simple computer models. Then, with the advent of personal computers (PCs), models were developed which could be run on individual computers. Now, the new technology gaining popularity is the Internet. The Internet poses new challenges, like file storage on a client or server computer, but also provides new techniques for hydrologic modelers. This chapter will focus on some of the most promising techniques for hydrologic modeling via the Internet. The main purpose of this chapter is to provide a general overview of these techniques within the context of hydrologic modeling. Each technique is defined and then compared and contrasted with other techniques. To display how these techniques have been used for hydrologic modeling, the end of this chapter contains brief summaries for four examples of existing applications of Internet-based hydrologic modeling. These examples demonstrate that Internet-based hydrologic modeling is still in its infancy and has great potential for further growth.
At the simplest level, the Internet resembles a large network or web of interconnected computers. Just like mainframes and PCs, the Internet can run programs to read, write, store, and delete files. What makes the Internet different than mainframes and PCs is that a user can do these file actions on other computers in the network. That is, a user or "client" can manipulate files from someone else’s computer or from a "server." Mainframes had a similar setup with terminals and a server, but the terminals usually did not perform any computation; they just provided an interface to mainframe programs. PCs allowed running programs and file manipulation, but only on the client's computer.
PCs have been connected together (Intranets) for many years. Two main things make an Intranet different than the Internet. First, the Internet makes use of URLs (Universal Resource Locators) to give servers an unique numeric and text "address." Intranet addresses usually are not universally unique. Second, the Internet is meant to connect PCs worldwide, while Intranets connect PCs only within a given company or organization. While all servers have access restrictions for different clients, Intranets are designed for only a select group of clients.
As the Internet has grown, many different client-side programs have been developed to perform different tasks. The first of these were text-based terminal or telnet programs, which function like the terminals for mainframes, allowing clients to run programs through command line input. Usually coupled with these programs were FTP (file transfer protocol) programs, which use special server-based commands to allow file manipulation with uploading and downloading of files from the client to the server. Also there were gopher programs, which provided display of text information, simple graphics, and directories of files. In addition to the tools for file manipulation and display, there were developed a number of client-side communication tools. Electronic mail or email, a form of FTP program, sent text and attached files between clients through a server. Very similar to email were newsgroups, where the server stores a message or various files, and subscribers to the newsgroup can access the files. A faster version of this was the chat program, where clients send single lines of text to a server which displays the text to all other clients connected to the chat, i.e. a text teleconference. Most of these tools have been available in some form since 1990 and are still being widely used.
The use and understanding of these different programs can be challenging to the Internet user. Each program uses different protocols and methods to transfer information. During the early 1990s, a new type of client-side program emerged, the Web Browser, which combined the tasks of many of these prior programs and provided new features. Web browsers are designed to read the different protocols from the various programs described previously. They can also read files formatted using HTML (Hypertext Markup Language) and display a web page or site containing text, graphics, sound, other programs, and links to other sites. When a web browser opens a file at a particular location, the URL contains the protocol type (like http for hypertext transfer protocol) and unique name for the location of the file. None of the other client-based programs provide as seamless an interface to so much of the Internet as web browsers. The two most popular web browsers are Netscape Navigator and Microsoft Internet Explorer. While web browsers have been very successful, certain client-based programs like email, newsgroups, and chat programs require slightly different features than those provided by web browser programs. As a result, most web browsers come with separate programs for web browsing, email, chat, and newsgroups that are contained with a single interface. For many Internet users, Navigator or Internet Explorer are synonymous with the entire Internet system, since they contain within a single interface all of the tools needed for browsing, chatting, and using email and newsgroups.
What this means for hydrologic modeling on the Internet is that most models should be built for use with web browsers and/or be made accessible through a web site. The challenge in the next few years for hydrologic modelers will be to determine if their pre-existing or new models should be designed for the World Wide Web (WWW), considering the available modeling techniques and the costs of model development and server maintenance. While this chapter does cover the costs of web-based modeling versus conventional modeling, it will give guidance on available modeling techniques. The following section will detail some of the most promising techniques available for web-based hydrologic modeling.
3.4.1. Hypertext Markup Language (HTML)
One of the simplest techniques for applying hydrologic models to the Internet is through the capabilities of HTML. Vander Veer (1997) states, "HTML is a character-based method for describing and displaying Web page content." It is not a programming language, but a formatting method. To change the size, font, or color of some text, one surrounds the text with tags. A browser uses these formatting tags to change the display of the text when a file with HTML is read. Tags can cause text to act as a link to another web page or can be used to add multimedia elements, such as pictures or sound, to a web page. Scripts and programs (to be covered later) are also added to a web page using the appropriate tags.
Used independently from other techniques, HTML provides ways to organize and display information and to access sites with downloadable models. HTML does not provide calculation methods for models, but can be used to structure information in ways that are helpful to model users. For example, there are numerous web sites that use HTML to provide sample data sets, online help, and downloadable executable files for different hydrologic models. While HTML does not actually perform the modeling, the web site for a model can arrange the information to best address the users' needs. Use of HTML provides hydrologic models with constantly updated online documentation and globally accessible distribution.
HTML also provides the foundation on which to build all other web site features. These features can be added through the use of CGI (common gateway interface) scripts, JavaScript, Java, and third-party software. Each of these three techniques has characteristics which make them unique from each other and better suited to address certain modeling needs.
3.4.2. CGI (Common Gateway Interface) Script
By using server-side scripts, CGI scripts allow a web page to be dynamic (Wooldridge and Morgan, 1997). A scripting language, as opposed to a programming language, is interpreted, not compiled. When a script is called, an interpreter goes line by line through the script and executes the code immediately. This is different than a programming language, where the code is initially compiled into an executable file and this file is later run to perform some action (Wooldridge and Morgan, 1997). Usually scripting languages are easier to use than programming languages, because they contain fewer features than programming languages (Vander Veer, 1997). Most CGI scripts are written in Perl, a scripting language with interpreters for all server platforms.
By being server-side and dynamic, CGI scripts have several capabilities that HTML does not. First and foremost, CGI can produce new web pages based on interactive user input. For instance, most web pages where a client fills out an online form use CGI. The HTML tag for the submit button contains the URL for the CGI script. When the client clicks a "submit button", the server-side script is sent the form data. The script processes the data and sends back a new web page to the client. This new web page may just be a pre-existing HTML file confirming that the form data was sent or a newly created HTML file based on the form data. CGI scripting has the ability to write new files to a server (Cornell and Horstmann, 1996).
However, the utility of CGI comes at a price. Because it is server-side, CGI scripting has issues with development, platform compatibility, data storage, and security. Server administrators often store CGI script in a special location in a server, usually a directory named cgi-bin. The security structure of this directory is specially developed to allow the script to read and write files. To test a script, a developer must have the proper interpreter for the scripting language and platform (UNIX, Windows, Macintosh). In addition, the developer must have access to the cgi-bin directory to debug CGI scripts and will need to understand the data exchange protocol between HTML and servers. Depending on the purpose of the CGI script, the developer will need to carefully create scripts that do not threaten server security or available memory storage. For example, if the CGI script writes a number of files to the server every time the script is run, the developer will need to make sure the server has enough space to handle the load and some mechanism to delete specific files.
Another issue is server speed. Since the script must be interpreted each time it is run, a lengthy, complicated script may take considerable time to run. Other time lags are added by the client's Internet connection speed, number of users on the server, server processor speed, and transmission delays caused by general Internet traffic. As a result, the client may have to wait a long time to obtain results from a CGI script.
For certain applications, like submitting form data, CGI scripts work well. However, other techniques have been developed which attempt to overcome some of the shortcomings of CGI scripts.
JavaScript is a client-side scripting language specifically developed to extend HTML (Vander Veer, 1997). Like CGI scripting, JavaScript is interpreted, not compiled. However, the interpreter for JavaScript is a web browser, not a special interpreter for the given scripting language and platform. JavaScript works within the web browser to give advanced features to HTML and more control over browser characteristics. While HTML can change the size and color of text of a web page, JavaScript can change the browser window size or the display of browser tool bars. JavaScript can respond to user input from the keyboard or mouse to perform some action and allows more advanced interfaces like drop-down lists or "radio" buttons (Vander Veer, 1997).
JavaScript works by being embedded into an HTML file using a special tag. When the file is loaded into a web browser, the JavaScript interpreter in the browser goes line by line through the JavaScript code. This allows dynamic elements to be embedded into a web page. Instead of sending a brand new web page in response to client input (like CGI scripts,) JavaScript can maintain portions of the web page, while changing other portions to respond to input (Wooldridge and Morgan, 1997).
Being client-side, instead of server-side, gives JavaScript certain advantages over CGI scripting. Data storage and security issues of CGI scripting are overcome, because JavaScript can not write files to the server and does all interpretation on the client’s computer. An HTML file with JavaScript is stored like other web pages on a server and copied to the client's memory cache when loaded by the browser. The server does not need to create new files or find space to store them. Only a web browser is needed to interpret JavaScript, so that web pages with JavaScript can be tested and developed with less trouble than CGI scripts. The speed for JavaScripts is also faster, since new files are not being created and all calculations are being done on the client's computer (Wooldridge and Morgan, 1997).
JavaScript, despite its advantages over CGI scripting, still has several shortcomings. While being client-side gives JavaScript distinct advantages, its inability to write files to the server is a major drawback for hydrologic modeling. Traditionally, hydrologic models have been based around file creation. An input file is created for a model, the model runs and creates an output file. While JavaScript does allow files to be saved to the client's computer, these files are only copies of the HTML code, graphics, or text on the web page display. Because of the security restriction posed by being client-side, JavaScript does not have the file input/output routines that are commonly used to save data (Wooldridge and Morgan, 1997).
Another concern for developing applications with JavaScript is the programming language itself. JavaScript is an object-based language that uses built-in and user-defined objects. This is different than procedural languages, like FORTRAN, which perform instructions in sequential order. Object-based languages are also slightly different than object-oriented languages, like C++, because object-based languages do not support inheritance. Inheritance is the ability to create a new object that inherits the characteristic of existing objects (Vander Veer, 1997). In addition, JavaScript is not completely standardized. According to Wooldridge and Morgan (1997), JavaScript was originally written for use with Netscape Navigator, while Microsoft created a JavaScript clone called JScript for Internet Explorer. While Microsoft claimed that JScript was 100% compatible with JavaScript, Wooldridge and Morgan (1997) cite numerous examples of incompatibility, mostly based around the interactions between the script and web browser page elements.
Despite these shortcomings, JavaScript probably provides the best balance of learning difficulty with advanced features for beginning web programmers. In an attempt to go beyond the capabilities of JavaScript, the Java programming language was developed.
Java and JavaScript are two separate and different languages. Java is a platform independent, object-oriented programming language. Being platform independent makes Java code the same for UNIX, Windows, and Macintoshes. Java code, like other programming languages, can be compiled into computer programs. However, Java code can also be converted into applets which can be run on a web page. Cornell and Horstmann (1996) describe how Java code is converted into class files, which are used to run a program through a web page applet. This conversion to class files is much more complex than a web browser just interpreting JavaScript.
Java applets can be used in a web browser that is Java enabled. Using the proper HTML tag, an applet can be embedded into a web page, usually within a window or in a separate frame. The applet acts like an independent program within the web page. Therefore, Java applets can do many things, like dynamic graphics, that JavaScript cannot. Java, however, cannot alter web browser characteristics like JavaScript, since an applet's scope is limited to the window or frame in which it is running.
One big advantage of Java over JavaScript is the ability to access files. Java can read files from a server or a client computer. Java can also be used to write CGI scripts, so files can be written to the server. Still, Java applets currently can not write files to a client's computer. Cornell and Horstmann (1996) indicate this restriction is not an inherent part of Java and may be removed for future versions.
The file input/output problem is indicative of the major shortcoming of Java: it is a very new programming language. Even more than JavaScript, Java is not standardized and its capabilities change significantly between different versions. Because of this, the software used to compile and debug Java is still very crude and difficult to use. Future versions of Java will also need to adjust to the increased use of third-party software, namely Netscape Plug-Ins and Microsoft ActiveX components, which add specific extended features to a web page. As a result, Java is a powerful technique for modeling on the Internet, although difficult to use or trust.
3.4.5. Third-Party Software: Helper Application, Plug-In and ActiveX, and Server-Side Software
When web browsers were first being constructed, their developers realized that users might often want to extend the browser's features beyond what is easily available through HTML (Wooldridge and Morgan, 1997). One very simple way to do this is through the use of helper applications. If the browser is asked to load a file in a format it is not designed to handle, it can prompt the client to load the file using an existing software program on the client's computer. The browser can store the association between this format and the helper application, so the next time this file format is loaded, the application will automatically start. Helper applications can allow file input and output to the client's computer, while CGI scripting, JavaScript, and Java can not currently accomplish these tasks.
Any existing program on the client’s computer can act as a helper application. While this can greatly extend the ability of a web browser to deal with files, there are several major shortcomings (Wooldridge and Morgan, 1997). First, the client must wait while the new program loads. If the program is memory intensive, there may not be enough memory to allow operation of both the browser and the program. Second, the program has no interaction with the web page, so that the program acts independently of the browser. The client must leave the web browser interface to use the helper application. Third, the client must have the proper version of the helper application software for his or her computer platform (Wooldridge and Morgan, 1996). The web browser acts as an FTP program for the client and the file is copied from the server to the client.
To overcome these shortcomings, web browser developers have created components that can be embedded into a web page. Specifically, Netscape calls their components Plug-Ins and Microsoft calls theirs ActiveX. Both Plug-Ins and ActiveX components are platform specific programs that work with the web browser to add some new features to a web page, such as the ability to play a sound file or show a movie clip. Usually these components are very feature specific, making them smaller than helper applications, but also more limited. Like a helper application, Plug-Ins and ActiveX components are loaded on the client's computer and called when a certain file format is requested on a web page. Since these components work within a web page, they can begin to run as a file is being loaded, instead of waiting for the file to be entirely copied to the client (Wooldridge and Morgan, 1996). Both Plug-Ins and ActiveX are added to web pages using specific HTML tags and can communicate with JavaScript and Java components in the web pages (Vander Veer, 1997).
However, there are some serious drawbacks for Plug-Ins and ActiveX. Plug-Ins and ActiveX components are very browser dependent. Vander Veer (1997) indicates that Microsoft planned to have Internet Explorer compatible for Plug-Ins and Wooldridge and Morgan (1996) said that Netscape Navigator would support ActiveX. In fact, the compatibility varies from totally incompatible to highly compatible depending on the version of Navigator Netscape and Internet Explorer. For example, older versions of Netscape can not use any ActiveX components, while newer versions of Internet Explorer can only use older Plug-In components. Adding to this problem is the platform dependence of Plug-Ins and ActiveX components, and the need to continuously update components for certain file formats. What often happens is that a client must continually update their Plug-Ins and ActiveX components until they find that their browser is too old to support the newest component. Ultimately, they have to obtain a newer browser version and start the cycle over again. This is especially true for new technologies such as streaming sound files or video files over the Internet, where file formats are continually expanded and changed.
Other significant drawbacks for Plug-Ins and ActiveX components relate to programming and development. Each component must be created for a specific platform and written in a programming language that can be compiled into the proper format for a Plug-In or ActiveX (Wooldridge and Morgan, 1996). Of the techniques listed so far in this chapter, Plug-In or ActiveX components are by far the most difficult to program. However, these components also provide some way for file input and output to the client's computer through the web page.
Server-side software provides a server-based alternative to Plug-Ins and ActiveX. This very specialized software is designed to be run on a server and deliver specific features to a web site. Server-side software can run server programs and perform file input and output to the server. Because the software must account for the server and client, run programs, and manage files, developing new server-side software is even more difficult than designing new Plug-In or ActiveX software. Most applications which use server-side software purchase pre-existing server-side software for a specific feature, such as geographic information systems (GIS).
Another shortcoming of server-side software is the security and file management issue. Like CGI scripting, the designer of server-side software must account for file input, output, and storage space for these files. This level of control over files requires the server to have less security in certain directories. In addition, server-side software may require several programs to be running simultaneously to produce a desired output file. If the server is being used by many clients, the computing load may cause a slow response to client requests.
Table 3.1 gives a summary of the features of HTML, CGI scripting, JavaScript, Java, helper applications, Plug-Ins and ActiveX, and server-side software. The table indicates whether each technique is client or server-based, uses interpreted or compiled languages, and whether it must be customized for specific platforms. In addition, Table 3.1 indicates the capability of each technique to read and write files to the client and server. The table also describes each technique’s level of standardization; whether the method and languages used by the technique are consistent among browser types, versions, and platforms. Finally, Table 3.1 lists the ease of using each technique to create new software. The table does not indicate the ease of using pre-existing software for a particular technique, because this facility can vary greatly among software packages.
Table 3.1 also summarizes the current status of each technique. New capabilities are continually being added. For instance, Wooldridge and Morgan (1997) discuss the use of JavaScript as a server-side scripting language, merging CGI scripting with JavaScript, or as a server-side programming language, where a JavaScript compiler is used to make JavaScript programs. While these new capabilities may be possible, in most cases they are not currently practical. The characteristics in Table 3.1 describe what currently is practical for use in hydrologic modeling over the Internet. Each of these techniques has distinct features, advantages and disadvantages over other techniques. The challenge for any given hydrologic modeling application is to decide which technique or combination of techniques can meet the modeling needs by balancing model features, budget constraints, server capability, and client needs. The next section will detail research methods and other examples of Internet-based hydrologic modeling.
3.5.1. Internet Watershed Educational Tool (InterWET)
The Internet Watershed Educational Tool (InterWET) was developed as part of a doctoral research fellowship from the U.S. Department of Education. InterWET is available through The Pennsylvania State University’s Agricultural and Biological Engineering Department’s home page at http://server.age.psu.edu/, under research in the natural resources and conservation area (Parson et al.,1999). InterWET was created to help educate local officials and concerned citizens about water resources, using the Spring Creek Watershed in central Pennsylvania as a case study (Parson, 1999).
InterWET consists of a set of web pages that present five water resource components from three different perspectives. The tool utilizes the "microworlds" concept, defined by Edwards (1995) as computer-based learning environments, "which embody mathematical and scientific concepts in a context which is engaging to the learner, and which allows for a certain degree of self-directed exploration or discovery of the implicit ideas and processes." InterWET was developed around fifteen different microworlds, where each microworld is a combination of one of five water resource components (runoff, groundwater, sediment, nutrient, fish) and one of three perspectives (researcher, conservationist, local official).
Each of the three perspectives was linked to a certain dimensionality. For a researcher like an agricultural engineer, the water resource components can often be seen as individual, two-dimensional processes. A process like runoff might be measured from a small field plot. This can be contrasted with the perspective of a conservationist from an organization like Trout Unlimited, who may be more concerned with the geographic, three-dimensional aspects of water resources. From this perspective, the amount and quality of runoff in watershed streams on a particular day is important. A local official might expand this idea to a temporal or four-dimensional perspective. An official may be concerned about not only the amount of stream flow on one particular day, but also how local policy choices made today may affect average stream flow 10 and 20 years from now. While researchers, conservationists, and local officials are concerned with all dimensions in a watershed, they are more likely to focus on information in the dimensions to which they are linked to in InterWET (Parson, 1999).
To construct these microworlds, InterWET used HTML, JavaScript, and Java. HTML was used to create the basic appearance of all web pages, text and images on each page, and navigational links between pages. HTML code was also used for a navigational image map on InterWET’s home page, where users can click on the image thereby going directly to any web page at the site.
JavaScript was used intensively for display and calculation. Since InterWET is an educational site, there is no need for extensive file input and output. Each microworld was constructed to be a self-contained entity. To help reinforce this idea, each microworld loads into a new window (created by JavaScript), so the client could manipulate the microworld while going through the lesson on the web page. All microworlds for the researcher or processes perspective were JavaScript calculators, like the erosion calculator illustrated in Figure 3.1. This erosion calculator uses the Universal Soil Loss Equation (Wischmeier and Smith, 1978). The input is from text fields for numbers and radio buttons for different variables. Since InterWET’s audience of local planners might not be familiar with factors influencing erosion like slope length, some values were predefined and assigned to the radio buttons. Once all inputs are entered, the user clicks the Calculate Button and JavaScript calculates a value, which is displayed in a text field. Since input and output are both shown in a single interface, file storage is not needed. Parson (1999) gives details on the different methods used for each calculator.
Java was used for GIS display for the conservationist or geographic perspective. Specifically, ActiveMaps v2.0 was purchased from InternetGIS.com. ActiveMaps is a Java, client-side GIS program, giving low cost GIS features to InterWET. This avoided the high cost and upkeep of commercially available server-side GIS software. Figure 3.2 shows the Java ActiveMaps GIS for groundwater from the conservationist perspective. ActiveMaps uses database files, so features like queried data lookups are supported. The client does not have explicit file input or output capability, but the special format shapefiles and database files are copied to the disk cache for the browser.
The microworlds for the local official or temporal perspective use JavaScript to represent output from the Generalized Watershed Loading Functions (GWLF) model (Haith et al., 1992). The GWLF Model utilizes simple loading functions to predict monthly runoff, sediment, soluble nitrogen and phosphorous, and sediment nitrogen and phosphorous estimates. This approach uses look-up tables and artificial neural networks to replicate the predictions from GWLF. This makes calculation of estimates much faster than using only GWLF, making it better suited to the Internet. Parson (1999) provides details on using artificial neural networks for Internet-based hydrologic modeling.
Since the modeling is primarily educational and model input and output is handled through the user interface, InterWET is an example of a hydrologic model where the problem of file input and output is overcome. The next example will cover a more complex approach used to convert a pre-existing hydrologic model to the Internet.
The Soil and Water Assessment Tool (SWAT) is continuous, distributed parameter hydrologic model used to compare alternative best management practice decisions based on water quantity and quality levels (Arnold et al., 1994). SWAT On Line provides Internet-based interface to SWAT using databases from the Hydrologic Unit Modeling for the United States (HUMUS) Project (Wang et al., 1999). Developed by the Blackland Research Center of the Texas Agricultural Experiment Station, SWAT On Line uses a combination of client and server-side techniques for its three main modules; "Input", "Check Status/Project Management", and "Output."
The "Input Module", shown in Figure 3.3, allows users to develop an input file set extracted from the HUMUS Project databases (Wang et al., 1999). The HUMUS Project consisted of gathering landuse, soils, elevation, and climate data for making national and regional water assessments with SWAT. The main computer modeling components of HUMUS were the SWAT model, a GIS for spatial data, and database programs for managing the non-spatial data. The Input Module of SWAT On Line allows a user to access this information to create a SWAT input scenario. This is accomplished through the Java applet shown in Figure 3.3 that makes use of CGI scripting and Oracle database server-side software. Then, the user can run a server-side version of SWAT for their input scenario. All input and output files are created and stored on the server (Wang et al., 1999).
The "Check Status/Project Management Module" provides another Java applet interface where the user can check the progress of a current input scenario run through SWAT or previous runs. This module also allows the user to stop a run or to delete server-side input and output files (Wang et al., 1999).
The "Output Module" takes the output from a SWAT run and allows the user to produce a map, chart, or ASCII data file, which can be saved on the client side. The interface makes use of client-side JavaScript to provide input to Oracle’s Pro*C server-side database software. Users can enter various query statements through JavaScript and Pro*C will produce the desired client-side output (Wang et al., 1999).
SWAT On Line tackles the file input/output problem by providing an extensive input database which is made accessible through CGI scripting and server-side database software. While most of the output is stored on the server side, SWAT On Line does provide a way to save selected information to the client side. Because of data storage and security issues on the server-side, the current version of SWAT On Line requires users to register and create a free account on their server. For a purely hydrologic modeling example, SWAT On Line provides the current state-of-the-art. However, most web sites that deal with hydrology are primarily geared toward education or information and database management and retrieval, and use hydrologic modeling to support primary focus. The next example will show a web site that is primarily data retrieval.
3.5.3. USGS Water Resources Web Site
The U.S. Geological Survey (USGS) maintains a variety of web sites that address geologic topics. One of these web sites (USGS, 1999), deals with different USGS water programs. Main topic headings at the web site include news, features, water data, publications and products, technical resources, programs, and connections to state information. Each of these topics uses different sets of techniques to deliver information to users. All pages extensively use HTML and its capabilities of displaying text and graphics. For instance, under the technical resources topic is a link to hydrologic software. Clients can look for models under different topics like groundwater and surface water, look for information on specific models, and download the models. Specific information on each model is accessed through a call to a CGI script.
CGI scripting is the main technique that USGS (1999) uses to add additional features to web pages. For instance, under the water data heading are links to real-time water data. Imagemaps of the United States use CGI scripts to help a user zoom in to their specific location of interest and find specific water gauging stations. A different script then accesses the real-time data for the selected gauging station and produces graphs for information like streamflow, shown in Figure 3.4. These gauging stations send their information via satellite to the server, which delivers the information to the web page when called by the CGI script.
Hydrologic modeling underlies the information given at USGS (1999). For example, the real-time stream gages send stage data to the server. The server software must use the proper rating curve to model the stream flow. File input and output are simplified through the use of CGI scripts. Input usually comes by clicking a selection or entering a search string. Output is usually a web page with some special text or graphics. If the client wants to save the graphics, they can use the web browser to save the page and graphics. An organization like USGS has the staff and computer resources to manage the numerous files that all of these CGI scripts produce, so individual accounts, like those used by SWAT On Line, are not needed. The next and final example will discuss a primarily hydrologic database delivery site that utilizes server-side GIS.
3.5.4. Enviromapper for Watersheds
Enviromapper for Watersheds, at US-EPA (1999), is a web site that provides interactive GIS maps to EPA spatial data. As the client makes use of the zooming buttons to go from national maps, as shown in Figure 3.5, to state and county level maps, Enviromapper will display more detailed information. For example, at the county level, the client can display EPA database entries for water dischargers, Superfund sites, and toxic releases, in addition to streets, water bodies and streams, and ZIP code regions. The client can then click on a particular symbol to link to the data for that location.
HTML, CGI scripts, and JavaScript are the primary techniques used for Enviromapper. Making use of frames in HTML, the client display is split into different regions that show map graphics, selectable legend items, and a navigation toolbar. User input is handled by JavaScript, which then sends the input to a CGI script to produce a new map or to produce new frames where a user can access detailed information. The site developers made use of commercially available software from Environmental Systems Research Institute or ESRI (1999), namely MapObjects Internet Map Server. ESRI also has an Internet Map Server for ArcView, which utilizes Java for the browser interface and server-side software to deliver features.
Like the USGS Water Resources Site, Enviromapper is primarily an information and database delivery system and is supported by vast resources of the EPA. The GIS feature is used to make access to database information easier. The output from using Enviromapper is either maps or databases which can be saved through the existing features of the web browser. All of the maps and other information are stored and managed on servers capable of handling large client numbers. In addition, the site resources are continuously updated and monitored by agency staff.
These few examples show that hydrologic modeling on the Internet is at a very early stage. Whereas the existing techniques allow for complex user interfaces and information portrayal, the basic problems of file input and output to the client and intensive computation for model simulation still have not been practically addressed. Each example showed that hydrologic modeling on the Internet requires compromises between the client and server side. Highly detailed hydrologic modeling on the Internet will not be practical until new techniques and technology are developed to overcome data storage, speed, and security issues. While the use of Plug-Ins and ActiveX or server-side software techniques gives the most promise, these techniques currently are very difficult to learn and to use. Most of the current work with hydrologic modeling on the Internet involves either education or database retrieval and query. This is accomplished with a combination of HTML, CGI scripts, JavaScripts, and Java programming. As these techniques and their associated technologies advance, their features may advance to the point where more active, computational, and data intensive hydrologic modeling can take place on the Internet.
Arnold, J.G., J.R. Williams, R. Srinivasan, K.W. King, and R.H. Griggs. 1994. SWAT: Soil and Water Assessment Tool. Temple, Texas: USDS, ARS, Soil and Water Research Laboratory.
Cornell, G. and C.S. Horstmann. 1996. Core Java. Upper Saddle River, New Jersey: A Prentic Hall Title, SunSoft Press.
Edwards, L.D. 1995. The design and analysis of a mathematical microworld. Journal of Educational Computing Research 12(1): 77-94.
Environmental Systems Research Institute (ESRI). 1999. Environmental Systems Research Institute, Inc. Web Site. [On-line] Available: http://www.esri.com/.
Haith, D.A., R. Mandel, and R.S. Wu. 1992. GWLF: Generalized Watershed Loading Functions, Version 2.0, User’s Manual. Ithaca, New York: Department of Agricultural and Biological Engineering, Cornell University.
InternetGIS.com. 1998. ActiveMaps Version 2.0. Oakton, Virginia: InternetGIS.com.
Parson, S.C. 1999. Development of an Internet watershed educational tool (INTERWET) for the Spring Creek Watershed of central Pennsylvania. Doctoral dissertation. University Park, Pennsylvania: The Pennsylvania State University.
Parson, S.C., J.M. Hamlett, P.D. Robillard, P.A. Johnson, and M. Urquidi-MacDonald. 1999. The Internet Watershed Educational Tool (InterWET). [On-line] Available: http://server.age.psu.edu/.
US-EPA. 1999. Enviromapper for Watershed. [On-line] Available: http://maps.epa.gov:10000/iwimap/.
USGS. 1999. USGS-Water Resources of the United States. [On-line] Available: http://water.usgs.gov/.
Vander Veer, E.A. 1997. JavaScript for Dummies. 2nd Edition. Chicago, Illinois: IDG Books Worldwide, Inc.
Wang, H., J. Gollapalli, and R. Srinivasan. 1999. SWAT On Line. [On-line] Available: http://srph.brc.tamus.edu/humus/html/swatfirst.html.
Wischmeier, W.H. and D.D. Smith. 1978. Predicting Rainfall Erosion Losses - A Guide to Conservation Planning. USDA Handbook 537. Washington, D.C.: U.S. GPO.
Wooldridge, A. and M. Morgan. 1997. Special Edition: Using JavaScript,
Second Edition. Indianapolis, Indiana: Que Corporation.
TABLE 3.1. Summary of Techniques for Hydrologic Modeling
over the Internet
(after Cornell and Horstmann, 1996, Vander Veer, 1997, and Wooldridge
and Morgan, 1997.)
|
|
|
|
form Spe- cific |
|
|
ardiz- ation |
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
