Agile Earth Observation
Written by Mark Reichardt
GIF 2010 Volume: 8 Issue: 3 (April)
Access And Fusion Of Real-Time Data
From A Wide Variety Of Sensors.
“At a dock in New York Harbor, an explosion releases a cloud of radioactive cesium that drifts over the New York metropolitan area. The Port Authority Emergency Operations Center quickly launches an emergency management operation that relies heavily on access to information from a wide variety of sensors.”
This summarizes the scenario for the OWS-4 Testbed Final Demonstration held in the Port Authority’s situation room. (OWS stands for OGC Web Services, and the current testbed is OWS-7.)
The purpose of the OWS-4 demo was to illustrate that existing software products using existing standards enable discovery, access and fusion of real-time data from a wide variety of sensors, and that this sensor data can be immediately used with geospatial data and models from other online sources.
One resource accessed by officials in the test was the NASA SensorWeb. Via an open interface, operators tasked the SensorWeb to provide NOAA weather data and NASA’s Earth Observing 1 (EO-1) satellite imagery of the of the New York/New Jersey area. The EO-1 imagery immediately became part of an information environment that included in-situ radiation sensors, Doppler radar, a Lagrangian plume model, orthoimagery and Google Earth base maps.
Agility is important in intelligence gathering, and software agility, gained largely through open interfaces and encodings, is the key to agility in decision-making, business processes and workflow. Analysts looking for information frequently run up against constraints imposed by their technologies due to a lack of interoperability between systems or data. They would like to be able to jump from one view to another, which often means jumping between different sensor systems. An analyst would like to be able to quickly see a map showing all the online video cameras in an area, and the map should make it immediately obvious which way the cameras are pointed and whether they can be controlled. One click on a video camera’s icon should open a window showing what that camera is imaging.
In an analyst’s ideal world, this quick visual survey of sensors in a region would also include those mounted on satellites and UAVs, as well as in-situ sensors for chemical, biological and radiological hazards, and perhaps also sensors mounted on wheeled vehicles.
COMMON LANGUAGE
Everyone has experienced the agility of the Web. We jump from one Website to another to quickly narrow in on the information we seek. That agility is possible because HTTP, HTML, XML and other standards constitute a common language of interfaces and encodings that enables all Web clients and servers to communicate, sending and receiving instructions and results.
For sensor Webs, HTTP, HTML and XML are necessary but not sufficient. Discovering Web-resident sensors, assessing their fitness for use and then accessing them and their live or stored data requires additional common interfaces and encodings.
Systems need the common encodings for describing the sensors, the locations and motions of sensors’ physical platforms, the sensors’ observations and measurements, the sensors’ control parameters and the services that use them. The common interfaces enable software components to exchange service requests and services. Catalog services also require common interfaces and encodings if they are to be used by other services that automate discovery and access.
To get the most from some sensors, users also need a way to schedule access to the sensors. That is, there should be a standard way to post instructions for a particular Earth imaging sensor—for example, to provide maximum detail for Manhattan whenever it is in the sensor’s observation swath between July 1 and July 4.
The agile capabilities described above provide a view of intelligence gathering in a cloud computing environment. That is an environment in which many of the resources available to the analyst, such as sensors, data stores and software, are “out on the Web.”
Cloud computing environments for national security intelligence gathering are carefully secured, of course. But there is no practical limit to the resources available in a secured cloud computing environment, and freedom from proprietary stovepipes brings the same flexibility and capability to users of a secured cloud that it brings to users of a publicly accessible cloud.
Developers and their clients who are planning geospatial intelligence systems want their systems to able to respond to future requirements. This challenge is referred to as agile software development.
Such agility is evident in sensor systems when new sensors or processing services or registries or client applications become available and these new resources are immediately usable with existing resources. Again, open interface and encoding standards provide the common language that makes this possible. “Sensors are everywhere” has become a truism, and there is growing awareness that Web-resident sensors can easily, through open standards, be made part of the ubiquitous network of information resources.
Agility in developing software is one result of service-oriented architecture. In today’s net-centric information environment, server components provide services in response to client components that consume those services, and every service or data resource is coupled with a description of that resource. Because these resources are selfdescribing, they don’t need a person to determine whether service A will connect with request B. Self-describing Web services with open interfaces and encodings can connect automatically, and broker services can query registries of services’ descriptions to direct the connections. The OGC’s Sensor Web Enablement (SWE) standards enable the realization of agile sensor webs much like TCP/IP, HTML, and HTTP enable the World Wide Web. SWE standards include four standard XML encodings (SensorML, O&M, SWE Common, TML) and four standard web service interfaces (SOS, SAS, SPS, WNS).
SWE standards are designed to be fully compatible with the OGC’s Web Services Standards for Web-based geoprocessing, and both sets of standards are the result of an open, consensus process as demonstrated in OWS-4.
In addition to the advantages described above, open standards provide:
• More competition among tool developers and solution providers
• More abundant data sources
• Ability to share and utilize efforts funded by others
• Traceability and observation lineage
• Quality of measurement
• More widely available technical support.
WEB ENABLEMENT
SWE is a cornerstone of the European Space Agency’s strategy for addressing harmonized multi-mission satellite feasibility analysis and tasking management for disaster, emergency response and security services as well as for land, marine and other global services. This challenge is being addressed cooperatively by the member states agencies that own EO missions (DLR-Germany, ASI-Italy, CNES-France, the Canadian Space Agency and the European Organisation for the Exploitation of Meteorological Satellites).
The demand and the requirements for Earth observation (EO) data have evolved drastically. The amount and volume of requested data has increased by a factor of 10 over the last 10 years, in line with the users’ processing and analysis capabilities. More than 80 percent of the users request and use data comes from more than one satellite or satellite operator. The challenge for EO satellite operators, space agencies and EO data providers is to properly identify the available satellite mission, to study acquisition feasibility, to task, acquire and process the data, and to offer access to the different data as coherently and easily as possible.
In line with the vision of ground segment interoperability driven by geospatial user needs, the European Space Agency has worked with the other agency partners within the Heterogeneous Missions Accessibility Architecture Working Group. They have modeled a standard approach to perform feasibility analysis and tasking of sensors flying on satellites that provides consistency of interaction with any geospatial sensor. To implement this, a sensor planning service application profile for EO sensors has been defined and is being standardized within OGC. ✯
Mark Reichardt is chief executive officer and president of the Open Geospatial Consortium.
