Zhong-Ren Peng, Ph.D.
Assitant Professor
Department of Urban Planning
University of Wisconsin - Milwaukee
Milwaukee, WI 53201-0413
E-mail: zpeng@csd.uwm.edu

Abstract Internet has been changing the ways of data access, sharing and dissemination. It is further changing the means of analysis and visualization of Geographic Information Systems (GIS). Internet GIS is rapidly evolving as Internet and Web technologies change. Internet GIS is a network-centric GIS tool that uses Internet as a major means to access and transmit distributed data and analysis tool modules, and to conduct analysis and visualization. While many early Internet-based GIS services links World Wide Web and GIS server with the Common Gateway Interface, most recent Internet GIS focuses more on applications on the Web client side. The client-side Internet GIS using GIS plug-ins, ActiveX controls, and Java applets offers better interactions between the end users and GIS on the Internet. This paper discusses the working procedures of each technique, assesses their pros and cons, and addresses performance and security issues in the evolvement of Internet GIS.

The Internet is shaping the ways of traditional Geographic Information Systems (GIS) function. It is changing the access and transmission of GIS data, applications and visualizations. Internet has facilitated three major changes in GIS: (1) Access to data; (2) Transmission of data; and (3) Access to GIS analysis functionalities.

Internet provides a means for data access. It greatly improves the accessibility of data in general, and GIS data in particular. GIS data providers, including government agencies and private organizations, are discovering the convenience of publishing GIS data on the World Wide Web. GIS data warehouse and Clearinghouse are two common forms of Internet data access systems. Distributed search engines have facilitated the findings of GIS data among all sources of data providers (Peng and Nebert, 1997).

Internet is also a perfect means of GIS data transmission. The World Wide Web and FTP (file transfer protocol) programs make it convenient to transfer data files across the Internet. They provide GIS users easy access to acquire GIS data from different sources of data providers. GIS users can download data almost instantly from the Web over the Internet without the hassles of calling or writing around to find who has what data, making a formal request, and then waiting for days or weeks for the data disks to be arrived.

Furthermore, the new development of the Internet technology can enhance the accessibility and sharability of GIS analysis tools and functionalities over the Internet. Web browser is providing Internet users access to GIS applications software residing in Web servers. End users could work with GIS data interactively on the Web browser without owning GIS software on his/her local machine. Internet communications software such as Microsoft NetMeeting facilitates users to emulate a map server by sharing Windows-based GIS applications with others over the Internet (Matuschak, 1996).

The issue of GIS data access and transmission on the Internet has been addressed in the literature (Colman and McLaughlin, 1997; Peng and Nebert, 1997). The main task of data access and transmission is to provide access and deliver spatially-related information from many different sources to the widest possible group of potential users through network linkages. The national spatial data infrastructure is working toward that goal. The Alexandria Digital Library project, a centralized or indexed repository of spatial information, is beginning to structure and make searchable descriptive information, known as metadata, from diverse collections, and to make it available to the public (Frew, et al. 1995).

The National Geospatial Data Clearinghouse (NGDC) is another example of Internet data access. It is a distributed archive of information -- distributed among potentially multiple nodes within an organization, but accessible to all users through a single point-of-entry, managed by the Federal Geographic Data Committee (FGDC). It is an open federation of spatial data servers using the same vocabulary and supporting the same search protocol -- Z39.50 protocol (Peng and Nebert, 1997). The FGDC is assisting develop Clearinghouse nodes in the state, county and other non-federal sectors to form part of the NGDC in order to make the NGDC a more efficient data source.

Using Internet to access and transmit GIS data assumes that the user will use the data in his/her local machine with stand-alone GIS software installed. This is useful in the sense that it can facilitate the user to obtain the data more efficiently. However, the use of Internet in this manner is very limited. GIS users have to use the traditional GIS software to view and analyze the data. What if someone does not have GIS software installed in his local machine? What if a user only needs to view the data and maps on the Internet before he/she decides whether to download the data? How can we publish spatial data on the Internet and allow the user to perform some analysis without owning his/her own GIS software?

This is the third change being brought by the Internet, access to GIS analysis tools and functionalities. This change has emerged and is rapidly evolving, but it has not been adequately addressed in the literature. Access to and transfer GIS data over the Internet is a great but only the first step toward interoperability in the GIS community. The ability to access to GIS analysis functions over the Internet is the next and yet more important step.

This paper examines issues and emerging techniques in the evolvement of Internet–based GIS, or Internet GIS. It first discusses the definition of Internet GIS. It then reviews the procedures, pros and cons of four major techniques used in the Internet-based GIS: CGI (Common Gateway Interface)-based Internet GIS, GIS Plug-Ins, GIS ActiveX controls, and GIS Java applets. It further addresses Internet GIS related issues relating to performance and security and other issues.

Internet is a global network of computers connected through communication devices to one another. It is a means for GIS users to exchange GIS data, conduct GIS analysis and present GIS output. Therefore, Internet GIS is a special GIS tool that uses Internet as a means to access and transmit remote data, conduct analysis and make GIS presentation.

Internet GIS should have all or almost all functionalities the traditional GIS software have. In addition, Internet GIS should have additional functions that take advantage of the Internet and its associated protocols such as World Wide Web (WWW) and File Transfer Protocol (FTP). These additional functions include exchanging remote data and application programs, conducting GIS analysis on the Internet without owning GIS software on the local machine, and presenting interactive maps and data on the Internet. The key features of the Internet GIS are object-oriented, distributed and interoperable. Each GIS data and functionality is an object. These objects are resided on different servers on the Internet and are assembled and integrated when needed. These data and analysis functionalities can be exchanged or interoperable by any other systems on the Internet.

