Local time: Monday, 09-Oct-95 19:58:11 EST
Last update: at /special/conference/apwww95 , Sunday, 08-Oct-95 17:29:12 EST

Developing Geographic Services on the World Wide Web

Anthony P. Steinke

School of Environmental and Information Sciences,
Charles Sturt University,
P.O.Box 789, Albury, NSW 2640,
Australia

asteinke@csu.edu.au, http://life.csu.edu.au/~asteinke

Paul Bristow

Division of Information Technology,
Charles Sturt University,
P.O.Box 789, Albury, NSW 2640,
Australia

pbristow@csu.edu.au, /phonebook/pbristow.html
Abstract
The World Wide Web has great potential as an interface into geographic information systems and services. A growing range of geographic services including geographic indexes, real-time mapping of species distibutions, interactive world map generators and other environmental data is already on-line. The current browsing softwa re places some limitations on the variety of input types from the user, especially in the area of spatial input. Other issues involved in the development of on-line geographic services include preservation of state, image generation and conversion techniq ues, image caching and data formats. The future of on-line GIS looks promising with new techniques such as client-side processing and new standards and protocols. Although our work has been in geographical services and information, many of the issues ment ioned above are universal, relating to WWW services in general.
Keywords
Caching, CGI, Geography, GIF, GIS, HTML, HTTP, PERL, SIN, SSI

Introduction

The explosion of internet activity over recent years has sparked a global move away from traditional isolated single-software, single-machine computing, towards distributed multiple-software, multiple-machine computing. The advantages are obvious - larger information base, up-to-date information and greater computing power.

Many GIS projects today require facilities for many contributors, many users and many types of multi-media output. The isolated computing approach no longer meets the requirements of these systems, a distributed computing environment can fulfill these req uirements, but needs to be capable of supporting many contibutors and users across different platforms.

The solution is to provide remote access to GIS services via computer networks, ie. the internet. More specifically, the World Wide Web provides an ideal platform-independent, multi-media communications medium. Here we address the viability, development a nd future of on-line geographic information services.

Rationale

The motivation behind the development of on-line geographic information services at Charles Sturt University is due to a number of factors:
  1. A Global GIS Community
    Geographic Information Systems play an important part in many areas of research and study, most efforts to date however, have been made by individual groups, with much duplication of effort and results. The World Wide Web (WWW) has the potential to overco me these problems by providing an environment for a distributed GIS community, sharing data, ideas, and services. A model outlining this approach to networking information, services, and people within a specific area of interest, has been developed by Dav id Green and is called a Special Interest Network, or SIN [GREE95a].

  2. Multi-media Capabilities of the Web
    The multimedia capabilities of the Web make it an ideal medium for the implemention of geographic applications and services where much of the data involved is best represented graphically. The ability to easily produce documents that can contain text, hyp ertext and graphics, and produce them in a format that is accessible across the globe and on many different platforms, makes the Web a very powerful communications medium, ideal for networking geographic applications.

  3. Portability/Accessability
    A major factor in the enormous popularity and growth of the Web in recent times is its platform independency and wide accessibility. This has led to an explosion of information and services on the Web due to the ease of publication with respect to both ef fort and time, and the large potential audience.
There are however some limitations to using the Web as a medium for geographic, or indeed, any interactive service:
  1. Stateless Nature of HTTP
    The World Wide Web has been implemented using the HyperText Transfer Protocol (HTTP), a stateless protocol in which each transaction is treated independently from any other. This characteristic has one major implication for the development of interactive Web services: the problem of maintaining context. In order to achieve some degree of continuity from one Web page to the next within an interactive service, some method of storing the user's state is required. Fortunately, with the development of the Comm on Gateway Interface (CGI), this limitation can be overcome by a number of methods which will be outlined later.

  2. Limited Input types from Graphical Elements
    One of the limitations imposed on Web-based GIS services by current browsing software and HTML specifications, is the inability of the user to select more than one point from a map at a time. With respect to geographic applications, a more sensible and mo re powerful input mechanism would be the selection of a set or region of points.

