Untangling the net - Utility GIS / Internet technology
Kathy H. Spivey
Systems Analyst
Laura Mizula
Senior Consultant
PlanGraphics, Inc. 1597 Cole Boulevard,
Suite 300, Golden, Colorado 80401
Introduction
Over the past few years, the explosion of intemet technology and intemet-enabled applications
has changed the way information is distributed. Not unaffected by this information shockwave
was the GIS community, who recognized a niche they can fill by deploying dynamic maps and
related information on the Web. These dynamic maps are created by web-enabled GIS
applications which offer users the capability of interactively obtaining graphical data.
The purpose of this paper is to introduce the reader to the concept of web-enabled GIS and the
technology that supports GIS/intemet applications. Common utility-oriented GIS/intemet
applications are discussed. In addition, the planning and implementation process associated with
the deployment of such applications is reviewed.
GIS/Internet technology
Three GIS/intemet architectures are currently being deployed (ter Haar, 1997). Figure 1 presents
common configurations for each architecture.
The first GIS/intemet architecture is raster-based. A user client, whether browsing the internet or
an internal intranet, issues a mapping request (i.e., users asks for the map to be panned or
zoomed, or performs a query resulting in a new map). Alternatively, the user client can also use
the mouse to make a screen selection. The request or the location of the screen selection (in
screen pixel coordinates) is sent by the intemet server to the map server. The map server sends
the information to the map server application (which can reside either on the map server or on
another workstation). The map server application converts the pixel coordinates to real-world
coordinates if a screen selection was made and/or processes the query request, creates the
requested map, and converts the new map into a bitmap image. The image is then converted into
an HTML page and is downloaded to the intemet server which is then delivered to the user
client. Each request by the user client results in the generation of a new map, and thus a new
image.
The second GIS/intemet architecture that exists today is the vector-based approach. This
architecture is very similar to the raster-based approach, except for the data type being passed
back to the user client. Once again, the user client makes a map request through the intemet
server to the map server. The map server application processes the request and generates a
vector file (rather than a raster file, as in the previous approach), which can be linked back to
non-graphic data stored in a database and can be tagged as active features. In order to be able to
see the vector file, however, the user client must download a special plug-into enable the
browser to display the information. Each map request results in the generation of a new vector
file that is created and sent to the user client.
The third GIS/Intemet architecture being used is the vector-metafile approach. In this approach,
the plug-in plays a critical role in the viewing of the data. Map requests made by the user client
are sent through the intemet server to the map server in two steps: 1) the request triggers the
creation of a metafile sets up the mapping application environment (including information about
what information is to be loaded, where the information can be found, and how the information
must be displayed, and 2) the plug-in requests the data associated with the map. The map server
then returns to the user client only the raw data which is processed by the plug-in and displayed.
Once the mapping application environment is established, each user client map request prompts
the plug-in to request only the new data from the map server.