The concept of client/server involves splitting an application into tasks between the server and client. A client/server application has three components: a client, a server, and a network (Hall, 1994). Each of them is supported by specific software and hardware. The client sends a request to the server, which processes the request and returns the result to the client, the client then manipulates the data and/or results and presents to the user. The connections between the client and server are established according to a communication protocol such as a TCP/IP.

Internet GIS applies the client/server concept in performing GIS analysis tasks. It breaks down the task into server side and client side. The client can request for data, analysis tools or modules from the server. The server either performs the job itself and sends the results back to the client through the network, or sends the data and analysis tools to the client for use on the client side.

World Wide Web provides a natural interactivity to the Internet through its hypertext linkage. The user can browser the Web page by page through the hypertext linkage. However, each Web page is a static image that organized by the Web developer. Similarly, many map pages that was published on the Web are also static map images. Typically, static maps are portrayed at many sites to provide some geographic context to a site's information such as where the regional representatives of a company are located or where the major regional attractions are in a given state or county. Most of them are static image file like JPEG or gif (Graphics Interchange Format) file. The user cannot manipulate the map and perform even a simple analysis function such as zoom, pan and query on the map.

Internet GIS, on the other hand, enables users to manipulate GIS data and maps on the Internet interactively. Users can perform basic GIS functions such as zoom, pan, query, and labeling using Web browser. It can perform spatial queries like where is the closest restaurant and hotel is. It should be able to perform more advanced analyses such as spatial analysis and network analysis. Use Internet GIS on the Web should just like use desktop GIS software at the local machine.

One advantage of the Internet is that it can access distributed database and perform distributed processing (Hall, 1994). Information and applications can be resided on different computers cross the network. Internet GIS takes advantage of this distributed system so that the GIS data and analysis tools can be resided in different computers on the network.

GIS data and analysis tools are individual components or modules. Users can access those data and application programs on-demand from anywhere on the network. The user does not have to install the data and application programs in his/her local computer. Whenever it sends requests to the server, the server would deliver the data and analysis tool modules for just-in-time performance.

Because Internet GIS is a distributed system, database and application programs reside on computers that publish them. Those data and application programs are updated by those who manage them. Once the data and application programs are updated, they are available to every user on the Internet. In other words, Internet GIS is dynamically linked with the sources. The GIS is updated as soon as the sources are updated. This dynamic linkage with the sources always keeps the data and software current.

The Internet GIS can also link with real time information, such as satellite images, traffic movements and accident information by real time connection with the relevant information sources.

Internet GIS can be accessible cross platforms. It doesn’t matter what operating system the user is running. The Internet GIS is not limited to any one kind of machine or operate system. As long as one has access to the Internet, he/she can access and use Internet GIS, giving that the Internet GIS providers provide platform neutral or cross-platform GIS tools.