Existing Geographic Services

A vast range of geographic information services already exists on the World Wide Web. The services range from meta-indexes of GIS-related WWW sites to interactive services allowing the creation of user defined maps. Some of these on-line services are listed below.

Geographic Indexes

Interactive Maps

Customized Maps

Maps as database outputs

Making the Web Interactive

An interactive Web service is one in which the content of subsequent Web pages depends upon previous input from the user. A searchable index, for example, returns a Web page consisting of a list of references to documents matching the search parame ters. This page has been created dynamically as a result of the user's input, and could be one of an almost infinite number of possible responses. A service such as this is termed interactive.

Interactive Web services can be implemented either by using server-side includes or through the Common Gateway Interface.

The Server-Side Include (SSI)

A HTML document may include either another file, or the output of a program by using what is known as server-side includes. The ability to include the output of a program is what makes SSI's suitable for implementing interactive Web services.

SSI's are implemented by the httpd server, which parses the document before sending it on to the requesting client. The httpd server replaces any SSI's with the appropriate text. The format for a SSI is:

[an error occurred while processing this directive]

Web pages that include something along the lines of "You are the 2435th person to access this page" generally use server-side includes. The HTML document contains a line like:

You are the <!-- #exec cmd="/somepath/someprogram"-->th person to access this page
The httpd server replaces the SSI tag with the output of the /somepath/someprogram command, in this case it would be some form of counter program.

Some points to note about SSI's:

  1. The client browser receives the parsed document and hence has no knowledge of the SSI.
  2. A SSI can only return text, ie. no images etc.
  3. The httpd server must be configured to allow SSI's, otherwise the server will return the file as is, with no parsing. (in that event the browser would treat the SSI tag like a comment and not display it).
  4. The same functionality obtained using SSI's can be implemented using CGI scripts.
  5. Documents including SSI's are not HTML documents in the true sense until after they have been parsed. The common file extension for a SSI file is .shtml.
SSI's can be very useful in many applications, however due to their inability to return images, the usefulness of SSI's is limited in geographic services.

For more information on SSI's, see http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html [NCSA95a]

The Common Gateway Interface

Introduction

The Common Gateway Interface, or CGI, is an interface that allows external programs to be run from an information server. The CGI makes interactive Web services possible and is currently only sup ported on HTTP servers.

CGI programs are accessed through the Web just as a normal HTML document is, through a Uniform Resource Locator, or URL< /a>. The only condition placed upon CGI programs is that they reside somewhere below the CGI binary directory configured within the httpd server (usually called cgi-bin). This is so the server can determine whether to return the file as a document, or execute it as a CGI program based on the file's path.

The most common use of CGI is to handle the results of form and query submissions for HTTP.

The CGI Process

Information flow through CGI is illustrated in the figure below.

CGI Information Flow

  1. The result of a form or query submission is passed from the client browser to the httpd server.
  2. The httpd server forwards the information from the browser to the appropriate CGI program.
  3. The CGI program processes the input and may require access to certain data files residing on the server, such as a database.
  4. The CGI program writes either of the following to standard output:
    1. a HTML document
    2. a pointer to a HTML document in the form of a Location header that contains the URL of the desired document
  5. The httpd server passes the output from the CGI process back to the client browser as the result of the form or query submission.

CGI scripts can be written in virtually any programming language, with C, PERL, Visual Basic and shell scripts being the most common. PERL is the language of choice for many CGI programmers due to its powerful string manipulation and regular expression ma tching functionality. This makes PERL well suited to handling both CGI input from HTML forms, as well as producing dynamic HTML documents.

For more information on CGI, see http://hoohoo.ncsa.uiuc.edu/cgi/overview.html [NCSA95b]

Programming Considerations

Preserving Context

