Anyone involved in building enterprise information systems might reasonably question the feasibility of the Global Earth Observation System of Systems (GEOSS). The scope and complexity are overwhelming: In the highly technical and legacy-heavy domain of Earth observation systems, GEOSS aims to meet information requirements of 80 nations and the European Commission as well as the needs of multiple communities of practice in each of nine vast Societal Benefit Areas (SBAs): Agriculture, Biodiversity, Climate, Disasters, Ecosystems, Energy, Health, Water and Weather. For hundreds of different organizations that provide and/or use geospatial information, GEOSS is supposed to enable comprehensive, coordinated and sustained observation of the Earth and also efficient publication and use of the collected information.

Remarkably, progress has been rapid. Participants in the GEOSS Architecture Implementation Pilot (AIP) have developed and deployed a new development process and they have also deployed working components for the GEOSS Common Infrastructure (GCI) and the broader GEOSS architecture. That is to say, the basic technical foundation of a service-oriented architecture for GEOSS has been established, and it works. The technical foundation has been proven and has undergone continuous improvement in multiple pilot activities based on real-world scenarios and existing national technical resources. And the process for continuous improvement is in place.

— The GEOSS Common Infrastructure (GCI) provides core capabilities that enable GEOSS resources (systems, data and products) to be discovered, understood, and accessed by users and decision-makers. — The GCI includes several registries, a search tool known as “Clearinghouse,” and GEO Web Portals that provide a user interface to search and access all GEOSS resources. — The Initial Operating Capability (IOC) for the GCI was declared open for business in June 2008. It provides a one year evaluation phase for the GEO community to use and deliver feedback.

Within the Group on Earth Observations (GEO) organization and plan, AIP is a core task (GEO Task AR-09-01b) of the GEO Architecture and Data Committee (ADC). Results of the AIP are transitioned to GEO Task AR-09-01a and affecting the evolution of the GCI.

No system of systems as large as GEOSS could be planned and built in a linear fashion, nor could anyone expect it to be built and finished as an unchanging entity, though the technical foundation’s purpose was stated clearly enough in the GEOSS 10-Year Implementation Plan (2005):

“‰Û_ GEOSS will depend on data and information providers accepting and implementing a set of interoperability arrangements, including technical specifications for collecting, processing, storing, and disseminating shared data, metadata, and products.” (Section 5.3)

The GEOSS architecture was necessarily designed to evolve so it would meet changing needs and take advantage of rapidly evolving information technologies. The architecture, the delivered systems, and the stakeholders must all co-evolve. Thus the Architecture and Data Committee undertook to develop a special process to facilitate this co-evolution.

The AIP process provides a structure for experimenting with prototypes that are adapted to user needs, while simultaneously capturing, increasing and sharing knowledge about GEOSS. Each phase of AIP involves extensive prototyping, testing, documentation and demonstration of interoperability arrangements. AIP-2, which was completed in October 2009, established “operational, research and technical exemplars” in six scenarios representing four SBAs:

— Health SBA: Air Quality & Health: Smoke Event: AIP-2 participants focused on air quality with a scenario entitled, “Southern California Smoke” which describes how air quality event managers would use data available through GEOSS to predict and analyze the effect of smoke plumes on air.

— Biodiversity SBA: Pika Distribution — GEOSS was used to predict how the distribution of Pika will change with climate change in the Great Basin of North America.

Major Milestones and Schedule of AIP-2 ‰Û¢ AIP-2 CFP announced by GEO Secretariat 30 June 2008 ‰Û¢ CFP Responses requested to support Kickoff Workshop 1 September 2008 ‰Û¢ Kickoff Workshop at NCAR, Boulder Colorado, USA. 25-26 September 2008 ‰Û¢ Interim Design Review, Barcelona, Spain December 2008 ‰Û¢ Scenarios and Use Cases defined January 2009 ‰Û¢ Demo Capture Workshop, Stresa, Italy 4-5 May 2009 ‰Û¢ Finalize AIP-2 deliverables September 2009 ‰Û¢ AIP-2 results transition to operations 2nd half of 2009

— Biodiversity SBA: Arctic Food Chain — GEOSS was used to assess the impact of climate change on the species of a simple food chain in the Arctic region.

— Biodiversity SBA: Polar Ecosystems — GEOSS was used to identify the extent and degree of vegetation changes in response to climate change in arctic ecosystems, and in particular, the boreal-tundra ecotone.