This is the direction of future Internet GIS. Access and share GIS data, functions and application programs among a group of GIS users in the heterogeneous environment needs high interoperability (Bishr, et al. 1996). The Open Geodata Interoperability Specification (OGIS) is attempting to lay the ground rules for GIS interoperability (http://www.ogis.org/). There are a series of issues needed to be resolved, such as standards for data formats, data exchange and data access, standard specification of GIS analysis components. But the fully interoperable Internet GIS becomes promising as the Internet standards and technologies rapidly improve.

With the help of the hypermedia system in the Web, Internet GIS can link different map pages through a hypermedia hot link. For example, one can browser a national map to the state map, to the city map by clicking on the hot link that links the national map to the state maps and further to the city maps (Peng and Nebert, 1997).

Furthermore, the World Wide Web provides Internet GIS a capability of integrating multimedia systems such as video, audio, maps, text, and broadcasting into the same Web page, which enriches the contents and the presentations of GIS.

In summary, Internet GIS is a special type of GIS tools that uses Internet as a major means to access and transmit distributed data and analysis tool modules, to conduct analysis and make GIS presentation. The end use does not necessarily need to have GIS data and software installed in his/her local computer, all data and analysis modules can be installed on the network servers that can be requested by and delivered to the end user on-demand. The GIS analysis tools are componentized or modularized objects that can be shipped to the Web browser just in time.

The Internet GIS has emerged and is rapidly evolving. At the current stage, there are two major Internet GIS applications: server-side applications and client-side applications. Server-side applications rely on GIS server (usually reside on a remote server) to perform all GIS analysis, while client-side applications perform GIS analysis and processing on the Web browser on the user’s local machine.

Server-side Internet GIS depends on the GIS server to perform analysis and generate output. The user at Web browser client initiates the request that is sent across the Internet to the server. The server processes the request and sent back the results to the user client. The server-side Internet GIS applications include the simple HTML to Common Gateway Interfaces (CGI) approach and application-sharing approach using Internet communications software such as Microsoft NetMeeting.

The initial development of linking GIS with Internet is by linking the GIS programs with the Internet server through a Common Gateway Interface (CGI). The GIS server runs on the background at the GIS server and is linked with the Web server. The Internet browser acts as a friendly user interface for the end user to request GIS data and service. The GIS performs the requested analysis and provides the graphics and text output to the Web server, which in turn presents the results to Internet users or clients. The CGI script handles the information exchange between the Web server and the GIS server. This approach is mainly for simple map display and does not facilitate much direct interaction between the Internet user and GIS analysis.

Web browsers and Web servers communicate by using the Hypertext Transfer Protocol (HTTP). Web browsers cannot directly communicate with GIS programs, which have to connect with Web servers. The linkage between GIS programs and Web servers is established by the Common Gateway Interface (CGI) or gateway script. The CGI script allows Web servers execute GIS programs and interpret their output information to Web browsers. The server and the CGI program work together to enhance and customize the World Wide Web’s capabilities to link with GIS data and functions.

How Do CGI-based Internet GIS Work?

CGI-Base Internet GIS is an extension of the HTML. It needs a GIS server running on the background. The GIS server is linked with the Web server via a CGI script as shown in Figure 1. Here is the simple version of how do CGI-based Internet GIS really work:

1. The Web user requests the document file by clicking on a Universal Resource Locator (URL) on a Web page.
2. The Web browser decodes the URL and contacts the Web server.
3. The Web server receives the request and translates the URL into a path and file name.
4. The server realizes that the URL points to a program (CGI) instead of a static file.
5. The server launches the CGI script and the script executes.
6. The CGI script calls the GIS server and translates the user input from the browser to a format or variable that the GIS server can recognize and use.
7. The GIS server performs the analysis based on the user’s request. Fore example, the GIS server may generate a thematic map and transfer the map into an image file (via other programs) such as JPEG and gif file.
8. The CGI script returns to the server the GIS output and information about the output, i.e., MIME (Multimedia Internet Mail Extension) type of the output.
9. The Web server receives the result from the CGI script and passes it to the browser.
10. The browser displays the output to the user.

In a nutshell, CGI scripts are called by the Web server based on the user requests from the browser. The scripts launch the GIS server and translate the request to a format or variables that GIS server can understand. GIS server then performs the analysis and sends the output back to the CGI script. The CGI script sends the output and the information about the output (e.g. MIME type) to the Web server and browser for display.

Advantages and Drawbacks of CGI-based Internet GIS

CGI-based Internet GIS focuses solely on the server-side operation. The GIS server does all the work, and the Web browser is a user-friendly front-end interface. The CGI scripts act as an intermediate translator between the browser client and the GIS server.

The advantage of the CGI-based Internet GIS is that all analyses are conducted by the GIS server. So the workload on the client side is small. It is a thin client. Since all work are conducted by the GIS server, the CGI-based Internet GIS can take advantage of the functionalities of existing GIS server software such as ArcInfo. The analysis tools and software developed in the last two decades can be fully utilized. Anybody who has Internet access can access and use the CGI-based Internet GIS, regardless of what operate systems and platforms are used.

The CGI-based Internet GIS, however, is also limited by the limitations inherent in the Web browser and its static HTML. First of all, CGI and the current HTTP are stateless. It means that an HTTP Web server doesn’t remember callers between requests. If a user requested a map and he/she wants to zoom in to the same map, the whole routine from browser to the Web server, to invoke CGI script, and to initialize GIS server has to be gone through again. Every single user inputs has to be sent to the GIS server via CGI script, and every result has to be interpreted by the CGI script and transmitted to the Web client. Therefore, it generates a lot of traffic on the Internet.

Secondly, because every operation has to be conducted by the GIS server, the information transmission between the Web browser user and the backend operation by the CGI script and GIS server is rather slow.

Third, since the CGI script handles all input from the Web browser and interpret all output for the GIS server, it becomes very difficult for the CGI script to handle a large amount of requests from users, especially those simultaneous requests. For any frequently used site, this incurs a considerable load on the server. The CGI script could become a failing point. That is, when the CGI script or the GIS server fails to work properly, the whole system will fail to function.

Finally, the final result of all the GIS server’s work is more static images. These static map images are passively displayed by the Web browser to the user. The user cannot interact with HTML documents other than by pressing hyperlinks. The limitations inherent in the HTML prohibit the direct manipulations of maps on the Web browser. For example, the user cannot drag a rectangular, a circle or an irregular polygon on a map image to select an area feature. The user cannot select a linear or a point feature on the map either.

There are many examples of CGI-based Internet GIS on the Web, such as VISA International's ATM (automated teller machines) locator (http://www.visa.com/), Yahoo Maps (http://www.proximus.com/yahoo/), MapQuest (http://www.mapquest.com/), and West Virginia Division of Environmental Protection (http://www.dep.state.wv.us/).

Another approach of server-side Internet GIS is to share GIS applications among a group of users. Microsoft has created a freeware software tool that supports collaboration of GIS users over the Internet, called Microsoft NetMeeting. NetMeeting consists of a suite of technologies that enable real-time, multiparty, multimedia communication over the Internet. The most important feature of NetMeeting for GIS users is its capability of sharing applications with many users over the Internet in an online meeting. "Sharing" an application means all participants can view and use the applications simultaneously with others. For instance, while one participant in a NetMeeting conference launches ArcView or MapInfo to work on a project, other participants in the conference can take control of the application and edit it while each of the others watch what is being done. Many people in conference can simultaneously work in the same application. However, only the participant who has initiated the GIS application can save or print files from that application (Matuschak, 1996). Application sharing using Internet communication software such as NetMeeting is not a true server-side application, because the GIS application can reside in any participant’s machine, not necessarily on the "server".

In addition to program sharing, NetMeeting includes features of Whiteboard, Chat, Clipboard and File Transfer. The Whiteboard feature allows online meeting participants to draw pictures and write text simultaneously and see what other people are drawing. The Chat feature allows online meeting participants to send typed messages to each other. The File Transfer feature allows the user to send a file to one or all the participants in a meeting. NetMeeting allows all the participants in a meeting to share a common Clipboard. When one person in a meeting copies data to the Clipboard, all participants can then paste the data into documents on their computer.

Client-side Internet GIS allows GIS analysis and data processing execute on the Web browser in the user’s local machine. GIS data and analysis tools initially reside in a server. Users usually request for data and process tools from the server, which sends the data and analysis modules to the client for local processing. Client-side applications include three major technical approaches: GIS plug-ins and helper programs, GIS ActiveX Controls, and GIS Java applets.

GIS plug-ins or helper programs are created to work inside the Internet Web browser such as Netscape and Internet Explorer to handle GIS data and maps. The GIS plug-in is downloaded from the Web server and operated in the front end at the user’s local machine. It acts as a helper application to handle GIS data type that the current HTML (HyperText Markup Language) cannot recognize. Microsoft ActiveX Document is a special helper program.

The second client-side application is to use Microsoft ActiveX Controls to create GIS Controls. GIS Controls are similar to GIS Plug-ins in that they are created to extend the capabilities of the HTML to handle spatial maps and data. GIS Controls are downloaded and executed in the user’s local machine.

The most recent development is to use Internet programming language Java to create GIS Java applets, which are executable small Java applications. GIS Java applets are downloaded from the Internet servers and are executed inside the Web browser immediately. All the GIS functionalities and data are encapsulated in the package and shipped to the client on demand. No plug-in or helper program is needed to be installed at the client’s Web browser. Because the GIS applications are executed at the user’s local machine, no unnecessary information exchanges between the Internet users and servers.

To overcome the limitations of the HTML, a client side GIS application called plug-in and helper program can be created. GIS plug-ins are small applications installed at the client side to extend the capabilities of Web browsers. The role of plug-ins is to provide seamless new GIS data supports for Web browsers and to facilitate the Web browser to communicate with GIS data.

While GIS plug-ins are small applications installed in the Web browser, GIS helper programs can be large GIS applications or existing GIS software that is located in the user’s local machine. GIS software like ArcView, MapInfo, CGM can all be GIS helper programs. When the Web browser detect a GIS data type in an HTML page, it will automatically launch the respective GIS helper program.

GIS plug-ins and helper programs handle GIS data directly, such as ArcView shape file, Intergraph CGM file and MapInfo file. They can also generate data that Web browser or other plug-ins will display. So they can be both producers and consumers of GIS data. Or, in other words, GIS plug-ins and helper programs can be GIS data translators or filters.

Like other plug-ins, GIS plug-ins handle GIS data from a URL that is provided as a stream as it arrives from the network. This allows a GIS plug-in to implement a progressive viewer without seeing an entire stream. Individual plug-ins can request multiple simultaneous data streams. The Web browser client caches plug-in data in its existing persistent cache mechanism.

Plug-ins are dynamic code modules. They are associated with a data type that the Web client has no native support for. When the Web browser starts, it enumerates the available plug-ins in a platform-specific manner and registers them according to their MIME type. When Web browser encounters an unknown data type (most GIS data types are unknown to Web browsers) in a Web page from a server it will look for a plug-in that is associated with that data type and load it. The work process of the client side GIS plug-ins is shown in Figure 2 and can be simply described as follows. The GIS helper program works the same way, and thus will not repeat here.

1. A Web browser user sends a request to the Web server by clicking on a URL via hypertext link.
1. The Web server receives the request, identifies the MIME types (e.g., shape file, or CGM file) of the requested data or document, and tells the browser what type of document is being sent.
1. The Web browser interprets the document according to its MIME types.
2. Since the browser does not support the GIS MIME types directly, it will look for a GIS plug-in or helper program that is associated with that MIME type to open the document.
1. If a GIS plug-in or helper program is not available in the local machine, they have to be installed and/or downloaded from the server over the network.
1. Once the GIS plug-in or helper program is installed, it is used to interpret and manipulate the GIS data. The plug-ins and helper programs communicate directly with the GIS data stream.

GIS plug-ins can be embedded within the HTML document as a rectangular subpart of an HTML page. This is similar to an embedded gif or JPEG map image, except that the image can be live and user can manipulate the map by zooming, panning and querying.

GIS plug-ins can also fill in the full screen outside the HTML document. This full-screen plug-ins will completely fill the inner frame of a browser window with its representation of some data type. MapGuide and Adobe Acrobat viewer are two examples of this kind of plug-ins. GIS helper programs usually fills the full screen outside the HTML document.

Plug-ins and helper programs can also be hidden, i.e., they can run in the background. An example of this might be a MIDI player.

GIS plug-ins and helper programs are used to extend the Web browser’s capability to seamlessly support GIS data. GIS plug-ins and helper programs enable web browser users to interact with spatial data. The user can use them to manipulate the GIS data. Plug-ins consume no memory (other than disk space) when they have not been referenced. The advantage of GIS plug-ins is to extend Web browsers to seamlessly support GIS data. Some simple GIS functionalities such as zoom, pan, query can be built in plug-ins and performed locally. GIS data are provided as a stream transferring from the network. The GIS plug-ins can implement a progressive viewer or make a particular decision without seeing an entire stream. A GIS plug-in can fetch data from the server as it needs on demand.

However, there are drawbacks of GIS plug-ins. First of all, plug-ins are dynamic code modules, native to a specific platform on which the Web browser runs. The specification for the development of Netscape/Microsoft plug-ins varies significantly by platform. They are not platform neutral. Therefore, plug-ins and helper program developers have to develop various plug-ins and helper specifically for different platforms. That is, individual plug-ins would need to be created for UNIX, Windows, and Macintosh operating systems.

Second, there are numerous GIS data types among GIS users, each GIS data type needs a plug-in to support. Unless a uniform GIS plug-in is developed that can handle or translate all types of GIS data types, or all GIS data use a standard file format, Web users have to download various GIS plug-ins in order to process different GIS data on the Web. For example, the user has to download a plug-in that supports CGM format in order to view CGM data file. He/she has to download another plug-in that supports ArcView shape file in order to view shape file, and other plug-ins that supports MapInfo, Maptitute, AtlasGIS data format. The proliferation of plug-ins by numerous applications on the Internet would lead to large Web client suite and cause problems in information management on the Internet.

The third drawback of GIS plug-ins and helper programs is that they have to be installed in the hard disk of the user’s local machine permanently. The numerous plug-ins downloaded would take a lot of disk space in the users’ local machine. This will be especially problematic if plug-ins and helper programs become more complex and grow in size and numbers.

A typical example of GIS Plug-Ins is Softdesk’s MapGuide (http://www.mapguide.com/).

A special helper program is Microsoft ActiveX Documents, which are documents created in Microsoft Office applications and other compatible applications that can be viewed inline in a Web browser. When an URL points to such a document, and the Web server serving it is configured with the correct MIME types, the application program that support that document can automatically be launched from directly within a Web browser.

A Web browser is an ActiveX container. When it comes across a file format, such as ArcInfo coverage or ArcView shape file, the file’s native program (ArcInfo or ArcView) can launch within the browser’s windows, combining the browser’s toolbar with the viewing program’s own, and combining the browser’s menus with the viewing program’s own. The result is a file that opens without conversion in the same, single-window as used to view Web pages, but with the functionality required to manipulate the new file. A user can now use the browser to access HTML pages on the Web and applications specific file on the local hard drive.

For example, ArcView shape files can be seen on the Internet as ActiveX documents. When shape files are encountered, they are considered by the browser to be OLE objects, and launch ArcView within the browser, combining commands and interfaces in a way that most people find much simpler and intuitive than either helper applications or plug-in modules. At the current stage, the native programs such as ArcView have to be preinstalled in the user’s local machine. In the future, this requirement may not be necessary. When a Web browser client click on an ActiveX document file format that requires another program, the browser will instruct the viewing program located on the server to ship along with the data over the Internet.

To make use of ActiveX Documents, the local applications have to also be ActiveX Document compatible. This means that local GIS software needs to be reconstructed to fit the needs of ActiveX Documents. At the current stage, there is no GIS software as I know being ActiveX Document compatible. A GIS viewer can be created to facilitate those who do not have their GIS applications available in their desktop and to provide capacity to view GIS documents without launching the full GIS application.

The advantage of ActiveX Documents is its capability to provide content from GIS software over the Web. Because the applications themselves are launched and used within the Web browser windows, the user has the added ability to edit and manipulate such files.

The second advantage is that ActiveX documents can be used to ease the task of collaboration over the Internet. It makes it easier for multiple people to access and manipulate GIS documents from these applications over the Web. The multiple-step process of transferring a file via FTP and then launching the appropriate application to edit the file, becomes a one-step process.

However, ActiveX Documents allow only serial collaboration; only on person at a time can work on a given document. And though ActiveX Documents can be read inline very easily with a compatible Web browser, once edited they cannot be saved directly to a central repository or to the original document source through the Web browser (Chappell, 1996). The updating process of GIS document is not automatic.

The primary use and benefit for most content providers of ActiveX Documents, therefore, is the ability to provide documents in many different applications via the Web and have them presented in their original form.

Another approach in the development of Internet GIS is the use of ActiveX controls to create GIS Controls. ActiveX is developed by Microsoft to "activate the Internet." It builds on the Object Linking and Embedding (OLE) standard to provide a common framework for extending the capability of Microsoft’s Web browser, Internet Explorer (Chappell, 1996).

An ActiveX is a modular piece of software that performs tasks and communicates information. It communicates to other programs, modules, and Internet via OLE. It can also be used and reused by any program or computer language that is able to contain ActiveX controls, such as Web browsers like the Internet Explorer 3.0 and Netscape Navigator (with certain plug-ins installed) or languages like Visual Basic, Visual C++, and FoxPro (Chappell, 1996). GIS controls have computational power, communications power, and their own small graphic interface, and can be used like plug-ins and Java applets within Web pages. There are many different types of ActiveX controls, each with different capabilities and functionalities. GIS controls are created to handle GIS data and perform GIS analyses.

ActiveX controls are similar to plug-ins. Both of them are dynamic modules to extend the functionality of Web browsers. But ActiveX controls can also be used by any programming languages or applications that support the OLE standard. ActiveX controls are general componentware that can plug into any application. Therefore, one can access an existing library of commercially available controls. Plug-ins, on the other hand, are specific to the browser. They can only be used in Web browsers.

As mentioned before, current Web browses cannot directly support GIS data type. When an HTML page contains GIS data it requires loading a specialized GIS plug-in, helper program, or GIS ActiveX Control into the client’s browser to view it. GIS controls are referenced inside an HTML document and executed by a Web browser. They initially reside on the server side. These controls are downloaded when a user connects to the Web site and invokes the HTML document containing a reference (<OBJECT> tag) to the GIS control. The GIS control is downloaded from a web server when it’s needed, or it might already be presented on the client machine if it was previously downloaded.

ActiveX controls integrate with Web browser client very flexibly and seamlessly. The GIS control can access an URL and retrieve MIME data just as a standard Web browser client does. GIS data are streamed asynchronously to the GIS control as it arrives from the network, making it possible to implement viewers and other interfaces that can progressively display information. If the GIS control needs more data than can be supplied through a single data stream, multiple and simultaneous data streams can be requested by the GIS Control.

ActiveX Controls are generally embedded within HTML code and accessed through the reference <OBJECT> tag. GIS controls are loaded as needed and executed on the browser’s machine. Figure 3 illustrates some of the following steps that take place when loading a GIS Control:

1. A Web browser user sends a request to the Web server by clicking on an URL via hypertext link.
2. The Web server receives the request and loads the HTML file.
3. The Web browser interprets the HTML file and detects the GIS Control reference <OBJECT> tag.
4. The GIS control is downloaded from the server.
5. Other Control files and data files referenced by the GIS Control are detected and downloaded as well.
6. The GIS control is displayed inside or outside the Web browser, as embedded controls, full-screen controls or hidden controls.
7. The GIS controls, with their built-in GIS functions, interpret and manipulate GIS data that streamed asynchronously from the server.

Similar to Plug-ins, ActiveX controls need to be downloaded and installed in the user’s local machine. ActiveX controls reside on disk until they are needed. They do not take any RAM until they are used. An ActiveX control is removed from RAM as soon as the user moves to another HTML page that does not require it. But ActiveX does take local disk spaces.

Similar to GIS plug-ins, GIS controls are not platform neutral. The developer has to create different Controls for different platforms. Furthermore, because there are different GIS data formats, many GIS controls have to be created to handle and interpret these GIS data formats.

Netscape Navigator does not support ActiveX Controls on its own and will ignore any controls embedded in a Web page through the use of the <OBJECT> tag. However, with one of the Ncompass Labs plug-ins installed, Netscape Navigator also supports ActiveX controls and will interpret embedded objects correctly.

The MapObject Internet Map Server (http://www.Esri.com/) created by the Environmental Systems Research Institute (Esri), Inc. adopts the GIS ActiveX Control approach. So does the GeoMedia Web Map server developed by Intergraph Corporation (http://www.intergraph.com/software/).

Another interesting implementation of the ActiveX Controls is the Citrix’s WinFrame Web Client ActiveX Control (http://www.citrix.com/). The WinFrame Web Client ActiveX Control can allow users access GIS data and applications remotely. WinFrame Web Client uses the techniques of Application Launching and Embedding (ALE) to run applications remotely from a Web page. Users can launch an application from a Web page by clicking on a hyper-link. The server will launch a GIS application in a window on the user’s local desktop. The launched application can run on its own window or within the Web page (embedding). The user can then use this application as if it were installed and running locally on his/her own machine.

Besides the GIS applications, WinFrame Web Client can also support other applications such as spreadsheet. Using this technology, information providers are now able to serve documents in any format, without regard to whether or not their users have compatible software (other than a Web browser and WinFrame Web Client). The users can not only use the remote application to view the data and document, but they can also use the application to edit and manipulate the information, save it to a local file, or even save it back to the remote site (if the file permissions there allow).

The most recent Internet-GIS is to use Internet programming language Java. Java is an object-oriented programming language. Java applets are mini applications that run inside a Java-enabled Web browser. Java applet is seamlessly integrated inside the Web browser, and is downloaded and executed on a client computer on demand. Java provides a wide range of tools for creating and displaying graphics. It is the most appropriate to manipulate GIS data on the Web.

GIS Java applets are written in Java. They are created to interpret GIS data and perform GIS analysis. Each GIS function such as zoom in, zoom out, zoom area, query, label and the report of query output could be one applet.

GIS applet is executable code resides on a machine that is accessible to a Web server at a Web site. GIS applets are referenced inside an HTML document and executed by a Web browser at the client side. They initially reside on the server side, just as HTML documents, GIS plug-ins and GIS controls do. These applet class files are downloaded and executed when a user connects to the Web site and invokes the HTML document containing a reference (<APPLET> tag) to the GIS applet. There is a specific sequence of events that takes place when a Java-enabled browser loads an HTML document and GIS applets. Figure 4 illustrates some of the following steps that take place when loading a GIS applet:

1. A Web browser client sends a request to the Web server by clicking on a URL via hypertext link.
2. The Web server receives the request and loads the HTML file.
3. The Web browser interprets the HTML file and detects the <APPLET> tag.
4. The Applet class file is downloaded from the server.
5. Other Java class files and data files referenced by the applet class are detected and downloaded as well.
6. The GIS applet is displayed inside the Web browser or outside, if it uses its own frame.
7. The GIS applet interpret and manipulate GIS data.

The major difference between a Java-based GIS program and a traditional stand-alone GIS application is that Java programs are network-aware or network-centric and truly distributed computing. GIS Java applets present a model much closer to the stand-alone GIS programs users are running on their own PCs. Internet GIS written in Java offer almost all benefits of locally executed GIS programs: responsiveness, the capability to take advantage of local computing resources, graphic search and so on. Yet, at the same time, Internet GIS programs break the shackles of being tied to a single PC. They can take advantage of computing resources from the entire global Internet.

More specifically, GIS Java applets provides the following important characteristics not present in the HTML, plug-ins and GIS Controls:

1. Java applets are dynamic, whereas native HTML is relative static.
2. Because Java applets run on the client side, not on the server, Java applets can make better use of local computing resources.
3. Java is designed to be "architecture neutral." For vendors and developers, it means larger potential markets, and the elimination of costly "software porting" efforts. For consumers and users, it means lower costs, increased choices, and greater interoperability between components.
4. Java applets are installed on demand on the client-side Web browser when the user initiates the request and could be automatically un-installed when the user quits the application. Therefore, the Java applet does not take any permanent disk space on the client’s local machine, which is not the case for client-side plug-ins and ActiveX Controls which are left on the client-side machine after the user quits the application.
5. Java applet is more flexible to create and display graphics and maps. Therefore, the user interface can be extended to include more complex client-side maps and query capabilities
6. Because a Java program consists of bytecodes, it tends to be smaller and lends itself better to transferring across the Internet. The bytecode scheme also lends itself to far greater levels of runtime optimization than scripting languages. The just in time Java compilers built into newer Web browsers can make Java programs run almost as fast as native executables.
7. Java has a high security mechanism and is safe to use. When a Java applet or application is downloaded, Java runs on the JVM (Java Virtual Machine) on the user’s local device. Programs have no access to local system resources. No viruses can corrupt local memory or local file system.

The drawback of Java applets, however, is that they have to be run in a Java-enabled browser. Since browsers for Windows 3.1 platform are usually not Java-enabled, GIS Java applets cannot run in Windows 3.1 platform. However, this could be changed, an additional plug-in can be installed in those browsers which allow the run of Java applets. The biggest drawback of Java applets is that they cannot save GIS data and analysis results to the local machine because of the Java security restrictions. Furthermore, the Java applets cannot connect with other computers on the network other than the one they were downloaded from. This prevents the truly distributed processing that is essential in Internet GIS.

Several programs are using Java applications on the Web, such as the ArcView Internet Map Server being developed by the Environmental Systems Research Institute, Inc. (http://www.Esri.com/) and ActiveMaps by Internet.com (http://www.internetgis.com/).

In the evolvement of Internet GIS, in spite of great progress made, there are several issues are yet to be resolved. First, most Internet GIS can only be considered as Internet mapping. There are basic functions for interactive map view such as zoom, pan and query. However, there lacks more advanced GIS analysis functions such as buffering, spatial object overlay, network analysis, to name a few. To empower Internet GIS with more analysis functions become an imminent challenge. The second issue is the performance. GIS data, especially raster and image data, are large in volume. They take long time to transfer over the Internet. This poses big problem especially for slow Internet correction like modem connection. The third issue is security. When plug-ins, ActiveX Controls and Java applets are downloaded from the Internet and executed in the user’s local machine, how would one be sure that those applications are safe to use? The fourth issue is who should pay for this service and how to charge the usage.

At the current stage, the functions of most Internet GIS are still limited to GIS mapping and viewing. GIS analysis functions such as spatial analysis, buffering and overlay are yet to be developed.

Some GIS analysis functions are prohibited by the limitations of the HTML. For example, if we are using CGI-based Internet GIS approach, it is very difficult, if not impossible to perform functions such as spatial data overlay, spatial object buffering, because the HTML cannot allow you to even draw a rectangle on a map image.

GIS plug-ins, ActiveX Controls, and Java applets are all small applications. Potentially, more functionalities can be added to the interfaces of these small applications. But that would make these application programs large, which will cause problems in just-in-time delivery.

Furthermore, it would be difficult to develop GIS analysis functions using single plug-in. There are so many GIS analysis functions, the single plug-in has to be either very large, or it has to call a lot of other plug-ins. The management of the proliferation of plug-ins would be more problematic.

To empower the analysis function of Internet GIS, it will be the future trend to create standard individual function modules or components. These standard function components enable developers to produce "plug and play" GIS analysis tools. These function components are assembled in the client’s Web browser on demand when they are needed. This componentized or modularized approach is also in line with the trend of the world of computing, which is moving toward componentware and network-based computing. This approach demands a standard specification to ensure interoperability. It seems that the Open GIS Consortium is working toward this standard Open Geodata Interoperability Specification (Buehler and McKee, 1996).

Java offers the most potential to create modularized GIS analysis functions. It can offer the user the capability of drawing, selecting graphics and thus thematic objects. In addition to small Java applications like Java applets, Java program can develop large applications that can be run on the Internet. Each function can be an object class, which can call one or more other classes.

A major drawback of current Internet GIS is its slow performance. It takes a long time to initially download the vector and image data, GIS plug-ins, controls and Java applets. This will become especially a problem when more analysis functions are added to plug-ins, controls and Java applets. A progressive data stream helps in a way that it will not make the user feel boring when looking at the screen. However, the user cannot do anything until all the data arrive. It is not uncommon to have data with 100k in size. It will take about anywhere from 30 seconds to 10 minutes to load. It will take much longer if you are using slower speed modem. This is a significant amount of time just waiting for data.

The issue of slow performance can be tackled in two ways: increasing the speed of Internet connection and developing more efficient Internet GIS programs. The speed of Internet connection is improving with faster modem and faster communication connections. At the higher education institutions, the next generation of Internet, Internet 2, will increase the Internet speed dramatically (Shapley, 1997). This fast Internet connection will make the current GIS data movement on the Internet a trivial task.

On the other hand, an efficient design of Internet GIS program will make it feasible to run Internet GIS even at a slower speed connection. A componentized design of GIS analysis tools and data, and the just-in-time delivery mechanism can allow the Internet GIS user to initially download the minimal GIS functions and data. Other data and analysis tools can be streamed asynchronously to the user on demand.

Because GIS data, including vector and raster data, is large in volume, the performance of current Internet GIS is an issue. But it will become less an issue in the near future when the Internet connection becomes faster and Internet GIS design becomes more efficient.

Security is less an issue for server-side applications, because there is no program codes that are executed in the user’s local machine. It is, however, a concern for client-side applications, which are downloaded from the network, often from machines over which the user have no control. Such application codes could contain fatal flaws or viruses that could damage the user’s local machine.

Plug-ins, helper programs and ActiveX Controls are binary codes executing directly on the machine’s hardware. Therefore, all of the dangers of running unknown software from the Internet apply to them. Unknown plug-ins and ActiveX Controls downloaded from the Internet can do anything on the client computer. How do you know that a downloaded ActiveX Control won’t erase your hard drive (Chappell, 1996)?

To address this concern, Microsoft’s Internet Explorer Web browser supports Authenticated code-signing technology and Netscape uses Object Signing protocol. This enables vendors of ActiveX Controls and developers of plug-ins and other software components to digitally sign these components. When they are downloaded and the digital signature is recognized, a code signature certificate is displayed on the screen. This certificate ensures that the software component is coming from the trust source and hasn’t been tampered with (Chappell, 1996). The user then decides whether to install the applications on his/her local machine.

The download and execution of Java applets are relatively more secure. All applets loaded over the network are assumed to be potentially hostile and are treated with appropriate caution. Java has established the Java security framework to establish an intelligent, fail-safe stance for the execution of Java programs (Weber, et al. 1996). The Java security framework consists of three major layers that create the Java execution environment, from the Java language, to the Java compiler and verifier, to security managers in the runtime. When Java bytecode is loaded, it has to be verified by the Java verifier. If the verifier cannot confirm that the code being loaded was produced by the Java compiler, the code will not be loaded and executed. On the browser side, a specific policy has been identified for the loading of untrusted applets. For example, Java applets are not allowed to create, modify, or delete files or directories on the local system. They are not allowed even to read file on the local system.

Java applets are safer, but there are not error-free either. Several flaws have been found in the Java security system. Furthermore, this very restrictive secure system imposes some restrictions on what can be done using Java applet in the development of Internet GIS. For example, Java applets are prevented from accessing other machines on the network other than the one from which the applet was loaded. This imposes serious problems in developing the Internet GIS as a distributed system. Furthermore, because applets are not allowed to write on the local system, data cannot be written and saved to the user’s local machine (Weber, et al. 1996).

Internet security is not unique to Internet GIS. It applies to all Internet applications. As the overall Internet security improves, Internet GIS will become more secure and more flexible.

In addition to the issues discussed above, there are other issues to be concerned, including the institutional issues and cost-recovering issues. For example, what kind of information should be published on the Internet and be accessed by the general public? What are the liability consequences of false and inaccurate information, especially GIS information published by the governments?

Since Internet GIS can be accessed by anyone who has Internet access, who should pay for cost-recovery or profit? Should the consumers be charged to access Internet GIS data and analysis tools? If so how to charge them and how much?

Furthermore, NetPCs is entering the market. How NetPCs, especially Java-based NetPCs, affect the future development of Internet GIS? These issues and many others deserve a serious thought among the GIS users, developers and GIS data providers. They are beyond the scope of this paper and thus are not addressed here.

Internet GIS has emerged and is rapidly evolving. Integrating GIS with Internet is an inevitable trend of the future. It is important for the GIS community to monitor and define the course of its development. Hopefully, the discussion in this paper will generate some systematical discussion among GIS users and developers.

Internet GIS is a network-centric GIS tool that uses Internet as a major means to access and transmit distributed data and analysis tool modules, to conduct analysis and visualization. Internet GIS allows the end user to download all componentized data and analysis modules directly from the network servers on demand. The end user does not necessarily need to have desktop GIS software installed in his/her local system.

The current server-side Internet GIS based on stateless http and CGI script offers little flexibility and interactivity to the end user. The user cannot directly work with spatial object as one does with the vector-based stand-alone GIS software. The limitations of the stateless HTTP prohibit the construction of more advanced analysis tools in the development of interactive GIS on the Web. It can merely be used for static spatial query and display.

The client-side Internet GIS offers more flexibility and interactivity than the server-side applications. GIS plug-ins, helper program and ActiveX Controls extend the capability of HTTP to directly handle GIS data. The end users can view GIS data and perform simple analysis on the Web just like they work on local GIS software. However, the platform-dependent specifications of plug-ins and ActiveX Controls impose information management problems for both users and developers.

Java offers its unique contribution to Internet GIS with its object-oriented and platform-independent characteristics. It is an Internet programming language that is well suited for graphic presentation on the Internet, an essential part of Internet GIS. Java applets are more secure to be loaded from the network and executed in the user’s local system. Although the Java programming language seems offer the most promising for the future development of Internet GIS, several issues need to be addressed, particularly access to local system and access to other remote computers. It is essential for Internet GIS to be able to take advantage of the distributed processing to access analysis models and distributed data on the network in order to achieve high interoperability. It is also desirable for end users to be able to save data and results to the user’s local system. For Java to be the programming language of Internet GIS, these issues have to be resolved.

Interactive mapping is only the first step in the development of Internet GIS. Future developments will inevitably focus on interactive GIS analysis. The trend is toward small-componentized GIS analysis modules, just-in-time delivery and network-centric architecture.

Bishr, Y.A., M. Molenaar, and M.M. Radwan, 1996. "Spatial Heterogeneity of Federated GIS in a Client/Server Architecture." Proceedings of GIS ‘96, Tenth Annual Conference on Geographic Information Systems, Vancouver, British Columbia, Canada, March 1996

Buehler, Kurt and Lance McKee, 1996. "The OpenGIS Guide: Introduction to Interoperable Geoprocessing." OGIS TC Document 96-001. URL: http://www.opengis.org/guide/guide1/htm.

Chappell, David, 1996. Understanding ActiveX and OLE, Redmond, WA: Microsoft Press.

Coleman D.J. and John D. McLaughlin, 1997. "Information Access and Network Usage in the Emerging Spatial Information Marketplace," Journal of Urban and Regional Information Systems, spring 1997

Frew, James, et al. 1995. "The Alexandria Rapid Prototype: building a digital library for spatial information." Proceedings of the 1995 Esri User Conference, May 22-25, 1995. URL: http://www.Esri.com/resources/userconf/proc95/toc1.html.

Hall, Carl L. 1994. Technical Foundations of Client/Server Systems, New York: John Wiley & Sons, Inc.

Matuschak, Brian J. 1996. "Commentary: GIS is Being Redefined by Current Computing Trends," The Electronic Atlas Newsletter, Vol. 7, No. 9

Peng, Zhong-Ren and Douglas, D. Nebert, 1997. "An Internet-Based GIS Data Access System," Journal of Urban and Regional Information Systems, spring 1997

Shapley, Deborah, 1997. "Scientists Use Fiber Optic Network as Internet Alternative," New York Times (online edition), January 27, 1997

Weber, Joseph, et al. 1996. Special Edition Using Java, Second Edition, Indianapolis, IN: Que Corporation