The need for preservation of context is a result of the stateless nature of the HTTP protocol. To provide continuity from page to page in an interactive Web application, some means of storing the user state is required. There are a number of ways of accom plishing this:
  1. Hidden Variables
    Hidden variables are defined within a HTML form object by assigning type=hidden within an input tag. Consider the following HTML line:

    <input type=hidden name=foo value=bar>

    The key-value pair of foo=bar will be passed to the CGI program just like any other form input variable. The point being that the user cannot modify its value directly. A combination of hidden variables can be used in this way to identify the key p arameters that define the current state of the user.

    The Interactive World Cities Map service developed at CSU uses this method of preserving state [STEI95a].

  2. Server-side storage of user state
    The CGI program can store the state of each user in a file located on the server. In order to do this some method of distinguishing users is needed. The remote address stored in the REMOTE_ADDR environment variable could be used, but the possibilit y of more than one user from a particular host accessing the service makes this an unattractive approach. A more foolproof method is to ask the user for some form of identification, such as an email address, a name and password, or some combination of the se.

  3. Client-side storage of user state by using HTML Cookies
    A HTML cookie is a mechanism by which server-side processes can store and retrieve information on the client side of the connection. The cookies are set in the object header of the returned document, included in that header is a range of URL 's that the cookie is to be returned for. The client will store the cookie and when it requests a URL that matches the specified range for that cookie, it sends it along with the request.

    Some limitations of HTML cookies are that the cookies only last till the end of a session, they are only implemented on Netscape browsers, and there is a limit to the number and size of cookies the browser can store. [NETS95]

Image Generation/Conversion