— Disaster Management SBA: AIP-2 participants used GEOSS components and standard services to supply forecasts, a stream of satellite and in situ observations, and derived maps integrated with local and regional data sets to support all phases of the disaster cycle. The scenario is applied to flooding disasters caused by tropical storms, hurricanes, cyclones, and tsunamis in particular, but can be easily re-cast to cover other disaster types such as earthquakes, wildfires, landslides, volcanoes, tornadoes, and many more.

— Energy SBA: Renewable Energy: AIP-2 participants developed an end-to-end scenario between a data provider on the one hand and a consulting company looking for the best place to site a solar power plant on the other hand. Both benefit from GEOSS as a centralized point of access. The needs of the data providers looking for an efficient dissemination of databases are expressed.

These scenarios provided a structure for extensive prototyping, testing, documentation and demonstration.

As noted in the ‰ÛÏAIP-2 Summary Engineering Report‰Û, the process has been informed by the approach of Leonardo da Vinci:

‰ÛÏFirst I shall do some experiments before I proceed farther, because my intention is to cite experience first and then with reasoning show why such experience is bound to operate in such a way.‰Û

The AIP-2 Floods Disaster Response Scenario The GEOSS AIP-2 Disaster Management Scenario was one of the six AIP-2 scenarios that describe the integration and utilization of GEOSS standard components and services. In this case, the goal was to supply forecasts, a stream of satellite and in-situ observations, and derived maps integrated with local and regional data sets to support all phases of the disaster cycle. The scenario is applied to flooding disasters caused by tropical storms, hurricanes, cyclones, and tsunamis in particular, but can be easily re-cast to cover other disaster types such as earthquakes, wildfires, landslides, volcanoes, and tornadoes. The mains actors in this scenario are: ‰Û¢ Decision makers who need to effect resources ‰Û¢ Regional civil protection authorities preparing to face a natural disaster or looking for information on a daily basis in order to react appropriately. ‰Û¢ The public looking for information either to face the situation themselves or to find out what can be done to help. Figure 2: Flood response use case diagram. You can view the Floods Disaster Response Scenario demonstration video. It contains graphic depictions of each step in the scenario for two flood events: the flood in Myanmar in May 2008 and the strikes of hurricanes Hannah and Ike on Haiti and the Gulf coast of Texas. The international Flooding and Coastal Hazards Community of Interest consists of national disaster management, meteorology, hydrology, and emergency response agencies supported by regional inter-governmental centers, universities, and institutes plus satellite data providers and providers of value added services. Data and computing resources provided by these communities of interest members are integrated through the GEOSS interface standards and made accessible through common desktop tools. Many of the collaborating satellite and value added providers are organized for this AIP-2 activity and for the GEO Task DI-09-02B through the international Committee on Earth Observation Satellites (CEOS). The components and services implemented in this scenario are in continual use supporting disaster management activities on a global scale. For example, local and regional disaster, meteorology, and hydrology agencies in Africa and the Caribbean are currently evaluating these components and services, and they will be refined accordingly as part of an on-going Group on Earth Observations (GEO) Task DI-09-02B.

The process developed in the AIP is called a ‰ÛÏreusable process‰Û because in implementing the GEOSS service oriented architecture the various Societal Benefit Areas (SBAs) will involve many players over time, and those players will benefit from a proven formal process for implementation. Later players will benefit from the experiments and documentation that has gone before. The process begins with a scenario defined by the SBA community and then employs GEOSS resources to make a variety of Earth observation information assets available for researchers and decision makers in that SBA community. The process is now published and available for use by anyone (see AIP-2 engineering reports)

AIP Evolutionary Development Process

The AIP task employs an ‰ÛÏevolutionary development process‰Û whereby the architecture, the delivered systems, and the stakeholders co-evolve. Stakeholder needs are reassessed with each iteration of the architecture; the architecture is used to guide each system as it moves through development, and appropriate versions are used to evaluate each system on delivery. Architectures developed under this approach emphasize •Ââexibility and adaptability. This approach is well suited to software system development in cases where it is impossible to postulate all of the requirements and the system development can proceed iteratively.

Figure 1 shows the steps for a single phase. The main result of the concept development phase is a Call for Participation (CFP) that is released to the GEO community. Organizations that respond to the CFP then gather for a kickoff workshop for the phase that begins the development process. The development phase includes design development, design review and testing activities. A phase of AIP is completed with the delivery of demonstrations, engineering reports, and the transition of new functionality to persistent operations. The AIP evolutionary development process is an application of the process defined and used in the OGC interoperability program. The OGC process has been used and refined in 35 testbeds and pilot initiatives, most notably for the development of the OGC Web Services Standards (OWS) baseline.

