Web services, Geospatial processing models, Workflows, and Virtualization of Geospatial Products Liping Di Laboratory for Advanced Information Technology and Standards (LAITS) George Mason University 6301 Ivy Lane, Suite 620 Greenbelt, MD 20770 ldi@gmu.edu

Introduction Geospatial data are those containing location information. Data collected by instruments are called raw data. In order to make geospatial data useful, processing steps have to be carried out to extract information from the data and then convert to knowledge for applications and decision supports. Standard products Currently most data providers produce some advanced geospatial products, called standard products, in advance with anticipation that such products can meet requirements of most users. Provide the standard products as is to the users—one-size-fits-all approach. Problems with standard-products only approach users’ requirements are so different that a pre-produced product cannot meet the requirements of many different users. Wasting time and resources: some standard products are never fully used.

Virtual Geospatial Products A virtual geospatial product is a geospatial product that not yet exists but the data system know how to create when a user requests such a product. Advantages of products virtualizations Need only to archive low-level data. Significantly reduce the requirements for computing resources. Able to provide more products to users than the non-virtual standard product approach. Currently a lot of data providers are implementing the standard products as virtual products. Standard products on demand—not customizable. Customizable virtual products– expert users definable, user-modifiable, reconfigurable, and interoperable. Ways to implement the product virtualization. Tightly-coupled product pipeline Web service-based loosely coupled approach

Web-service-based Product Virtualizations Allowing expert users to easily define a customized virtual geospatial product and the associated procedure of geospatial processing for generating such a product. Define the product and the procedure conceptually (Geospatial processing model) The models are constructed with the types of processing functions (service type) and input data (data types) instead of their instances. Models are applicable within specific spatial-temporal domain. Advertising the model as a type of geospatial products available at the system. Not specify as data granules Models are instantiated to become a specific workflow only when a user requests the products with specifications provided: Spatial, temporal, format, projection, spatial/temporal resolution etc. Service type and data types in the models are replaced with the service and data instances. Advantages A system with such capability can offer an unlimited number of data- product types, with unlimited number of data granules unique to each users. Flexible, sharable, easily customizable.

Some Terminologies Geo-object – a geospatial product describing geospatial phenomena or events. Why not called datasets??? User geo-object – a geo-object defined and requested by a user. Archive geo-object – a geo-object that exists in a geospatial archive. Geo-object type – abstract of individual geo-objects that share same features (e.g., spatial, temporal, content..). Geospatial process module – an process that produce a geo-object/s through manipulation of input geo-objects. Geospatial service – Geospatial process module implemented in the service environment. Geospatial service type – Abstract of individual geospatial services that provide same type of geospatial process.

Geospatial Processing Model and Geo-Tree Geospatial processing model—Tell conceptually steps to take to generate a geo-object type/s from a set of geo-object types. A geospatial processing model represents the knowledge for generating a specific type of geo-object. Geo-tree – The conceptual/graphic representation of a geospatial processing model. Two types of nodes in a geo-tree: processing node and geo-object node. The processing node is a geospatial service type. The geo-object node contains a geo-object type. By defining geospatial models at abstract level Allow the development of general model that can use for generating unlimited numbers of instances. Make domain experts easier to create models by eliminating the needs to details on product specifications.

Geo-object, Geo-tree, Virtual products, Geospatial Models modeling and virtual data services no service data service User Requested User Obtained archived geo-object user geo-object Geospatial web/Grid services Intermediate geo-object Automated data transformation service(WCS/WFS)

Virtual geo-objects and virtual geo-object type A virtual geo-object is a geo-object that: not exist in a geospatial information system The system knows how to create it on-demand. All metadata items for a virtual geo-object has defined values. It uses the same metadata as the real geo-object (archive geo-object). The only thing different is that the data part does not exist yet. The client/data user will not know the difference between a real and a virtual geo-object. Virtual geo-object type—abstract of virtual geo-objects that share the same features. All geo-object nodes in a geo-tree, except for those nodes for the archive geo-objects, are virtual geo-object types; The root node in a geo-tree is a virtual geo-object type the model can generate.

The Life Cycle of Virtual Products Knowledge Capture phase User query Phase User retrieval phase Geospatial Model Virtual geo-object Logical Workflow Concrete Workflow Workflow execution user geo-object

Knowledge capture: the construction of geospatial models Two catalogs are essential geo-object types service types Save the model in a formal way Use the modified/simplified BEPL to store the geo-tree Keep geo-trees in the geo-tree library Catalog the geo-trees in the geo-object catalog. Two ways to create geospatial models Domain experts create models and share with others. Easy to construct a model through a graphic model construction client. Automatically creation of model. Require the system to have domain knowledge and AI capabilities

Knowledge capture: User Creation of Geospatial Models A user-requested geo-object maybe does not exist both virtually and no virtually. If the user knows the thought process to create the geo-object from lower-level inputs step-by-step (the logical geospatial modeling) With help of a good user interface and the availability of service modules and models/submodels, the user can construct a geospatial model/virtual data product interactively. The system then can produce the virtual data product for the user. The user-created model can be incorporated into the system as a part of the virtual datasets the system can provide. This allows the system to grow capabilities with time. Advantages allows users to obtain the ready-to-use scientific information instead of the raw data, significantly reducing the data traffic between the users and the geospatial Grid. allows users to explore huge resources available at a data Grid and to conduct tasks that they never be able to conduct before.

