DATA INDEPENDENCE AND GEOSPATIAL WEB SERVICES

The importance of data independence in a database management system is well recognized in the database community. Data independence means database can be changed structurally without affecting programs processing the data. The concept of Data independence can play a very useful role in the development of Geospatial Web Service architectures. We have created a prototype Web Service platform on top of Geographic Resources Analysis Support System (GRASS) GIS based on the concept of data independence. The paper presents the general architecture used in developing the Web Services. This architecture consists of several layers of services. The interfaces of services at each layer are independent of the implementation of the lower level services. The geospatial modeler, who is also the developer of services at the top most layers, is immune from having to learn the specifics of any one particular software package or service. The services at the higher levels can be cataloged and made discoverable for use in other higher level models. Some of the issues that we encountered - granularity of services, statelessness of services and interoperability between services- are also discussed.

Layered Architecture for Geospatial Web Service development

Fig. 1. Layered Architecture for Web Service Design

One of the important considerations in the design of the architecture is that the scientist or model developer should be immune to the details of the underlying implementation of the software or services. The model developer should be able to view the service interfaces available at the conceptual level without having to know much about the details of the implementation. At the same time, the flexibility and power of the underlying software should not be restricted when incorporated into Web services. In other words, a user of the services should be able to achieve all the functionality that can be achieved by using the software in a standalone manner. This idea of conceptual data independence has played a crucial role in the design and development of relational databases. Having a layered architecture for geospatial Web service development can play a similar role. At each layer are services composed by chaining services at the lower level or same level. The higher level services can be created in such a way that they completely hide specifics of the software and services used in the lower level. Figure 1 shows the layered architecture used in the development of Web Services on top of GRASS GIS. The reader is referred to [7] for more details about GRASS GIS. GRASS GIS is at layer 0 in the architecture.

Layer 1

Layer 1 consists of “atomic” Web services which are directly based on the GRASS commands. Each and every service interface emulates a GRASS command. Some simple mapping rules, depending on the pattern of the the command line, were used when going from the command line interface to the Web service interface.

Most of the services in this layer are not self-contained, though they are independent of each other. But, in reality, Web services are supposed to be discrete units of code which are independent as well as self-contained. They are usually only loosely coupled with each other. In a later section , we will argue that services on top of session based command line software like GRASS are more naturally designed as Grid services which have state. The parameters used in the above GRASS services- DATABASE, LOCATION and MAPSET can be thought of as representing state information which is stored on client side and passed during each and every call to the service. We will see that in the next layer of the stack in Figure 1, we can chain the atomic services, which can be either stateful or stateless, into higher level Web services which are completely independent and self-contained. Specifics of GRASS can be completely hidden from the users of the Web services at this layer, unlike services in the present layer which requires user level knowledge of GRASS.

Layer 2

In this layer, several services from the layer below are chained together to create new services. These higher level services are similar to GRASS scripts that are composed of several GRASS commands. The interfaces to these services are such that they can be looked at the conceptual level by the model developer, without regard to the implementation details. They follow directly from the definition of the parameter being modeled. This will be illustrated with a simple example. A service has been developed to calculate Normalized Difference Vegetation Index (NDVI) values from two raster data files─ Near Infra Red (NIR) and Red Images. The inputs to this service are two raster images ─ the first containing reflectance values from the visible range in HDF-EOS format and the second containing reflectance values from the near infrared range also in HDF-EOS format. The two images are assumed to have the same projection, resolution and bounds. The output from this service is the image containing NDVI values in Portable Network Graphics(PNG) format. All the services used for creating this service- r_in_gdal, r_mapcalc and r_out_png are atomic services in Layer 1.

Layer 3

In this layer, services developed in Layer 2 are chained with other services to create even higher level services. The Layer 3 services can also consist of other Web services. The other Web services could be Web services based on other geospatial software. The OGC data services like WCS or WFS implementations could be the data sources for the workflows at this layer. Now we will look at an example of a scientific workflow which is essentially a service at this layer. A simple model for calculating landslide susceptibility based on a few parameters like slope, aspect, NDVI, etc has been implemented as a Layer 3 service. Figure 2 shows the model schematically.

Fig. 2. A simple Landslide Susceptibility Model

The services developed in Layer 2 are chained with other services to create a workflow which represents the landslide model. In the image above, landcover is obtained from a Web Image Classification Service(WICS), which is a non-GRASS service. Each of the components in the model- NDVI, slope, aspect, landcover and landslide susceptibility are composed as independent Web services. These components form level 2 services. They are chained together to create a workflow which represents a landslide model. While one can create the model from atomic services itself, but to do that requires knowing the specifics of GRASS GIS and working at a lower level of abstraction. Languages for creating work-flows like BPEL can be used for creating the workflows. We used BPEL for creating workflows.

Conclusion

This paper has presented layered architecture for geospatial Web service development over GRASS GIS. However, similar architecture may be applicable when converting other geospatial software to Web services. Each geospatial software package has its own set of interfaces for users to work with. Usually these interfaces are designed for optimal functioning of the software. Bypassing these interfaces to develop coarse-grained services from the software may severely restrict the Web service developer from using the full capabilities of the underlying software. But on the other hand, a model developer who uses these interfaces directly must learn the specifics of the software. A model developer does not and probably should not think about any specific software when developing a model. Therefore it is better to have multiple layers of users. At one layer is the user who is conversant with the interfaces. She/he can develop higher level interfaces which completely hide the details of the underlying software and are highly reusable across many different models. These service interfaces can be understood at the conceptual level by the model developer. The high level interfaces would be much easier for model developer to use than using implementation dependent low level interfaces. There is much scope for adding new functionality to the system developed so far. GRASS has many interactive commands. It is challenging to convert these commands to Web services. An intimate knowledge of the GRASS API may be required. There does not exist any software which can act as a client to the services developed so far. For the end user to be able to use the services, development of a general purpose, extensible geospatial Web service client is needed.