The JGISFrame software framework enables efficient development of GIS-applications that use dynamic (time dependent) data. The framework conforms to a client/server model where the GIS-data is provided by the server and presented by the client. While a thin-client architecture is suited for a large number of users connected via high capacity communication channels, the thick-client approach used in JGISFrame is especially suitable in applications for mobile clients, where narrow bandwidth is the limiting factor and the communications load has to be minimised. The scalability of services, such as customised views for each user, is also easier to address when the user dependent computation is done on the client side.
The JGISFrame is programmed in Java. Its design is based on experience gathered in a number of earlier maritime and logistics GIS projects performed at the VTT Information Technology. Generally accepted design patterns are applied in the architecture of the framework. The JGISFrame provides an abstraction of a GIS product, which consist of GIS objects encapsulating the actual GIS data, and user interface objects implementing the means of presenting that data to the user. A local storage for the GIS objects facilitates efficient retrieval within the framework. Queries to the local storage can be based on time, spatial location, or their combination.
The framework approach for building GIS applications has proved to be very efficient in VTT Information Technologys projects. The iterative and parallel development process of the JGISFrame was also found very promising in developing reusable software.
In our paper we locate the JGISFrame in the GIS domain, describe its
architecture, its main functions, and the experience of applying it in
applications that handle dynamic GIS-data.
The current trend in the GIS applications is towards thin-client systems and applet based solutions [LaGr98, SaTo98]. Related to these trends our approach to mobile GIS applications in VTT Information Technology is quite conservative. The applications are influenced by the conditions that our clients meet in their operational activity. The customers are shipping companies operating in the ice-infested areas of the Baltic sea and the governmental authorities responsible for supporting shipping in those areas. VTT IT also provides logistics solutions for some land transport companies. The available communications capabilities are rather limited, either a narrow-band GSM/NMT connection or an expensive satellite connection can be selected. In either case the amount of transferred data has to be minimised. The thick-client approach reduces the successive requests of the same data by allowing user customised views to be generated on the client side. This reduces the overall data transfer volumes. The JGISFrame targets the need for faster implementation of such systems.
To position JGISFrame correctly in the domain of GIS applications we define a reference architecture for typical client/server GIS applications. There are two types of GIS-data: dynamic and static. Static data consist of fixed information, such as the geographical locations of cities, towns, and villages. Dynamic data is more varied, such as a weather forecast that changes every day for a given geographical region. With static data a stand-alone application with locally stored data is usually adequate for serving the user needs, thus the system architecture for static data services can be rather trivial. With dynamic data, the situation is more complicated because the data has to be updated from time to time. The JGISFrame can be used for storing both dynamic and static geographical data.
In dynamic data applications the communication issues and actions necessary
for keeping the data up to date have to be taken into account. Figure 1 shows
a reference architecture for dynamic GIS-data applications. In the
architecture we have one or more data providers producing dynamic data, a
server dedicated to collecting the data and giving the users access to it, and
finally client software presenting the data for the user. Client software
corresponds to the stand-alone application for static data, but is enhanced by
the ability to load dynamic data during operation and by the removal of
out-dated data. In this architecture much of the complexities in building an
operative GIS-service are abstracted away. In a real world situation some
approaches, such as the definition of delivery formats, selection between pull
or push mechanisms, and the implementation of billing, should be considered in
more detail.
Figure 1: A reference architecture for GIS-applications.
In our reference architecture we assume that a thick-client implementation will be used. This means that most of the logic associated with the customisation and presentation of data are implemented on the client side. This solution provides the user more opportunities for using the data but results in a heavier workload for both the person implementing the client software and the computer running it. Another option is the use of a thin-client solution, where the main body of computation is done in the server. However, this leads to rather fixed data and limits the user's options of customisation.
The JGISFrame is intended for thick-client systems for providing the abstractions needed in storing, retrieving and viewing geographical data, and thus reducing the effort on developing end-user software. In thin-client systems the data is usually reduced to some overlay images and thus the use of the JGISFrame could be overkill in a thin-client.
We can associate a service chain with production, delivery, and use of dynamic data in a GIS-service. A service chain is shown in Figure 2. The chain includes the production, and process of the data, and transactions that occur in passing the data from producers to users. The granularity of the service chain is usually finer than in an architecture model, because various processing of the data inside each architectural component is shown explicitly. It is important to note that every transfer of data is based on a defined format and thus they form a natural interface within and between the architectural components. A meta-data description of the actual data is also included with the data in the service chain. The meta-data helps the user to choose appropriate data and formats. Representation of the meta-data should also adhere to some well-defined format. Such formats can be defined using the Extensible Markup Language (XML) [W3C00] and Resource Description Framework (RDF) [LaSw99]. Figure 2 emphasises the interfaces between architectural components, namely IS and IC. The interfaces inside architectural components can eventually be used for attachment points if data from other sources or external processing are wanted. The figure also shows how the service chain approach can be applied in supporting both thin and thick-clients with the same server. The data is just passed for thick-client in an earlier processing phase.
Figure 2: Service chain for thin and thick-client GIS-service
models.
The JGISFrame is based on fundamental inter-component relationships and means of use that are encapsulated in the framework. The applications based on the framework inherit these predefined properties from the JGISFrame. The inherited components are specialised for the particular application. Components include basic application, user interface and data model parts. Java Generic Library (JGL) [Glas97] components are used on those interfaces that exchange data sets or references to data sets for standardising them.
The Model-View-Controller design pattern [Busc96, p. 125-143] is
used as the guiding line throughout the architecture of the JGISFrame. In the
design pattern the data (Model), views to it (View), and means
of manipulating it (Control) are separated. This approach loosens the
coupling between the components of the framework and thus makes it more
applicable and extendable. Also other design patters are applied. Use of the
patterns has been a corner-stone in implementing the self-extandability
facility of the framework. Lot of the application specific material can be
reused in future projects as it links naturally to the framework. Figure 3
shows a simplification of the M-V-C model and reuse through inheritance and
specialisation approach. All relations between components and their basic
co-operation can be taken for granted in the application and only some
application specific details have to be added to the subclasses. The
Factory Method [Gamm95, p.107-116] pattern is the basis for the
inheritance and specialization approach. The predefined relations among
JGISFrame components can be maintained when subclassing them to application
specific components by overwriting these factory methods in the resulting
subclasses. If this was not done, the specialized classes could only refer to
framework classes, not the specialized subclasses. For example the
Application Control class could only refer to View and
Model classes, not the Application View and Application
Model classes. This can be avoided by defining and using factory methods
as in code example 1.
Figure 3: Simplified example of the inheritance and specialisation
mechanism.
The framework provides an abstraction of discrete point data (location and time for a data item) and its local storage. The abstraction is specialised for the application by subclassing it with some extra attributes (e.g. for wind data presentation on a weather forecast application the wind speed and direction attributes are added to the subclass along the predefined time and location attributes of the superclass). The new data subclasses can be reused in future projects.
The framework contains a local storage facility for GIS data. The storage implementation is replaceable, queries to the default version can be done based on location, time, and data type. Applications with specific storage needs can replace the default implemetation with their own version. The Bridge [Gamm95, p.151-161] design pattern is used in making the storage implementation interchangeable.
JGISFrame applications use an overlay approach. Each layer in the overlay presents some type of GIS data (e.g. in a weather forecast application wind, temperature, weather symbols etc.). The layer controls all data belonging to same data type. Changes to data are reflected for refreshing views to corresponding user interface and application elements using the Observer [Gamm95, p.293-303] pattern.
The JGISFrame can be extended with various application specific tools, and these tools can be reused in future projects. An abstract interface for implementing tools and operations is implemented with the Command [Gamm95, p.233-242] pattern. The undo operation is supported using the Memento [Gamm95, p.283-291] pattern. Basic co-ordinate transformations among world, map, and display co-ordinates belong to the framework. Current version of the software supports Mercator-projection, but other projections can be easily added.
Code example 1: Use of Factory Methods.
The IBPlott project develops an application for monitoring and managing the maritime traffic situation for the Finnish and Swedish ice breaker administration. The JGISFrame has been successfully applied in this project.
ViewIce is an application that was developed for a Finnish shipping company for monitoring ice situation at the sea and optimising ship routes through the ice. Current release version does not use JGISFramework, but the software has been ported to the framework for future development. Future releases will be based on JGISFrame version.
The JGISFrame was used in the European Commision Telematics Programme project PRESTO. The project sought for means to serve multi-modal travellers across the Europe with precision weather forecasts. The framework was used in the implementation of the Nordic Demonstrator for the project. [PRES00]
The DynaTrans project funded partly by TEKES (the National Technology Agency of Finland) is applying JGISFrame and developing it further in land transport logistics domain. The solutions in the project emphasise map based user interface, route optimisations and other graph problems.
The JGISFrame may also be potentially used in the European Comission project Iwicos.
The JGISFrame was implemented in close co-operation with the applying
projects. This approach proved to be very fruitful. The arising problems could
be solved immediately and in a manner that supported all the involved
projects.
The development of the JGISFrame began in 1999 and has been applied since then in four different projects within VTT IT, concerning both research and operational GIS systems. The framework approach has shown much potential.
The JGISFrame implementation relies heavily on best practices and design patterns. This has shown to be very fruitful strategy for implementing a reusable framework. Especially the self-extendability where most of the application specific material becomes part of the framework is very effective.
The framework was developed in close co-operation with the applying projects. Developers of the JGISFrame were involved also in those projects and the framework was applied already during its implementation on them. This iterative development process proved to be very good in building the framework. The solutions to problems that occured were negotiated immediately with the applying developers. Furthermore, these solutions were not limited to the scope of a single project due to the multiproject involvement in the developing group.
Use of framework solutions and reuse can be effectively used to reduce the
time to market, improve the quality of the end product, and concentrate effort
from implementing the basic application logic to providing value added
services to customers.