Knowledge capture: Automatic Creation of Geospatial Model We are studying the approach to automatically create geospatial process models based on user’s description on user-geo-object and produce the user geo-object. In a lot of case, a model used to generate user requested geo-object does not exist and the user is not an expert user knowing how to create a model. The automatic creation will allow the general users to obtain geospatial information and knowledge The steps are as following: Users express their request in nature language (ideally) or in controlled vocabularies. The request is converted to a user geo-object. The user geo-object is abstracted to become a user geo-object type. Deductive method is used to form the geo-tree from the user geo-object type with the help of geospatial ontology. The rests are the same as the other modeling approaches.

Knowledge Capture: From Geo-tree to virtual geo-object The root node of a geo-tree is a virtual geo-object type When user/client requests a geo-object, user will provide a description of the geo-object they want; If the type of the user geo-object matches with virtual geo-object type in a geo-tree, The geo-tree is selected; The root node is instantiated with the descriptions provided by the clients. The root node now becomes a virtual user geo-object. The next step is to determine if the virtual user-geo-object can be materialized on the fly.

User query phase: Logical Instantiation of Geo-Tree Check if a virtual user geo-object can be materialized by instantiating the whole geo-tree. Push the description of the virtual user geo-object down to each node of geo-tree (e.g., spatial coverage, format, etc); Discover instance of service and geo-objects through searching both service instance catalog and geo-object instance catalog; If an archive geo-object is found as the input of a process, then the push down will be stop for the branch of this tree. The logical instantiation will not create an actual workflow, but conceptually, it creates a logical workflow. If a geo-tree can be instantiated logically, the virtual user geo-object can be materialized. A logical ID will be created and return to client to indicate the user-requested geo-object is found in the system. The logical ID will be used by the client/user to request for the geo-object.

User retrieval phase: Physical Instantiation of Geo-Tree When client requests a user geo-object, the geo-object ID will indicate if the user geo-object is virtual. If the geo-object is virtual, the geo-tree associated with the virtual geo-object will be instantiated to create a concrete workflow. A workflow language will be used to encode the workflow. The workflow is executable in a workflow execution engine.

User retrieval phase: Creation of user geo-object The workflow engine will execute the workflow and generate the user geo-object. The user geo-object will be return to user/client. The above mentioned steps reflects two stage processes: User query User retrieve The two stages can also be merged into one stage process that when a user query can meet, the resulted user-object will be pushed back to user automatically without user initiation of the retrieval.

Implementation In GeoBrain User CSW WCS VWCS Register AM Query Geospatial Data InstantiateService WorkflowEngineService WICS WCTS 1 2 LAITS ESG ECHO GSI (gt4.0) Figure 2. Architecture of Virtual Data Implementation CSWQueryM

Geospatial Registries The schema presented here depends strongly on the type matches; Registries have to be created to register Service type; Geo-object type; Service instances; Geo-objects; A registry must be able to Find instance based on search criteria. Search instances based types; Find types by giving an instance Find the association between geo-object type and service type. Metadata standards are needed to describe both type and instances of geo-objects & services. The OGC CSW service in GeoBrain is able to handle this.

Geospatial Metadata Standards We are using ISO 19115 + ISO 19115.2 to describe the geo-objects. ISO 19115 is an international standard for geospatial metadata. ISO 19115.2 is an imagery extension of ISO 19115 to provide more metadata elements for describing geospatial imagery. Not all elements are used for our project. Only mandatory elements + those needed for type matches are used. (about 50 elements). There is no standard for describing algorithms used in geospatial services. It is important to have an accurate description of individual algorithms used for geospatial services in order for users to create geospatial models.

Service Standards Being Used

Service Modules (Instances) The availability of a large amount of service modules is one of the keys for having a powerful service system. We have made GRASS modules available as service modules. GRASS is a public domain GIS and image processing package with about 230 geospatial process modules. We are wrapping the modules with service interfaces (SOAP) and create WSDL description of those services. Those modules are intended to be used both as Grid and as web service modules.

Service Ontology Group service types into hierarchy based on scientific meaning of the services. For example, Landuse classification service type has many subtypes, include IGBP_classification, Olson_classification, etc, Define the relationship between the service types. Each service instance has to declare which service type it belongs. It is essential for model construction, accurate discovery of service instances, automatic/semi-automatic service chaining, and both model and service interoperability. WGISS should take a leading role for establish the ontology

Data Ontology Group data types into hierarchy based on scientific meaning of the data. Define the relationship between data types Each data instance has to declare which data type it belong to. It is essential for model construction, accurate discovery of data instances, automatic/semi-automatic service chaining, model interoperability and match of services with data. WGISS can take a leading role for establish the ontology

Workflow Engine and Instantiation Service A workflow engine, BPELPower, has been developed to fully support BPEL workflow. A Instantiation service has been developed to work with the CSW services for converting logical workflow to physical workflow based on users’ specifications to the requested products.

Demo Landslide susceptibility Search GeoBrain and find no product for landslide susceptibility is available Establish a Landslide susceptibility model based on service types and data types. (Note the model is independent of the availability of the service and data instances. Register the model at GeoBrain CSW as a virtual data product. Search landslide susceptibility product for a specific area again and find the product for the area is available (logical instantiation) Retrieve the data through OGC WCS (Physical instantiation, and workflow execution).