The Methodology
Web Publishing of Spatial Data:
CGI and Data Publishing
Before the development of the World Wide Web (the Web, WWW), the Internet was used only as a tool to transfer data. Since the inception of the Web, GIS professionals realize that GIS can be expanded onto the Web, and it can evolve into a new GIS technology. Different GIS techniques have been developed on the Internet. There are three types of such techniques: common Gateway Interface (CGI), plug-ins, and Internet Programming Language (IPL). The plug-ins are the GIS helpers in a browser, and it is client-side implementation of Internet GIS. It is commonly considered as fat-client. The IPL includes Java, ActiveX, etc. It is the future direction for the Internet GIS, but it is currently not mature.
Pros and Cons 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 the translator between the browser client and the GIS server.
The processing workload on the client side is minimal. Since all processing is conducted by the GIS server, the CGI-based Internet GIS can take advantage of the functionality of existing GIS server software such as ArcInfo.
The CGI-based Internet GIS, however, is restricted by the limitations inherent in the Web browser and the static HTML. Server-side Internet GIS is based on stateless HTTP and CGI scripts. The user cannot directly work with spatial objects as with stand alone GIS software. In addition, an HTTP Web server doesn't remember calls between requests. The whole routine from browser to Web server, invoking the CGI script and initializing the GIS server must be repeated if a user wants to pan in the map delivered by the Web server. End result? Increase in traffic on the Internet.
In addition, every operation must be conducted by the GIS server creating a bottleneck during high usage periods. This results in the slowdown of information transmission between the CGI script and GIS server and the browser user. Since the CGI script single-handedly handles all requests from the Web browser and then interprets all output from the GIS server, it becomes very difficult for the CGI script to handle large amounts of requests from users, especially concurrent requests. A considerable load is placed on the server of a frequently accessed site. The CGI script can also be a vulnerable point. When the CGI script or the GIS server fails to work properly, the whole system will fail.
Finally, the product of all the GIS server's work is more static images. The Web browser passively displays these static map images. The only interaction with HTML documents is by selecting hyperlinks. The limitations inherent to the Web prohibit the direct manipulation of maps on the browser. For example, the user cannot select a feature by dragging a rectangular, circular or irregular polygon on a map image. Likewise, the user cannot select a linear or a point feature on the map.
There are many reasons why it is worthwhile to integrate a governmental Land Records System or GIS with the WWW environment using CGI:
- An economical solution
- Provides a single venue for sharing data and applications
- GIS computing power performed on the server side can be brought to the user without requiring the user to purchase expensive GIS software and hardware
- A platform and device independent standard user interface environment already exists (e.g. the Netscape browser is free and works on UNIX, Windows and Mac platforms)
- The WWW is a hypermedia, multimedia environment, allowing easy integration of many types of information
- Can be a source of revenue generation
- A GIS project integrated with the WWW has unlimited potential
Performance of Internet GIS
Although instructions required to initiate GIS processing can be transmitted across the Internet in a relatively compact manner, a major drawback of current Internet GIS technology is its slow performance. It takes a long time to transfer vector and image data. This will become more evident as additional analysis functions are added. A significant amount of time is spent waiting for data. Slow response times usually cause the user to lose interest.
Slow performance can be addressed in two ways: increasing the speed of Internet connection and developing more efficient Internet GIS programs. The speed of the Internet connection can be improved by using faster modems and faster communication connections. Conversely, the efficient design of the Internet GIS program will make it feasible to run even at a slower speed. The modularized design of GIS analysis tools and data, and the just-in-time delivery mechanism can allow the Internet GIS user to initially download the minimum GIS functions and data. Additional data and analysis tools can be delivered to the user as needed.
Security
"Domain-level" control is where the web server rejects or accepts a connection based on the IP address of the requesting browser. This level of access control is ideal for an internal company web server by limiting access to a whole class C network or even higher. The second level of control is "user authentication", in which the client must enter a user id and password to validate the right to access the requested document. This technique can be used to implement subscriptions in your html directory. The downside of user authentication is that not all browsers support it. The best solution is to use a combination of domain-level and user authentication access controls. All access controls work with your html directory tree, not with individual html documents. If you need to control access to one individual document, that document must be put into a separate directory.
The access control you set in your web server affects what documents it will send to a browser, NOT what an already-logged-in user can do. Because someone has access to web document directories does not mean that they have to have an actual account on your server. Security becomes less an issue for server-side applications, because there is no program codes that are executed in the user's local machine.
Security issues are not unique to Internet GIS but all Internet applications. Internet GIS can take advantage of the fail-safe measures as they are developed for the Internet as a whole. Regardless, by implementing access control you can devise many entrepreneurial opportunities for your web site.
Institutional Issues
In addition to the issues already discussed, there are other issues impacting development of Internet GIS, including institutional and legal concerns and cost-recovery for development of a Web based solution. Policies and procedures must be adopted that determine the information that can be published on the Internet and accessible by the general public. Liability consequences of false or inaccurate information, especially GIS information published by government, must be minimized at all costs.
Since Jaipur-GIS can be accessed by anyone who has Internet access, who should pay for cost-recovery or profit? Should taxpayers or for profit companies be charged to access Internet GIS data? How about analysis tools? If so, what is the fee schedule and how should they be charged?