The standard formats for displaying in-line images within HTML documents are the GIF format (Compuserve's Graphics Interchange Format), and the JPEG format. GIF's are better suited to geographic applications because they implement a lossless compression a lgorithm, whereas JPEG's are lossy. There are two ways of producing a GIF file:

  1. Create as a GIF
  2. Create in some other format and convert to GIF
The method used is dependent upon the tools used to create the image. The most eficient method is to create a GIF from the outset, but if your program depends on 3rd party software that does not support the GIF format, conversion to GIF will be required.

A useful GIF creation/processing library written in C is GD (current version 1.2 as at 11/8/95). This library has been written by Thomas Boutell and is freely available as C source from http://siva.cshl.org/gd/gd. html [BOUT95].

Image Caching Techniques

Image caching has the potential to greatly improve the speed of the service from the users perspective, as well as reducing the load on the server cpu. The idea with caching is to keep copies of frequently requested images on disk, returning these files instead of regenerating the image every time it is requested. The way a cache is implemented should depend on the nature of the application, the size of the images and the disk space available for caching.

Development of an on-line GIS service:
World Map Maker [STEI95b]

The World Map Maker, developed at Charles Sturt University, is an interactive on-line service designed as an interface into the Generic Mapping Tools (GMT) package. GMT has been developed by P. Wessel and W. Smith and provides a number of mapping and data manipulation commands that produce maps as PostScript output files [WESS95].

The aim of this project was to provide an on-line service that would allow the user the greatest possible control over the creation of a map, as well as the ability to overlay user defined data, using the GMT package. The service was to be implemented usi ng a HTML form and CGI scripts. Some of the major development issues encountered during this project are discussed below.

Image Creation and Conversion

The map images are created by calling various GMT commands with parameters defined by the user within the HTML form, and capturing the output from these commands in a PERL scalar variable. The contents of this variable are then written to a temporary Post Script file, which is converted to the GIF format by the GhostScript Program. An example of a map produced by the World Map Maker follows.

Linear Projection Plot

In order to include in-line images within a HTML document, either GIF or JPEG format graphics files are needed. As the GMT commands output only in PostScript, some form of image format conversion from PostScript to GIF is required. The Ghostscript software package was chosen for use in this project because it is able to interpret the PostScript language and output in a number of different formats, including GIF, and it is freely available [GHOS95].

HTML Form Creation

The HTML response from a form submission is created on the fly from a template file. The CGI script parses the template file, which is essentially a HTML document with special tags that are replaced during parsing with the value of form vari ables, or values derived thereof.

It was desirable to return map images that were not to be cached, directly from the CGI script, instead of creating a temporary file on the server disk which would have to be deleted at a later time. In order to do this, the CGI script contains two distin ct functional modules. The first module reads in the form input, calculates the new map bounds and projection parameters, and returns the HTML response. This response contains an image src attribute which is set to the URL of the same CGI script, b ut with different parameters this time so the script knows to return the image source. The second module creates the image, and returns it on standard output, removing the need to create a temporary GIF file on the server disk. The following diagram illus trates the structure of the World Map Maker CGI script:

CGI Script Structure

Overlaying User Defined Data

A text input box is provided on the HTML form for the input of user defined data. This data may consist of point, line, and polygon data, with optional labels for each element. After some trivial parsing, this data is piped into the GMT psxy (point , line and polygon data) and pstext (labels) commands which overlay these elements on top of the base map.

Transverse Mercator Projection Plot with Overlayed Cities

Future Prospects

Interactive Global Information Systems

The development of clickable maps that allow zooming in to any region of the world, at any scale, is paving the way toward the realisation of interactive global information systems. When implemented as an interface to an information database, in which the data is organised by geographic location as well as by theme, the interactive map/database interface becomes an extremely powerful information tool, capable of not only allowing the searching and extraction of information based on geographic location and subject, but also providing the mechanism for user submission of data.

The ability of the user to add to the database, has the potential to provide both a large quantity and broad cross-section of information, far exceeding the capability of any single data gathering organisation. A major consideration associated with gather ing data in this fashion, however, is that there are no controls over the quality of information attained. Some form of quality assurance is necessary in any information gathering/vending application to ensure the validity of data.

The applications of such a system are virtually limitless. Imagine planning a holiday over the Web, first zooming into a continent, then a country, then down to individual islands and towns. Extracting information about the places, people, customs, food a nd accomodation, and even booking your holiday over the Web.

Client Side Processing

Client side processing has three major potential applications for GIS on the World Wide Web. Client side processing can be used:
  1. To enhance clients' ability to specify their requests
  2. To improve clients' abilty to submit information relevant to the GIS service
  3. To distribute the workload involved in manipulating information from servers
  4. To provide image processing on clients' own data.

Specifying Client Requests

A problem with the current situation in GIS on the WWW is the limitation on Image maps that they only return a single point. It is especially desirable for GIS that clients can specify multiple points on a map or 'rubberband' regions of interest on a map. An httpd server is inherently capable of accepting a series of points - the problem is that the browser is unable to specify more than one point from a map.

Therefore programs are required on the client side which can deal more flexibly with image maps. These programs will require sufficient integration with WWW browsers to be able to send the selected points back to an httpd server through the browser.

Similar programs could also provide more interactive forms - for instance displaying or allowing options on the form dependent on previously selected options. Currently the only way to achieve this is to use a series of forms which store state information from the previous forms as hidden fields. This use of multiple forms tends to be clumsy and slow - the client must wait for each form to be sent and the next received for each step of the process.

Allowing client submissions

There is a multiplicity of information on the Internet and a multitude of people who may have relevant geographic information to contribute. As geographic information becomes more detailed and more integrated with deatils of small communities the collecti on of information may also become more distributed. For instance if social information is being linked to a geographic database people from within isolated communities may be best placed to maintain information on their community. Weather information is g athered by individuals all over Australia.

The WWW provides facilities for such infomation to be received by organisations but http forms are limited to text. Image information would have to be uuencoded and pasted into a text area to submit an image using standard http browsers. There is an obvio us niche for a program to accept an image and forward it to an httpd server. Organisations tend to have standards for the format of data they collect. Programs at the client end could be used to format data for transmission to WWW servers. Performing this processing on the client side would be particularly valuable if the data is summarised first as less data needs to be transmitted.

A more specialised application would be to use client side processing and the WWW to receive information from automatic remote sensing stations.

Manipulating Information from servers

Remote image processing tends to require the movement of large image files across the network. In many cases the required information may already have been transmitted to the client's machine but reformatting requires that a complete new image is transmit ted to the client. Providing the client with the ability to reprocess the existing data can eliminate this requirement - once clients have obtained the base information they can manipulate it to suit their needs.

The proliferation of image and data formats in GIS often requires data to be manipulated using programs designed specifically for a particular data format. Using traditional methods for client-side data processing would therefore require clients to have m ultiple programs to deal with each GIS format.

Using standards such as Java and the HotJava browser ( http://java.sun.com ) we can provide clients with applets or mini applications tailored to the data we are providing them. These applets are sent to the client along with the data. Once the client has received the applets and data they can perform whatever processing the applets allow without necessarily having to contact the server again.

The HotJava browser can run applets written in the Java language. Java is an interpreted, machine independent language which resembles C++. The language has been designed to make writing malicious programs difficult. The interpreter also validates that pr ograms have been compiled by an authentic Java compiler and is restrictive about class behaviour, type casting and file access.

HotJava is currently only available in alpha form for a limited number of systems and development using it is only just beginning. However it has generated a great amount of interest and shows promise of allowing solutions to many of the limitations of cu rrent WWW technology.

A GIS site in the USA (Argonne National Laboratory - http://www.dis.anl.gov:8001/GIS/is currently using java as an interface. This provides a zoomable map, panning, and information on geographic points (mainl y relevant URLs) and allows entry of relevant URLs along with geographic information taken form the mouse pointer over the map. This system implements 'rubberbanding' to allow clients to zoom an area of the map.

Processing the Clients' Own Data

There are sites that provide processing services on clients' images on the WWW today (eg Imaging Machine - http://www.vrl.com/Imaging/index.html). Typically the client supplies the server with the URL of the image and the operation required and the server mails the client with a URL from which to pick up the processed image. Services offered include making GIFs transparent or interlaced and file format conversions.

Use of client side processing could allow some services to be provided on clients' data on their machines. A program may be downloaded which performs image processing services through the WWW browser when required. The client does not have to store a dedi cated image processing application but can use tools provided by a WWW server when required. The WWW provider may charge for use of such a program.

As new processing services are developed they may be imlemented on the WWW. All users of programs from an official site can rely on using the most up-to-date release of the program. The author has access to statistics on usage and possible feedback.

The World Wide Web has created a surge of activity in computer graphics processing. WWW users are a major new market for image processing services and the place to reach them is on the World Wide Web.

Special Interest Networks and GIS

There is a large community of people involved in providing geographic information on the World Wide Web. to maximise the efficient use of time and resources duplication of services should be avoided.

This requires a communications channel between GIS providers as well as an authentication mechanism to provide users and other GIS providers with some guarantee that information is reliable.

A Special Interest Network of GIS providers could provide these facilities. The Special Interest Network would aim to be the first place clients would look for GIS information. If quality information is available through this network WWW users will use it . Members of the SIN should expect greater recognition by the user community through their participation.

Co-operation through the SIN will allow each participant to continue their individual projects as well as referring to other authoratitive services which relate to their projects. It should provide a forum for sharing expertise and experience, recommendat ions about products and tools, and useful information.

New Standards and Protocols

Presently, there exists a wide range of different GIS packages available on many different computing platforms. Most have their own data storage formats specific to their application, although some formats are emerging as psuedo-standards within the GIS f ield. Even so, the usefulness of a GIS package is limited by the available data for analysis.

In order for a GIS SIN to be successful, standards for geographic data formats need to be adopted by the entire GIS community. This would make the exchange of data less troublesome and more efficient as no conversion would need to be performed on the data before use.

The extension of the HTML language is currently underway with the development of the HTML 3.0 specification. Although the HTML 3.0 specification is still under development, it seems that it will include extensions to the range of graphic element input typ es. This is a major plus for interactive geographic services as single point input can be very limiting. The ability to select sets of points, or a region from an image will greatly increase the potential power of on-line geographic services.

For more information on the HTML 3.0 specification, see http://www-uk.hpl.hp.com/people/dsr/html3/CoverPage.html

Conclusions

The World Wide Web has the potential to greatly enhance many aspects of GIS communications, and applications. Already a vast number of on-line geographic services exist, and it is expected that these services will continue to grow and become more powerful , flexible, and functional as Web standards and technology progress. The ability to customize the client browser, and process input at the client end of the connection will increase the effectiveness of user interaction, as well as reducing the bandwidth requirements of a service - only essential communications need take place. New standards and the adoption of a community networking approach, such as the SIN model, will allow for greater cooperation and interaction between members of the global GIS commu nity, including exchange of data, ideas, and resources.

In all, the Web has much to offer in the area of Geographic Information Systems, and with the ongoing evolution of Web standards and technology, promises even more in the near future.

Acknowledgements

An Australian Key Centre for Land Information Studies (AKCLIS) grant was obtained to develop the use of the World Wide Web for networking Geographic Information Systems at Charles Sturt University in conjuction with the Tasmanian Parks and Wildlife Servic e.

References

[ARGO95]
Argonne National Laboratory (1995). Dynamic Geographical Information System. http://www.dis.anl.gov:8001/GIS/
[BOUT95]
Boutell, T. (1995). gd 1.2 - GIF graphics library. http://siva.cshl.org/gd/gd.html
[GHOS95]
Ghostscript, Ghostview & GSview. http://www.cs.wisc.edu/~ghost/index.html
[GREE95a]
Green, D.G. (1995). A Web of SINs - the nature and organization of Special Interest Networks. http://life.csu.edu.au/gis/finland/sin/index.htm
[GREE95b]
Green, D.G., Steinke, A.P., Peters, D.J. (1995). On-line Environmental and Geographic Information Systems. http://life.csu.edu.au/gis/finland/finpaper.html
[JAVA95]
Hot Java. http://java.sun.com
[NCSA95a]
NCSA httpd server side includes. http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html
[NCSA95b]
The Common Gateway Interface. http://hoohoo.ncsa.uiuc.edu/cgi/overview.html
[NCSA95c]
NCSA HTTPd Development Team (1995). NCSA httpd server side includes. http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html
[NCSA95d]
A Beginner's Guide to HTML. http://www.ncsa.uiuc.edu/General/Internet/WWW/HTMLPrimer.html
[NCSA95e]
A Beginner's Guide to URLs. http://www.ncsa.uiuc.edu/demoweb/url-primer.html
[NETS95]
Persistent Client State HTTP Cookies. http://home.netscape.com/newsref/std/cookie_spec.html
[RAGG95]
Raggett, D. (1995). Hypertwxt Markup Language Specification Version 3.0. http://www-uk.hpl.hp.com/people/dsr/html3/CoverPage.html
[STAR95]
CGI and PERL. http://WWW.Stars.com/Tutorial/CGI/Perl/
[STEI95a]
Steinke, A.P. (1995). Interactive World Map of Cities. http://life.csu.edu.au/~asteinke/gis
[STEI95b]
Steinke, A.P. (1995). World Map Maker. http://life.csu.edu.au/cgi-bin/gis/Map
[VISI95]
Visioneering. Welcome to the Imaging Machine. http://www.vrl.com/Imaging/index.html
[WESS95]
Wessel, P., and Smith, W.H.F. (1995). The Generic Mapping Tools - GMT. http://www.soest.hawaii.edu/soest/gmt.html
[W3C95a]
Hypertext Transfer Protocol. http://www.w3.org/hypertext/WWW/Protocols/Overview.html
[W3C95b]
Object MetaInformation. http://www.w3.org/hypertext/WWW/Protocols/HTTP/Object_Headers.html
[Return to Table of Contents]
COPYRIGHT © 1995 by AUUG95 and APWWW95 Charles Sturt University. ALL RIGHTS RESERVED. ISBN 1 875781 43 9