Certainties in the GEOSS Technical Architecture

One key certainty in the GEOSS technical architecture is that it is “service-oriented”. This means that network-resident software components interact in a client/server fashion with other network-resident software components. Internet-resident geoprocessing clients send instructions to Web servers, and those servers respond by providing processing services or data.

Another key certainty is that these client/server communications will use interfaces and encodings that implement open, not proprietary, standards. Because GEOSS clients and services implement open standard interfaces, anyone can write software that takes advantage of those clients and services (subject in many cases, of course, to access restrictions). This adheres to the basic paradigm of openness on the World Wide Web: Open standard interfaces such as HTTP and open standard encodings such as HTML enable diverse developers to write software components that reliably interoperate with countless other components on the Web.

As a “system of systems”, GEOSS is composed of contributed Earth Observation systems, ranging from primary data collection systems to systems for the creation and distribution of information products. Although all GEOSS systems continue to operate within their own mandates, GEOSS systems can leverage each other so that the overall GEOSS becomes much more than the sum of its component systems. This synergy develops as each contributor supports common arrangements designed to make shared observations and products more accessible, comparable, and understandable.

Coming next: AIP-3 Initial planning for the third phase of the GEOSS Architecture Implementation Pilot (AIP-3) began in November 2009. Below are some of the details: AIP-3 Summary – current focus to begin CFP planning ‰Û¢ Build on the content and processes of GCI and AIP-2 ‰Û¢ Promote mash-ups in a “link-rich” environment using the service-oriented architecture ‰Û¢ Engage Communities of Practice (CoP) continuing the AIP-2 scenarios and extending to additional SBAs ‰Û¢ Increase focus on data by promoting access services from content providers ‰Û¢ Experiment with implementation of the GEOSS Data Sharing Guidelines ‰Û¢ Experiment with controlled vocabularies of EO observables ‰Û¢ Schedule to support Ministerial Summit, November 2010 AIP-3 Schedule ‰ÛÒ (to be confirmed) ‰Û¢ Post AIP-3 CFP – January 2010 ‰Û¢ Responses to AIP-3 CFP – Early March 2010 ‰Û¢ Kickoff Workshop (Europe) – Mid March 2010 ‰Û¢ Demo Capture Workshop (US) – 2nd half of 2010 ‰Û¢ Ministerial Summit & GEO VII (China) – November 2010 ‰Û¢ Finalize AIP-3 deliverables – 2nd half of 2010 ‰Û¢ AIP-3 results transition to operations – 2nd half of 2010

Next Steps

At both the global level and at the local level, identifying information resources and setting up enabling technology is necessary but not sufficient for a working GEOSS.

In the AIP, projects are being defined that link together satellite providers and value-added services with national partners andåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊ regional/ international agencies in a many-to-many relationship under pilot programs. These pilot programs are local in nature, but supported on a global scale with orbital, aerial, and in situ sensors and analytical models. The data, when they are combined with underlying socio-economic data and infrastructure, can be used to predict risk and assess effective mitigation strategies.

But such resources will not be utilized unless institutional arrangements are in place. In addition to providing institutional support for the technical interoperability work described above, GEO assists in establishing framework agreements that cross country and agency lines to enable the delivery of societal benefit through open data sharing principles.

Funding, of course, is the key to success. Many components and services utilized in this AIP-2 scenario are prototypes of persistent exemplar data services, but most of them are pulled together on budgets gleaned by the individual AIP-2 participants who write competing proposal after proposal to granting agencies that request funds to support this scenario. Governments need to allocate funding at all levels to pay for data delivery infrastructure capacity. The integration of satellite data and value-added services for local use has to be in addition to funds for local utilization and capacity building activities.

References:

AIP-2 Summary Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.1

Polar Ecosystems Biodiversity Scenario Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.0

The Impact of Climate Change on Pikas Regional Distribution Climate Change and Biodiversity WG Use Scenario Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.1

Floods Disaster Response Scenario Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.3

George Percivall

Chief Architect and Executive Director, Interoperability Program

Open Geospatial Consortium, Inc. (OGC)

1804 Stonegate Ave

Crofton, MD 21114

gpercivall@opengeospatial.org

Phone: +1 301 560 6439