The button to call the select by range function described in example two can be seen in the bottom framset.
Over the past ten years, geographic information systems (GIS) have become standard research tools in archaeology (Allen et al. 1990; Aldenderfer and Maschner 1996). Despite the ubiquity of their use there are surprisingly few departments of anthropology in the United States where GIS has been carefully and creatively integrated into undergraduate curriculum. Some departments offer a general overview of GIS applications in archaeology, but send their students off to geography, landscape architecture, or some other department outside of anthropology for technical training. This approach achieves the goal of training but it does not provide students with the most relevant technical training to the spatial modeling demands of archaeology (Lake et al 1998; Ruggles and Church 1996; Kvamme 1995). Spatial models of archaeological settlement data employ unique suites of algorithms and transformations that may not be encountered in many technical courses from other departments. Archaeology students, then, not only require technical training in the use of GIS, but they also need training specific to the kinds of problems archaeologists are likely to encounter.
Access to appropriate software, hardware, and lab materials are a problem for many anthropology departments who want to provide GIS curriculum to archaeology students. Most anthropology departments that offer GIS courses do not have sufficient numbers of workstations to meet student demand. Instructors in these cases must often limit the kinds of examples they can use in class. Given the costs of GIS technology it is unlikely that many smaller colleges and universities will ever develop the fiscal resources necessary to develop computer labs fully equipped for spatial data processing by entire classrooms of users.
The World Wide Web (WWW) is a potential solution to GIS access problems. With the development of fully interactive user interfaces students may soon need only their own personal computer and an Internet connection to explore GIS concepts. In addition to reducing costs for smaller institutions, web delivery of GIS is also advantageous because it fits well with the development of the distance learning philosophy. Analytically functional web delivered GIS could take advantage of interactive data exploration, a component of distance learning philosophy.
Using a book metaphor for the WWW misses the potential advantages to a distance learning approach by not exploiting the dynamic capabilities of the web. Our course is designed around the belief that exploring of data in a problem-solving context is an effective approach to learning course material. Using real archaeological data to solve a research question in a laboratory setting can be more effective at imparting a concept or method to students than assigning reading material that covering the same ideas. This approach to learning is not unique, it lies behind many laboratory exercises. What is unique is that the development of web delivery technologies for GIS could make the application of this "hands on" kind of approach to teaching a more practical reality for anthropology departments.
Using the web as a GIS delivery medium permits inclusion of problem solving assignments without being tied to a specific computer lab. However, presenting content this way means that there is potential variability in client operating systems and browsers. Esri offers a variety of GIS web delivery options each with its own strengths and weaknesses. The three options we considered using for this project were: MapExplorer, creating our own application with MapObjects, or using the MapCafé Java applet in conjunction with Arcview's Internet Map Server (IMS) extension. MapObjects permits the flexibility to construct user interfaces that can perform analytical functions. However, we would have been required to develop unique versions for each of the major operating systems. Given the limited project budget the MapObjects approach was not pursued. MapExplorer showed significant potential for course development purposes, but it was only available for the Windows operating system. Esri's MapCafé Java applet used in conjunction with the ArcView Internet Map Server (IMS) extension appeared to be the best solution to our interest in designing platform independent delivery of course lab assignments.
While MapCafé is a solution to web delivery that is free to end users, the applet's out-of-box analytical functionality fell short of our instructional needs. For pedagogical reasons, analysis and theory testing through model building were focal points for the course we want to develop. We wanted access to many of ArcView's functions, in particular GRID surface and distance functions. Transformation, overlay and comparison between raster coverages (DeMers 1997: 350; Clarke 1995: 249) is basic to many kinds of GIS landscape modeling used in archaeology (Lake et al. 1998; Fisher 1997; Maschner 1996; Charmichael 1990). The project is still evolving, but we have solved some basic problems associated with developing analytically interactive web based GIS. The remaining sections of this paper address how we solved some of these problems through two examples. Example 1 is a dynamic HTML TOC. Example 2 shows a function that permits selection of raster elements from a GRID theme based on user inputs. We will define the roles that HTML, JavaScript, Java, and Avenue play in building interconnectivity between HTML, MapCafé, and ArcView.
Code written in languages such as Java, HTML, and JavaScript are intended to function the same way independent of the users platform. However, truly platform independent code is rare. Interpretation of code statements is dependent on the computer's operating system. What code results in depends on the language interpreter and its potentially different versions on different operating systems. A drop-down list in the MacOS, for instance, does not look or behave the same as it does in Windows or Unix. Netscape's browser for Windows allows a button's text to be changed at any time using JavaScript, however, the same command sent to Netscape's MacOS browser has no effect. Internet programmers who test their work in multiple operating systems know that each platform implements supposedly independent statements in different ways. While Java, HTML, and JavaScript are not yet completely platform independent, they do permit the construction of somewhat platform inspecific code statements.
The MapCafé Java applet is based on the client-server paradigm. A client requests a map and the server processes this request and responds. MapCafé is a request builder and a response displayer. Using the browser as a language interpreter and Java as the programming language, the PICS for display and input can be delivered with a single file or set of files to any platform. As a user interacts with the applet in a browser window, it interprets user actions and sends an appropriate request to the server. When the server responds, the response is interpreted by the applet and displayed in the browser window.
Again, MapCafé is a device for constructing and sending requests to the IMS and then managing the responses it receives from the IMS. The real power of the applet comes not from what it does, but rather what it allows. Since the Java files can be modified, the request and response routines can be changed to suit specific needs. Work can be done on both the client end and on the server end to capitalize on the ability to make a request and to get a response. Recognizing these relationships placed us in a better position to understand that the MapCafé and the IMS could be adapted to suit the demands of delivering archaeological GIS labs for archaeology over the WWW.
A multi-lingual approach was required to gain access to ArcView's analytical functions that were necessary for analytical lab assignments. Combining Avenue, HTML, Java, and JavaScript we constructed several generally useful new interactive functions. The roll each language plays in the development process is described below.
Avenue is ArcView's scripting language, and it allows ArcView users to create new routines for accomplishing any task supported within ArcView. Avenue is the language that is ultimately called upon by ArcView for performing tasks within the GIS. The IMS is an ArcView extension written in Avenue. All of the IMS scripts are editable Avenue code. Since all of ArcView's functionality is accessible via Avenue, the IMS scripts can call any available ArcView resource to process a request.
Multi-user access requires the IMS to be stateless, which logically means limiting access to some functions is necessary. However, all Avenue objects are available during request processing. This includes all of ArcView's basic functions and any extensions which are running, and any other ArcView resource in the serving project.
As described earlier Java statements were used in the construction of the MapCafé applet. MapCafé class files can be modified to create custom functions. MapCafé is the client side component that deals with user inputs and then displays certain kinds of output from ArcView communicated through the IMS. The kinds of requests that MapCafé builds and sends, though, do not have to be sent from MapCafé, they can be built using JavaScript and displayed using HTML. However, as an out-of-the-box solution, MapCafé provides a wheel that need not be reinvented but one that can be modified to suit specific needs. MapCafé, then, is the Java interface to the IMS connection to ArcView.
JavaScript at the code level is similar to Java. However, rather than manipulating objects in an applet, JavaScript is used to modify objects that are described within an HTML page. JavaScript can be used to build requests based on user input into HTML forms or user interaction within an HTML page. Within the context of a frameset, JavaScript can also be used to direct where requests are sent from. Since the server will always respond to the window that the request came from, JavaScript is useful for directing where requests are sent and received.
Hypertext Markup Language is a page description language. HTML is the set of PICS that are used to produce the user interface on the client's browser. It can be used to construct objects to input data or to hold the MapCafé applet. HTML is used to tell the browser where to put MapCafé and how big to make it. The browser is the containing application, and HTML is the language that describes what the browser will contain.
An http request looks like a normal URL. It begins with the URL of the .Esrimap file on the server (Esrimap.dll on Microsoft servers). It ends with a question mark followed by key value pairs separated by ampersands ( & ). The first key is 'name' or 'nameX' and the value is the unique portname given to the serving view by Arcview at serve-up. The second key is 'CMD' and its value is the name of the appropriate script to call. So a basic http request looks something like:
http://myserver.edu/.Esrimap?nameX=uniquePortName&CMD=ScriptToRunIn Arcview, the script called is actually AVINETMP.ScriptToRun. The AVINETMP.Dispatch script, that recieves all requests with the AVINETMP prefix, removes the AVINETMP portion of the script name. The AVINETMP prefix identifies the script as being part of the ArcView Internet Map Server extention. We created a script called AVINETMP.UserDispatch which accepts custom command requests as part of the http request.
The IMS�s AVINETMP.Dispatch script, in essence treats an AVINETMP prefixed script like a function, passing any remaining key/value pairs to the script. Take the following http request fragment:
0&CMD=UserDispatch&Size=700,0&SelectedTheme=Geology&Region=3AVINETMP.Dispatch recieves this request and knows to send the Size, SelectedTheme, and Region keys and values to the script called AVINETMP.UserDispatch. The UserDispatch script then creates a list of the key/value pairs. It uses a for-loop to traverse the list and uses if-then-else if statements to define actions to take for each potential key that can be encountered. The following code gives a general idea of how ArcView parses http commands.
Note: the following code may not compile properly if entered. It is for illustrative purposes only.
theXScale=nil
theYScale=nil
theXValue=10
theYValue=10
theKeyValuePairList = theDataPassedToThisScript.AsTokens('&')
for each key/Value in theKeyValuePairList
theKey=key/Value.AsTokens('=').get(0) 'get the stuff on the left of the equal sign
if(theKey='ScaleX') then
val=key/Value.AsTokens('=').get(1) 'get the stuff on the right of the equalsign
theXScale=val
elseif(theKey="ScaleY")then
val=key/Value.AsTokens('=').get(1) 'get the stuff on the right of the equalsign
theYScale=val
elseif(theKey="ChangeScale")then
[the val is nil because nothing is passed]
return ((theXScale*thetheXValue).AsString + " x " +(theYScale*theYValue).AsString)
`the string returned if theScaleX is 5 and theScaleY is 10 would be "50 x 100"
elseif(theKey="ChangeScaleXY")then
[the val is two numbers separated by a comma x,y
theXScale=val.AsTokens(",").get(0)
theYScale=val.AsTokens(",").get(1)
return ((theXScale*thetheXValue).AsString + " x " +(theYScale*theYValue).AsString)
`the string returned if the key/value pair in the http command is ChangeScaleXY=5,10 would be "50 x 100"
end
end
The ScaleX and ScaleY keys set the variables called theXScale and theYScale.
The ChangeScale key returns a formatted string using the information set
by the ScaleX and ScaleY keys. To use the ChangeScale key, the XScale
and YScale keys must appear before the ChangeScale key in an http request
being parsed by the above code. Thus the http command:
...&ScaleX=5&ScaleY=10&ChangeScale
would return the string "50x100" whereas the http command ...&ChangeScale&ScaleX=5&ScaleY=10
would return an error.
Using keys to set values is useful for creating
code that might be used in more than one key. In the above example, however,
the http request could be simplified by calling ChangeScaleXY key using
the http command ...&ChageScaleXY=5,10 which would also return
the string "50 x 100". In our scripts, information such as Size
and SelectedTheme are relevant to more than one key, so having a unique
key entry for both Size and SelectedTheme allows us to create re-usable
code. Generally, the modifications made to Avenue for the purposes of adapting
the IMS involves adding key/value entries to a Dispatch script.
Two examples follow showing how the connection to ArcView through the IMS can be optimized using HTML, JavaScript, Java, and Avenue working together. These examples were constructed around the PICS philosophy. By using HTML on the client end, and adding our own key/value pairs on the server end, we were able to enhance communication between the browser and the IMS to allow users access to more of ArcView's analytical capabilities.
During project development, we encountered a minor glitch in MapCafé applet's Table of Contents (TOC). On some platforms the TOC would not always show a scrollbar. Eventually, we decided to move the TOC outside the applet, putting it in its own frame in the HTML window (Figure1). Moving the TOC outside the applet solved the scrollbar problem and gave us increased control over the appearance and a functionality of the TOC. Since it would be written out in HTML, we could apply any text formatting that we wanted. More importantly, we could treat the theme display checkboxes for GRIDs as if they were radio buttons. Only one GRID theme in a view can be selected at a given time. Since each GRID completely covers or is completely covered by the other GRIDS in the project, redrawing any but the top most GRID is not efficient for the server. To accomplish the extraction of the TOC we had to work in all four languages. 1) The TOC has to be written out in HTML. 2) Mimicking radio-button functionality required JavaScript. 3) Causing MapCafé to request a map required modifying Java classes. 4) Avenue scripts had to be modified both to avoid drawing the MapCafé TOC and to implement a request for an HTML TOC. Thus, it is an excellent example of how different components can work together.
Figure 1: showing the dynamically constructed TOC in the left hand frameset that is described in Example 1.
The button to call the select by range function described in example two can be seen in the bottom framset.
The first step in moving the TOC out of the Java Applet was to disable the functions that create the normal TOC. To do so, we commented-out (place the comment character ` before a line of code so that it is not interpreted) each line of code that built the TOC. Specifically, we modified the AVINETMP.ServeMap script that builds the TOC when the map starts serving. Modifying the script from within our project meant that we were not modifying the original script, just a project specific copy. We did not want to disable the request for the TOC in the Java applet, because that would affect any project that uses the applet. Therefore, the Java applet functions normally, but the code it calls in our project simply ignores references to the TOC.
The next step was to add a new key to the UserDispatch script that would write back the HTML TOC. Requesting the TOC was chosen over manually creating an HTML file because we wanted the TOC to be dynamic. We wanted the TOC to reflect whatever changes were being made to the project as it grows, without having to open an HTML file to make necessary changes each time. Since it is being handled as a request, the TOC can be dynamically generated based on all the project's settings at serve-up. The following code is the key entry made into our dispatch script:
elseif(key="HTMLTOC") then
theViewName=val.lcase
theTable=av.FindDoc("ActiveProjects.dbf")
theVTab=theTable.GetVTab
theField=theVTab.FindField("View Name")
for each record in theVTab
if(theVTab.ReturnValueString(theField,record)=theViewName) then
theThemeString=theVTab.ReturnValueString(theVTab.FindField("ActiveThemes"),record)
theThemeTypeString=theThemeString
theThemeList=theThemeString.AsTokens(",")
theThmLstTemp=List.Make
theThemeString=theThemeTypeString
for each thm in theThemeList
theThemeInfo=thm.AsTokens("_")
if((theThemeInfo.get(1).UCASE="H").not and(theThemeInfo.get(2).UCASE="V") ) then
theThmLstTemp.add(theThemeInfo.get(0))
theThmTmp=theThemeString+theThemeInfo.get(0)+","
theThemeString=theThmTmp
end
end
theThmTmp=theThemeString.left(theThemeString.Count-1)
theThemeString=theThmTmp+"}"
theWebLink.WriteString("<HTML>"+CR)
theWebLink.WriteString("<HEAD>"+CR)
theWebLink.WriteString(" <SCRIPT>"+CR)
theWebLink.WriteString(" GThemes=new Array()"+CR)
theWebLink.WriteString("selectFlag=false;lastSelected=null"+CR)
theWebLink.WriteString("addend=null;ThemeString='';HThemeString=''"+CR)
theWebLink.WriteString(" functionradioClick(n)"+CR)
theWebLink.WriteString(" {ctr=0"+CR)
theWebLink.WriteString("for(ctr=0;ctr<GThemes.length;ctr++){"+CR)
theWebLink.WriteString("if(ctr==n)document.forms[0].elements[GThemes[ctr]].click"+CR)
theWebLink.WriteString(" else document.forms[0].elements[GThemes[ctr]].checked=false}"+CR)
theWebLink.WriteString(" clickHandler()"+CR)
theWebLink.WriteString(" }"+CR)
theWebLink.WriteString(" function clickHandler()"+CR)
theWebLink.WriteString("{setStrings();reconstructURL(addend)}"+CR)
theWebLink.WriteString(" function onLoadHandler()"+CR)
theWebLink.WriteString(" {"+CR)
theWebLink.WriteString("top.frames[1].document.applets[0].setThemeString(ThemeString,HThemeString)"+CR)
theWebLink.WriteString(" }"+CR)
theWebLink.WriteString(" function setStrings()"+CR)
theWebLink.WriteString(" {"+CR)
theWebLink.WriteString("ctr=0;ThemeString='';HThemeString=''"+CR)
theWebLink.WriteString("for(ctr=0;ctr<document.forms[0].elements.length;ctr++)"+CR)
theWebLink.WriteString(" {"+CR)
theWebLink.WriteString("if(document.forms[0].elements[ctr].checked)ThemeString+=document.forms[0].elements[ctr].name+','"+CR)
theWebLink.WriteString(" else HThemeString+=document.forms[0].elements[ctr].name+','"+CR)
theWebLink.WriteString(" }"+CR)
theWebLink.WriteString("ThemeString=ThemeString.substr(0,ThemeString.length-1)"+CR)
theWebLink.WriteString("HThemeString=HThemeString.substr(0,HThemeString.length-1)"+CR)
theWebLink.WriteString("onLoadHandler()"+CR)
theWebLink.WriteString(" }"+CR)
theWebLink.WriteString(" function reconstructURL(addendum)"+CR)
theWebLink.WriteString(" {addend=addendum;setStrings();"+CR)
theWebLink.WriteString("top.frames[1].document.applets[0].externalAPI(""Stop Enable true"");"+CR)
theWebLink.WriteString("top.frames[1].document.applets[0].externalAPI('Map reload')"+CR )
theWebLink.WriteString(" window.status='Retrieving Map'"+CR)
theWebLink.WriteString(" }"+CR)
theWebLink.WriteString(" </SCRIPT>")
theWebLink.WriteString("</HEAD>")
theWebLink.WriteString("<BODY OnLoad=""top.frames[1].location.replace('http://titicaca.ucsb.edu/HTML/SizeSpy.html?View=brac')""><FORM>"+CR)
_theHidString=""
_theVisString=""
theThemeList=theThemeTypeString.AsTokens(",")
GCounter=0
ECounter=0
GridFlag=false
for each thm in theThemeList
parsedThm=thm.AsTokens("_")
theThemeName=parsedThm.get(0)
theThemeType=parsedThm.get(1)
theThemeStat=parsedThm.get(2)
if(theThemeType.UCase="R") then
if(theThemeStat.UCase="V" and GridFlag.not) then
theCheckedValue="CHECKED"
if(_theVisString="") then _theVisString=theThemeName
else _theVisString=_theVisString+","+theThemeName
end
GridFlag=true
else
theCheckedValue=""
if(_theHidString="") then _theHidString=theThemeName
else _theHidString=_theHidString+","+theThemeName
end
end
theWebLink.WriteString("<SCRIPT>GThemes["+GCounter.AsString+"]="+ECounter.AsString+"</SCRIPT>"+CR)
if(theCheckedValue="CHECKED") then
theWebLink.WriteString("<SCRIPT>lastSelected=GThemes["+GCounter.AsString+"]</SCRIPT>"+CR)
end
theWebLink.WriteString("<INPUT Name='"+theThemeName+"'Type='Checkbox'"+theCheckedValue+"OnClick='radioClick("+GCounter.AsString+")'>"+theThemeName+"<BR>"+CR)
GCounter=GCounter+1
ECounter=ECounter+1
elseif(theThemeType.UCase="C") then
if(theThemeStat.Ucase="V")then
theCheckedValue="CHECKED"
if(_theVisString="") then _theVisString=theThemeName
else _theVisString=_theVisString+","+theThemeName
end
else
theCheckedValue=" "
if(_theHidString="") then _theHidString=theThemeName
else _theHidString=_theHidString+","+theThemeName
end
end
theWebLink.WriteString("<INPUT Name='"+theThemeName+"' TYPE='Checkbox'"+theCheckedValue+" OnClick='clickHandler()'>"+theThemeName+"<BR>"+CR)
ECounter=ECounter+1
end
end
theWebLink.WriteString("</FORM>"+CR)
theWebLink.WriteString("<SCRIPT>lastSelected=GThemes[0]</SCRIPT>"+CR)
theWebLink.WriteString("<LAYER WIDTH=100
HEIGHT=100 VISIBILITY='hidden'></LAYER></BODY></HTML>")
end
end
end
The portion of our AVINETMP.UserDispatch script provided above takes variables defined at serve-up and parses them to determine how to write the HTML. If the theme is visible and is a GRID, the INPUT tag is defined such that the OnClick JavaScript handler for the checkbox calls a JavaScript function that treats it like a radio button. Since, there is no static HTML file, the supporting JavaScript functions have to be written to the file also. When a GRID theme is selected, the OnClick handler passes its location in the GThemes array to a function called radioClick.
Since the contents of a view are determined at serve-up, there is no way for us to hard-wire the index number of the Grid themes into the JavaScript routines. To accommodate this, arrays are defined in JavaScript and after the INPUT tag for each GRID theme that is written out, an additional JavaScript statement within a SCRIPT tag is written. Two incremental counters are used in Avenue, one for maintaining the number of form elements written out, and one that maintains the number of those elements that are GRID themes. When the SCRIPT tag is written, the index specified for the GThemes array is whatever the counter setting is for the number of GRIDs written out, the value at that array index is set equal to the number of form elements written out. Thus, when the page is finally written out, there is an array that holds a list of the Grid theme indexes in the form's element object. When radioClick is called, it traverses the GTheme array and sets each form element in its list to unchecked, unless the GTheme index is the one the user clicked, in which case the function checks the box.
The GRID manipulation routines, though, are only a part of the code above. Included in the JavaScript are two variables ThemeString and HthemeString (for hidden theme string). In addition, the supporting function setStrings() is defined which looks at each form entry and if a theme is checked it adds it to ThemeString, otherwise it adds it to HThemeString. The last command in setStrings calls the onLoadHandler function (an outdated function that was not renamed) which then calls a public function we defined in the Applet (note: in our project the applet is in another frame) called setThemeString.
To invoke a change in MapCafé from our HTML TOC we had to add a public function. We modified the Launcher.class Java file that is the actual applet loaded on the page. We added a global variable and the setThemeString function to the class file. The setThemeString constructs a single string using the two theme strings passed to it, formatting the new string so that it is a fragment of an http request that looks something like:
&HThemes=theme1,theme2,...&Themes=theme0,theme3,theme4,...
This string is saved in the global variable we created. So, reloading the map takes into account changes made to the HTML TOC, we add our variable to the end of the function call to the IMS from Launcher.class for any requests sent to the sever. When the applet loads the first time, the global string is empty and whatever our settings are at serve up are reflected in the starting image. Since the HTML TOC is generated based on the serve-up settings they are in synchrony with the starting map. Communication between the TOC and the applet occur only when something changes in the TOC.
The code provided and the accompanying description are not intended to be a recipe for creating an HTML TOC. Rather, they are provided to illustrate the kind of interaction that is possible and the logic involved in making it possible. Although this example is rather simple and is not specifically geared toward accessing analytical functions, this programming described above makes it possible to cause an effect in MapCafé from HTML outside the applet. One can envision the construction of web based forms that could result in more analytically interesting effects in MapCafé. Example 2 illustrates the kind of effects that we are interested in constructing.
Our second example, Select by Region was developed as part of a predictive modeling exercise within a section about locational analysis. We wanted students to be able to construct a predictive model through locational analysis using multiple GRID themes (e.g. Charmichael 1990). Our example uses actual survey data from the Island of Braç. When MapCafé loads, it presents one half of the island of Braç with several themes including the location of Bronze Age mound sites for that half of the Island. Using MapCafé's default tools, students can get information about the various sites and associated thematic attributes. Students are also provided with links to the site data in both tab-delimited text and HTML formats if they choose to do statistical analysis of the attribute data as part of the model building process. To construct the prediction, grid theme attributes for known sites are examined. Based on observation of grid theme attributes among known sites, students were to select ranges of values for the grid themes to make predictions about where sites should be located from areas where site locations were not known. The exercise is not complete, but we discuss the SBR function here to illustrate progress made so far.
The overall routine for Select By Region is as follows:
Before we made the HTML version of SBR we created an ArcView dialog window version that functions much the way the HTML does. Thus, the HTML version is an attempt to mimic a dialog window that one might utilize in any windows based application. HTML and JavaScript are ideal for creating simple interactive dialog windows. Functionally, the only difference between the HTML version of the dialog window and the Avenue version is that the HTML version communicates to ArcView via http requests sent through the IMS.
The first step in the process was to create a dialog window. A JavaScript routine called from the onClickHandler of an HTML button in the MapCafé frameset spawns the window setting its size and general attributes. The window is opened with an HTML file that defines a three-frame frameset. The top frame is dedicated to obtaining a theme selection. The center frame is dedicated to inputting the desired range. The bottom frame holds the continue button. In addition to the frames, the frameset file describes JavaScript functions that direct where some requests come from as well as providing data validation prior to sending a request to the server.
When the dialogue window is loaded, the top frame sends a request to the server to send back a list of themes. To accommodate this request, a key/value entry was made in the UserDispatch script. Using the same kinds of variables used for constructing theme information in the TOC. The code for the key/value entry builds a drop down list of the available GRID themes for the requested theme (Figure 2). The items in the list are associated with the necessary request to send when a theme is selected in the list. All the information is created when the request is made to keep the process dynamic.
Figure2: showing the dynamically constructed dropdown list of GRID
themes in the serving view built from key/value pairs.
When a user selects an item in the list the onSelect handler calls a JavaScript function. This function reads the value and the label of the drop-down list's selected index. The value is the http request to send to obtain the appropriate entry form for the selected theme. Again, a key/value entry was made in the Dispatch script to accommodate this request. The entry form returned is determined by whether the theme contains continuous or nominal data (Stevens 1948). If the theme represents continuous data as in the case of Elevation, the entry form has a text field that displays the theme name and the available range of values (Figure 3). The entry form also has text fields for a from and to value so that the user may specify the range they are interested in selecting. If, the theme is nominal data, a drop-down list is constructed containing the available types (Figure 4). The information for nominal vs. continuous data is stored in global variables at serve-up in the AVINETMP.ServeMap script as is done with the variables used in the TOC. These global variables can be parsed by any subsequent call to the server by any script. When the page is written back to the client, a JavaScript call is included which sets a Boolean variable to indicate whether Range mode is on or off.
Figure3: showing the dynamically constructed text entry fields returned if
the chosen GRID theme contains continuous variables.
Figure4: showing the dynamically constructed text entry fields returned if
the chosen GRID theme contains nominal variables.
When the user clicks on the continue button, a JavaScript function is called. Here is where the Range mode is important. If the Range mode is on, then the function knows to look for the range form elements to validate the data. The string written into the first text field is used as a means of determining the allowed range as well as for displaying the possibilities to the user. The string will display something like: "Range for theme Elevation: 0-700." The JavaScript function then parses that string by splitting it first at the colon, at which point it ignores the text to the left. The text to the right is then split at the hyphen and the minimum and maximum values are then stored. With that information, the function can read the values entered by the user and make sure the values exist within the range allowed.
If the data is valid, or if a type is selected in the drop down list, the function constructs the http request string for the final image. However, before it sends the request, it spawns a new window to send the request from. Since we cannot know what the request will be before the users have entered their information, we cannot have a static HTML file to load into this window. So, using the document.write JavaScript command we write a basic HTML file into the window dynamically. The command looks something like the following:
For type data
Note that the http request is being sent from the SRC property of the IMG tag. We made the accidental discovery that if you set the response header to image/jpeg when writing back to the client, writing an image file back afterward results in sending the actual image data. So, after a few tests it was realized that we could send the request from the image tag directly. The traditional way to write an image back is to cache it to the server and then send the URL of the cached file back to the client. That creates clutter on the server and require an additional call to the server. Sending the request from the server allows us to temporarily create the file on the server, send back the image when it is ready, and delete the file from the server (Figure 5 and Figure 6). Thus, only one request need be sent to the sever reducing its workload.
Figure5: showing the results of the Select by Range function applied to
continuous data.
Figure6: showing the results of the Select by Range function applied to
nominal data.
The key/value entry for the Region request looks like this [text in braces indicates omitted code]:
The Size and SelectedTheme keys set the variable theTheme and sets width and height variables used to determine extents. The theme that is selected is not the theme in the serving view, but the theme in a second view of the project that has the same theme's name as the serving view. The second view holds the data associated with the other half of the island of Braç, therefore, it is the view we want to query. Since a query uses a bitmap to identify which pixels in a GRID to highlight, and since it overwrites that bitmap every time a request is made, the query can be made without worrying about whether the view is stateless. Additionally, the secondary view is never seen unless it is queried, so, the fact that it is still highlighted after request is moot.
The Range request is nearly identical to the Region request except that it has the variables theFromValue and theTwoValue determined by parsing the val variable associated with the Region key. Consequentially, theQuery changes to be the following:
theQuery = "([Value]>="+ theFromValue.AsString + ") and ([Value] <= "+ theToValue.AsString+")"
Select By Region is simply a query builder, much like the query builder in ArcView. Using HTML and JavaScript as a method for developing dialog window functionality, and making additions to the appropriate Avenue scripts, we were able to begin the process of accessing ArcView's analytical functionality through the WWW. The example falls short of our initial desire to build a locational analysis predictive model. However, it does demonstrate steps taken toward developing fully analytical web based GIS that can be used in an educational context.
Many of us share a vision of how GIS can be used as a teaching device (Tobler 1993). The WWW is a distributed publicly accessible file system with a promising future for classroom instruction of GIS in archaeology and the social sciences. Increasingly data access is becoming more open through the development of web based GIS applications like the ArcView IMS and the MapCafé applet. However, to fully capitalize on this vision and take advantage of its educational potential, developers must work to expand the range of analytical functions available to users. Clarke's (1995: 13) definition of GIS includes: