WTF-GOFC TIE Plan
Abstract
This document describes the construction of a Technology Integration Experiment (TIE) for the WTF-GOFC project. A TIE is meant to be an informal construction consisting of multiple components supplied by multiple organizations, working together to show that a particular set of interfaces works as expected.TIE participants should be prepared to negotiate with each other about how to best fix things that need fixing, and how to best progress towards the goal of the TIE.
WTF-GOFC Evolution
WTF-GOFC is part of a larger concept -- the WGISS Test Environment. It is the first WTF and we are breaking new ground. The purpose of the initial set of WTF-GOFC TIEs is to meet the objectives of the CEOS WGISS Plenary 14 (Kyoto) Demonstration. The TIEs leading up to that demonstration will help us decide what the scope of the demonstration can be and will help inform those who will develop the Kyoto demonstration scenario about the capabilities of the components to be demonstrated.
This document is meant to evolve as the TIEs themselves evolve.
At
the November 2000 WTF-GOFC TT meetings we defined a basic flow as seen
in Figure 1. Raw data from producers would flow to brokers who, in turn,
would process/package the results for end users. The end users should
be able to view the data/results in conjunction with their own local GIS
data.
A concrete example of this would be for fire location data derived from various sources (producers) to be turned into attributed point data by producers or brokers and made available to end users as either point data or served as Web Map Server maps. The end users would be able to use their local GIS viewers to add the fire point data to their GIS views or they would be able to layer their local GIS data on top of fire point maps received as WMS maps.
Metdata for the data and services would be published by the producers and be searched by the brokers on behalf of the users.
In
the longer term, we will provide a richer set of data sources (e.g. MTSAT
for SE Asia) and provide multiple paths to the data (sophisticated users
can either get data from the brokers or directly from the producers.
Starting Point
During the WTF-GOFC TT meeting in Greenbelt, MD we "deconstructed" several systems to determine how we could interface to those systems. The systems we looked at were:
|
System / Provider
|
| TRFIC |
| CCRS Catalog Services |
| ESA Fire Data |
| ESA Multi-Mission Catalog |
| JRC World Fire Web |
| USGS EDC |
| NASA Web GIS Server |
| DIAL |
| SGT Service Registry |
| Space Time Toolkit |
| (The following three still need to be analyzed) |
| MODIS Processing |
| CNES SPOT Vegetation & High Resolution Data Repository |
| NASDA JERS (via TRFIC) |
Table 1. WTF-GOFC Initial Participant List |
The basic architecture of all TIEs is one where the components are loosely coupled and are connected via the Internet. Initially, we will focus on connecting instance of these existing systems to each other via standard interfaces. Doing this should not preclude the ability of users of the systems to continue using them as they currently exist. In fact, the operational concept is to allow users to keep using the systems as originally architected but to expand the range of possible data services available to users of the systems and to expand the range of delivery mechanisms available to providers of data and processed results.
Figure
3 shows the ESA Fire Data system as diagrammed at the WTF-GOFC TT meetings
in Greenbelt. The existing data are available via the httpd interface and
are served up as text files with fire point information in them. These data
are also being made available via an OGC Web Map Server interface and will
shortly become available in GML format via an OGC Web Feature Server. By
making the data available as either rendered maps using the WMS interface
or as GML, ESA will provide others with a richer set of options for using
the fire data products. At the same time, as ESA develops user applications
(i.e. clients) that can use their WMS or WFS interfaces, these clients will
also be able to access maps or data provided by others using the same interfaces.
As
we assemble more of the systems listed in Table 1 into the WTF-GOFC, there
will be more system instances that provide services using the WMT, WFS,
and WCS interfaces. Clients should not have to be hardwired to specific
instances of these services. Therefore, the service instances will have
their associated metadata gathered into one or more Service Registries.
These Service Registries will be built using the OGC Catalog Services specification
or the newer Stateless Catalog interfaces developed under WMT-2.
Eventually,
as we progress, rather than put a lot of new functionality into the end-user
clients, some developers may choose to build server-side application services.
This is really an example of the classice 3-tier model where the data services
are at the bottom tier, the application services are in the middle tier
and the clients are in the top tier. In the context of WMT-2 and subsequent
pilot projects this style of application design has shown its versatility
and utility in the WWW environment. Again, this architecture does not preclude
the continued use of services that don't use the standard interfaces, nor
does it preclude the development of additional components that are tightly
bound to specific services via non-standard interfaces. The goal of the
WTF-GOFC effort is to make it easier to add value to the overall GOFC program,
not to force the development of particular styles of access.Specific TIEs
There will be a WTF-GOFC meeting at ESRIN in Italy on March 12-16, 2001. We want to try to achieve the following TIEs by that time.
|
System / Provider
|
Initial TIE
|
| TRFIC | Add WMS 1.0 capability to existing system |
| CCRS Catalog Services | Has GEO (Z39.50) Interface, need to add additional data sources |
| ESA Fire Data |
Provide WMS 1.0 capability for fire maps. Provide WFS 0.x capability for GML fire data ESA catalog has CIP Interface |
| JRC World Fire Web |
Provide full WMS 1.0 capability for daily world fire maps (approx. 1000 days of data). Provide WMS 1.0 capability for other maps (e.g. Vegetation, Earthquake). |
| USGS EDC |
Provide WMS 1.0 capability for Landsat 7 Browse maps Provide GEO (Z39.50) access to Landsat 7 Catalog |
| NASA Web GIS Server / DIAL |
WMS, WCS Interfaces Catalog (CIP) Interface |
| SGT Service Registry |
Harvest WMS/WFS/WCS capabilities from all available servers and provide search capability |
| Space Time Toolkit |
Provide WMS 1.0 client Provide WMS server |
| MODIS | -- to be defined -- |
| CNES | -- to be defined -- |
| NASDA | -- to be defined -- |
Table 2. WTF-GOFC Initial TIE Plans |
|
What we have to collectively work on, as a group, is to define what we want to achieve in the way of new client access to these WMS instances, how to best catalog the layers and search them, and how to serve and use the GML that would describe the fire point data.