 |
 |
| View across Lake Como |
Marc Van Liedekerke, Arwyn Jones
Abstract
The Regione Lombardia are currently investigating ways to develop
a regional information system for managing water resources. A prominent
aspect of this information system is the need to provide GIS functions
and products over a distributed network to a range of users (e.g. decision
makers, technical staff and the public). The paper describes a number of
products that allow such actions to be undertaken. These include a low-cost
in-house development for ArcInfo and the various products that are available
from Esri (SDE, ArcView and MapObjects Internet Map Servers).
The authorities of the northern Italian region of Lombardy (Regione Lombardia) are currently investigating ways to develop a regional information system for the acquisition, processing, archiving and retrieval of surface and ground water data and associated information. An initial phase studied the existing information and work flow concerned with the process and effectiveness of acquiring, storing and disseminating water data within the region. Existing data management practices could be enhanced by the introduction of current information technologies. Since most of the data within this information management process are geo-referenced and many operations with the data are geo-related, a GIS is seen as one of the key components.
However, GIS functionality is mainly used by highly trained and technical personnel, all GIS use is virtually concentrated in one office, and its use is not integrated elegantly with the current work and information flow. Since it is expected that any new system will dictate a distributed approach, the WWW client/server architecture is being considered as a suitable development environment. A prototype information system in which the WWW clients will be used to insert or upload new data, retrieve and display data in a variety of ways is being proposed. Data and information will be stored, processed and disseminated by various dedicated servers (WWW, ArcInfo, databases), in a format appropriate for the clients.
The prototype plans to use existing GIS applications in combination with a RDBMS to store information centrally. Since the WWW is used as the interface environment, it is planned to integrate GIS functionality into the prototype by exploiting the possibilities offered by recent developments in technologies to provide GIS functionality via the Web. Possible candidates include the Joint Research Centre's WWW-ArcInfo Gateway and Esri's emerging Internet Map Server technology.
It is foreseen that these technologies will provide the building blocks on which to construct a system that brings important and timely data to the expected end users in an interactive graphical manner This paper briefly outlines the proposed prototype system and addresses the merits and disadvantages of the possible solutions to provide effective GIS functionality through the WWW.
|
|
| View across Lake Como |
The region of Lombardy (Lombardia in Italian) is one of the most complex areas within Europe in terms of the management and use of water resources. Centered around the city of Milan, the region contains vast grain growing plains (mostly rice), sub-Alpine lakes (Maggiore, Como, Garda) which drain to the Po river and snow covered peaks. The use of water is intensive. The lakes are used to provide drinking water, recreation, transport (many ferries), irrigation and supply industrial needs. The rivers are used in much the same way but have additional problems since as a result of the Mediterranean type of climate, the flows can be erratic which results in problems in water quantity and quality. It should be added that the area is one of Italy's main wine producing areas. The task of managing the water resources for all these diverse uses falls to the regional council or the Regione Lombardia.
A serious first step in the support of this task has been the design and initial development of the computerised version of the "Catasto delle Acque" or Register of Water Resources. The aim of this being a repository of all water related data for the region. Since all data are geo-related, it was envisaged to integrate this database with the GIS capabilities of the Region's Cartographic Offices. For various reasons, informatic developments within the organisation have not proceeded to the level that was expected at the outset. It was realised that the database system realised at the end of the 1980's was technologically outdated and that a serious effort was needed to bring it to a level which is in tune with the latest technological possibilities for information integration.
The Regional Water Office, has become interested in developing an advanced prototype information system to manage, acquire, process, archive and retrieve surface and ground water data and associated information. An overriding objective of this information system is that there should be a more effective management of the various inter-connected elements that relate to water use. These elements include topics such as wells, the meteorological situation, industrial and household waste, water quality and quantity in the lakes, rivers, and acquifers. The prototype being tested will also address the human work flow components of the system whereby attempts will be made to improve data entry and dissemination.
During a first phase, four tasks will be undertaken :
In a second phase, the prototype system will be developed, demonstrating
the concepts within the design and incorporating a subset of the full functionality
as specified by the first phase.
Because the of the distributed nature of the organisations and personnel involved in this exercise (a series of local, regional and main offices, displaced departments, dissemination to the public, decision makers divorced from the technical level), it is proposed that the system has to be technically based on a client/server architecture. In this manner the clients will be used to insert or upload new data, retrieve data in a variety of ways and allow some of the system administration functions. Data and information will be stored, processed and disseminated by various dedicated servers in a format appropriate for the clients. This makes the World Wide Web (WWW or Web), by virtue of its client/server basis, user-friendly across-platform interface and multimedia capabilities, an obvious medium to use as a binding agent or "Glue" for all the technologies being used by the prototype.
As the key capabilities of the prototype information system range from the ability to generate and transfer maps, analyse and process spatially organised data, to undertaking querying and data retrieval, the integration of WWW and GIS technologies is of the utmost importance. One could view the relationship between GIS and the WWW in many different ways.
In the broader sense, this view could include high level access to GIS generated data and meta-data (catalogues), using the WWW as a user tool for formulating requests for such data and using WWW severs for generating responses to such requests. Both the request formulating environment and returned responses could contain spatial components such as maps. This view would not necessarily require the involvement of a GIS engine.
In a narrower sense, one could only consider those cases where a GIS computation component is actively involved as part of the client-request/server-response mechanism (i.e. where a user would have on its desktop a WWW embedded facility which provides GIS functionality to local or remote datasets). 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.
There are many reasons why it could be worthwhile to integrate a GIS with the WWW environment :
The remainder of this paper looks at various possibilities to provide GIS capability to distributed locations through the WWW.
This section outlines the various considerations that went into the design of a WWW-ARC Gateway which has been developed at the European Commissions Joint Research Centre. The original idea of the Web of just linking hypermedia documents through links has been extended by various client/server implementations to include to possibility to access remotely any application.
At the client side, this has been achieved by offering a developer the possibility to create a FORMS based interface, featuring all kinds of buttons and menus. Through simple mouse operations such as pointing and clicking, the user submits a request to a customised program on a remote server. One of the most appealing elements to exploit is the possibility to include "sensitive" maps within a document: a developer can declare some areas within a picture as 'sensitive' ; by clicking with a mouse on such an area, an action, specific for that area will be undertaken at the server side.
At the server side, the CGI-BIN interface takes care of the incoming requests from FORMS or sensitive maps and then routes them to a suitable program (or scripts) provided by the developer. For instance, a developer could create a FORMS interface that allows a user to specify a database query. On submission of the query to the server, CGI-BIN routes the request to a custom program that parses the request and constructs a corresponding query for a database ; the result of the query to the database is then processed to create a plain text or a new HTML document or even a sophisticated plot of the retrieved data, which is sent back to the requesting client.
Such a mechanism which allows access to an application to a server, is called a GATEWAY. In the case of ArcInfo Gateway, a user specifies a GIS task to be undertaken from the HTML interface. A CGI-BIN script is then evoked that launches ARC with a suitable AML and all the arguments required by that AML to undertake the necessary operation. The result of the processing undertaken by ArcInfo (text or a map) is then converted by a CGI-BIN script to a format that can be viewed by the WWW browser. The conceptual design of the WWW-ARC Gateway is given below.
The overall design goal of the system was the provision of a mechanism for providing a user with the means to undertake standard GIS operations on a remote server via the WWW. To attain this goal, four sub-problems had to be solved:
a) the identification of the functionality desired (this would become apparent from the users of the system);
b) the design of the user interface to interact with the GIS applications (a HTML development issue);
c) the adaptation of the ArcInfo GIS based applications to run in the Gateway environment;
d) the development of controlling CGI scripts.
Each of these issues will be covered in further detail in the following sections.
The functionalities being offered to the user of the Gateway can be placed into two categories:
a) selection and retrieval of specific feature;
b) provision of a set of tools to examine the retrieved information.
Each of these functions can be specified as a series of design goals.
Design Goal 1: The interface to Gateway should allow the user to select which of the various indicators or textual information is required.
Design Goal 2: The Gateway must be able publish map-based indicators and text based information.
Design Goal 3: The Gateway must allow the user to specify a number of different variables in order to select the indicator and element of interest (e.g. water quality data for Spain from 1986).
Design Goal 4: The user should be able to view legends and keys that explain any symbols used on the map based indicators.
In order to allow the user of the Gateway to extract as much information as possible from the retrieved information, a series of tools must be developed that permit the user to interactively add or remove ancillary information and to query further the information that is presented.
Design Goal 5: The user should be able to select a number of background cartographic layers (e.g. coastline, country boundaries, major lakes, major rivers, all rivers, location of monitoring stations, etc.) with a range of styles and colours.
Design Goal 6: The user should be able to specify a suitable scale for displaying the mapped information (i.e. by using a zoom in / zoom out / pan function).
Design Goal 7: The user should be able to interrogate the underlying data or retrieve additional information by clicking the current displayed map with a mouse. The results of this operation, normally text based, should be displayed in an appropriate manner.
Design Goal 8: The user should be able to return easily to an initial or starting situation (i.e. a 1:1 view).
Design Goal 8: The user should be able to run "stand-alone"
models from the Gateway.
Design Goal 10: The user should be able to access online help facility.
WWW pages are needed to provide the basis of the user interface to the Gateway. These pages served three functions:
a) to provide the user with information (e.g. background to the project, information on sustainable development, links to other resources);
b) to allow the user to select a relevant application area;
c) the interface to the Gateway by allowing the user to make requests and to provide a mechanism for displaying the specified information.
The first two functions can be satisfied with standard HTML tags and should be accessible from any WWW browser. To satisfy all the design criteria, the interface to the Gateway requires some enhancements over HTML 2.0 (e.g. borderless frames, control over user parameters, etc.). These enhancements can be provided by using JavaScript and the additional functionality of the target browser (Navigator 3.0).
Above all, the WWW pages had to be clear, easy to follow and satisfy all the design goals specified above. A key consideration was that the interaction between the Web user and the GIS gateway system must be handled through a single HTML page. The user had to be able to interact with a system using a set of images, buttons and tools for receiving feedback on his actions.
To test the functionality of the Gateway a series of GIS developments were adapted specifically for the Gateway. A number of available ArcInfo datasets and AML scripts had to be changed so that they could serve the Gateway developed CGI scripts. An example of the use of the Gateway is presented below which shows an application dedicated to providing information on indicators of European Water Resources and Quality.
Over the last few months, Esri has introduced a series of solutions for serving interactive digital maps and related data via the WWW. It should be stressed that the following observations are made on our observations of the literature supporting the following products. The comments are part of our on-going deliberations on the search for a suitable solution. Comprehensive information should be sought from Esri direct.
The Spatial Database Engine (SDE) is a high performance, object-based spatial data access engine implemented in several commercial relational database management systems (RDBMSs) using open standards and client/server architecture. SDE provides powerful tools that can be used for simple or complex data analysis on very large spatial databases. Software engineers can also use SDE to develop specific applications that provide access and manipulation capabilities for virtually any type of spatial data.
The particular strength of SDE is its ability to manage, and quickly access and retrieve, the very high numbers of spatial features that are encountered in large "industrial" databases (e.g. road information, land parcel records, customer locations, etc.). The system is designed to support tens or hundreds of clients and can undertake quite complex spatial and geometric analysis. Clients to SDE include Esri products such as ArcInfo, ArcView 3.0 and MapObjects or a "standard" development language such as C, C++ or Visual Basic.
The main disadvantages of using SDE to serve maps over the Web include the need to acquire additional resources to implement, manage and develop an SDE operational site. These additional resources include the human element (another software environment to learn) and the financial cost of purchasing and running the system Additionally, for each SDE application there has to be a process of developing a user interface. Another drawback to the use of SDE is that it is designed to operate on top of large commercial or industrially operated relational database management systems (RDBMS) such as Oracle, INFORMIX and SYBASE. This computing architecture may not be suitable or available for all users.
With the ArcView Internet Map Server extension, ArcView can be used to easily put mapping and GIS applications on the Internet. ArcView includes a built-in setup wizard and ready-to-use Java applet to help users publish their data quickly. Interactive maps can be created from a number of different types of spatial data (e.g. shapefiles, coverages, SDE layers, DXF) and a variety of graphic images that can be supported by ArcView. ArcView Internet Map Server works with Netscape Server, Microsoft Internet Information Server, and other server products that support NSAPI/ISAPI Web server extensions.
Although attractive to use because of its simplicity, a number of drawbacks for the use of this solution are the need to use a Java supported browser and the requirement of a Netscape or Microsoft server. In addition to fully exploit the capabilities of this system, applications must be developed using the Avenue scripting language. This means that some know how must exist or be acquired before dedicated applications can be released. The planned release date (mid '97) has not yet given us an opportunity to test the system.
Designed for Windows developers, MapObjects Internet Map Server extends the power of the MapObjects application to provide maps over the Internet. Applications built with the MapObjects Internet Map Server extension can access spatial data formats supported by MapObjects such as shapefiles, coverages, SDE layers, and graphic images. In addition, MapObjects Internet Map Server includes a Web server extension that works with Netscape Server, Microsoft Internet Information Server, and other server products that support NSAPI/ISAPI Web server extensions. The Web server extension provides a unique framework to manage requests to provide fast and efficient map serving capability.
The major drawback of this tool is the limited operating environment of MapObjects (i.e. only for Windows 95 or NT 3.5 platforms). In addition, application developers must be familiar with the MapObjects scripting language. This is yet another scripting environment to learn.
For the Esri Internet Map Servers, the overall merits include easy and effective procedures to provide GIS functions over the Web. Some disadvantages that may have to be looked out for include possible hardware and software limitations (e.g. possible conflicts may arise by the need to be NSAPI/ISAPI compliant), Java browsers (some organisations do not permit Java enabled browsers), unsuitable operating system (e.g. MapObjects on NT platforms only).
While very impressive in its technical capabilities, SDE demands large industrial database in order to be effective and cost- efficient. These conditions may not be suitable for small or medium-scale sites. An additional point to note is that a different development environment exists for each system (e.g. AML for ArcInfo, Avenue for ArcView, etc.). Finally, while ArcInfo is still the main spatial analysis engine for a large number of organisations, extra elements must be purchased in order to obtain GIS functionality via the Web.
The JRC developed WWW-ARC Gateway can be seen as a user-friendly, low-cost, basic technology approach which is relatively easy to implement by anyone who has a basic understanding of the WWW working environment. An important point to note is that the Gateway can utilise existing AML development with minimal adaptation. In the tests and usage of the Gateway, acceptable response times between the query being submitted and a result being returned were observed when operating the system between Italy and Spain (approx. 40 secs).
While ArcInfo adapts itself well to the environment of the Gateway development, potential users should be aware of certain key limitations. There is a need to customise the user interface (i.e. the HTML pages) for all the functionality that will be provided to the user. In many instances this means having to re-invent standard ArcView and ArcInfo functions that are operable from the Web browser (e.g. pan / zoom/ identify). The problem of HTTP being a stateless protocol required elaborate solutions for session handling. The problem with HTML sensitive maps handling only single points for map based spatial user specification could be solved using multiple pages or a Java Applet.
The approach of delivering interactive maps on the fly to an end user through the WWW integrated with a GIS and an RDBMS is not new and has been demonstrated before (e.g. in previous Esri user conferences). What is novel however is that in this exercise an industrial strength product is used to support this process and that it is integrated with the work and information flow within a day-to-day operational environment.
The AML developments for the European Water Resources Application within the JRC WWW-GIS Gateway were developed by TAO of Barcelona under contract to DG XIII of the European Commission.
Arwyn Jones // Marc Van Liedekerke
European Commission
Joint Research Centre
Environment Institute
21020 Ispra (VA)
Italy
Telephone: +39 - 332 78162 // +39 - 332 785179
Fax: +39 - 332 789256
Email: arwyn.jones@jrc.it // vanliede@ei.jrc.it