Interop97 - Fonseca and Davis

Using the Internet to Access Geographic Information: An OPEN GIS interface prototype

Frederico Torres Fonseca
Clodoveu Augusto Davis Jr.
PRODABEL - Empresa de Informática e Informação
do Município de Belo Horizonte S.A.
Av. Presidente Carlos Luz, 1275
31230-000 - Belo Horizonte - MG - Brazil
Phone: +55(31)984.5156 - FAX: +55(31)224.0022
E-mail: fred@pbh.gov.br and clodoveu@pbh.gov.br

SUMMARY

Interfaces to access geographic data can be designed in a number of ways. When the design takes into consideration interoperability concerns, the software's architecture becomes one of the main issues. In the interfaces that intend to be interoperable, the design often includes a module that is responsible for the interaction with the user, and another which implements the connection to the GIS. The distribution of tasks between the user interface and the connection module will be discussed here. The design of an interface that allows the user to gain access to geographic data stored in one or more GIS, using the Internet as a communications medium, will be proposed as an alternative.

The architecture of this proposed solution is presented, along with its weak and strong points. In this approach, direct manipulation and menu selection tools are used to build the user interface. The connection to the GIS has been implemented to reach a single source of geographic information, but given the interoperability features included in the interface's design, the potential to access several different GIS is assured. The use of Java, a multiplatform, object-oriented language, and its potential to build geographic interfaces based on an object model, is also discussed.

OBJECTIVES

This project has started with the objective of creating "middleware" to allow an user to gain access to geographic data from several different sources, using a simple object-based model. The intention was to provide the widest possible range of users with easy and inexpensive access to public GIS data. The initial concept called for the development of an interface between the user and the GIS. Initially, this interface would only provide basic data access, and should evolve in the future to support the definition and implementation of more specialized services. However, the ability to connect simultaneously to different GIS platforms has been considered important to the success of the project.

As a development platform, the Java language has been chosen. Java includes features that provide for easy client-server computing, Internet connections and standard database access, in a multiplatform, object-oriented environment. Java applets can be made available through the Internet (or any Intranet), cutting down on software maintenance and distribution costs. The Internet also provides an excellent medium for distributed applications, as required by the project's objectives.

ARCHITECTURE

This project works with the concept of geographic objects, that can be extracted from a geographic database to be presented to the user. The modeling of the objects are based on the OPENGIS Geodata Model, although it will not be completely implemented. Geographic objects are modeled as instances of classes derived from a generic class, called GeoObject. This design suggests some basic derived classes, such as Point, Line and Polygon, but new object classes (such as Raster or DTM) can be derived from GeoObject in order to provide support for more specialized data models, as implemented by existing GISes.

The interface has two main modules: the manipulator and the extractor. The manipulator is responsible for the user interaction. Through it, the user can select information that he wishes to see on the screen. The manipulator translates user interaction into requests to be fulfilled by the extractor. The extractor works (1) receiving manipulator requests, (2) connecting to the GIS that manages the desired information, formulating queries and retrieving results, and (3) returning the retrieved results as objects to the manipulator. In turn, the manipulator will handle data visualization issues. Observe that the manipulator module, since it deals only with generic GeoObjects, can be developed to be independent from the GIS that manages the geographic database. Only the extractor module needs to be developed considering specific aspects of the host GIS architecture, since it is the responsible for actually retrieving information from the GIS. Since the manipulator can always be left unchanged, the user gets a stable interface, independent from the actual source of geographic data. This source can also be changed, without the knowledge of the user; that is, the user does not need to know from which GIS the data are coming from.

BALANCING TASKS

As proposed, the extractor module needs to include code that reflects specific knowledge about how to query an existing geographic database, and how to retrieve results. Naturally, this implementation will vary, according to which GIS is used to manage the data. In order to develop interfacing capabilities for a specific GIS product, a class needs to be derived from the Extractor class, and it must include the ability to supply the manipulator with objects in any class derived from GeoObject. Classes derived from GeoObject will inherit GeoObject's basic class properties and methods, which will be used by the manipulator. Therefore, the manipulator code can disregard such details by using encapsulation.

In order for this to work properly, there has to be a clear separation of tasks between the manipulator and the extractor. Also, interfacing software that intends to connect to several GIS can never take on functions that are GIS-specific. The degree of specialization of GIS software in their primary functions, such as spatial data retrieval and analysis, could never be achieved by a simple interfacing program. Even considering that our communications medium, the Internet, is frequently congested, it is fundamentally important to avoid making the interfacing code responsible for any geographic functions. This can mean the loss of some performance, but the loss could be compensated by the possibility of keeping the user interface stable and unchanging, GIS-independent. The use of caching in the client machine, as allowed by Java, can also alleviate performance problems. The use of this feature, however, is optional in the implemented architecture, and depends on the implementation of the extractor module.

CONCLUSION

Results achieved with the initial implementation of the above described interface indicate that the proposed architecture, even though it carries the burden of translating data between the GIS and the user interface, has benefits that overcome its limitations. Among the main benefits, we can mention the adherence to open systems concepts, the concentration on the basic functional roles of each component (manipulator, extractor and GIS), and the possibility to progressively incorporate new services and functions. Furthermore, the strong coupling between the extractor and the GIS brings the opportunity for optimization and performance gains, due to specific knowledge of the GIS internal routines, while respecting the basic interoperability rules through the weak coupling between the manipulator and the extrator.

REFERENCES

Bruns, T., Egenhofer, M.J., "WEB-Top Interfaces for GIS Map Algebra", http://www.cs.umd.edu/projects/hcil/People/tbruns/gisjournal/webalgebra.html, 1997.

Buehler, K., Mckee, L., editors, "The Open GIS Guide", http://www.opengis.org/guide, Open Gis Consortium, Inc., 1996.

Kuhn, Werner and Willauer, Langley and Mark , David M. and Frank, Andrew U.(Eds), "User Interfaces for Geographic Information Systems: Discussions at the Specialist Meeting", National Center for Geographic Information and Analysis, 1992

Oliveira, J.L., Medeiros, C.B., "User Interface Issues in Geographic Information Systems", Relatório Técnico IC-96-06, DCC, UNICAMP, 1996.

Voisard, A., Designing and Integrating User Interfaces of Geographic Database Applications, in Proceedings of 1994 ACM Workshop on Advanced Visual Interfaces, 1994.

Voisard, A., Mapgets: A Tool for Visualizing and Querying Geographic Informatio, in Journal of Visual Languages and computing, 1995.