GEO Conference



Intermap

 
     
   
 

The Internet has amazing potential to provide an ever-increasing number of goods and services—evils like viruses and spam notwithstanding. But the Internet also has shown that many of today’s software applications often don’t work well together. Non-interoperability needlessly drives up the cost of information technology by impeding the sharing of data and computing resources. Real-world risks, however, are a more serious consequence of non-interoperability.


For instance, suppose a gasoline truck hits a utility pole where a state highway intersects a county road. Fuel spills and burns, and some runs into a storm drain that empties into a stream. The utility pole—owned by the electric utility and used by a cable company and a phone company—topples amid a tangle of wires. Traffic backs up in all directions. People are injured, and the fire spreads to nearby properties.


Consider the information sharing possibilities in this scenario, beginning with the government and private entities that might have and/or urgently need spatial information: the state and local police, the ambulance service, the local fire department, the company that employs the truck driver, the company that monitors hazardous material transportation, the state and local highway departments, the local sewer department, field engineering and customer service groups at each of the “wires” companies, the traffic reporters at the local news broadcasting stations, the state department of environmental protection, the owner of the burning property, and perhaps federal authorities such as the Federal Emergency Management Administration and the Environmental Protection Agency.


Currently only some of this information flows smoothly, particularly that which requires only a phone call or works through proprietary interfaces in tightly coupled systems. But most of the real-time sharing of digital spatial data can’t happen. It often takes hours or days, because no single technology provider has “tightly coupled” all of those systems, nor have all providers yet implemented standards that enable “loose coupling” of multiple vendor applications.

Now imagine a much broader disaster—a major flood, an earthquake, an explosion, a building collapse in a downtown area, a natural gas pipeline explosion or a sudden national epidemic. Consider the impact of non-interoperable data on services such as power, water, electricity, sewage and transportation, and consider the impact on

  safety and repair costs. Suffice it to say that all “spatial data infrastructure” stakeholder groups, along with the vendors that serve them, have a responsibility to work together to establish interoperable geoprocessing that will help agencies plan for, mitigate and respond to such real-world havoc.
 
In recognition of this important responsibility, the Open Geospatial Consortium (OGC), an innovative public-private partnership, has worked for more than a decade to enable interoperability in the spatial technology domain. Although geographic information and geoprocessing software pose some particularly difficult interoperability challenges, OGC’s efforts have become increasingly important as agencies and businesses work to increase quality while reducing costs of services, face an ever-changing economic landscape and address national security threats.


Sources of Geoprocessing Non-Interoperability
Information about the location, shape of, and relationships among geographic features and phenomenon can be highly complex. One reason is that there are many fundamentally different kinds of systems for creating, storing, retrieving, processing and displaying geospatial data. These include vector and raster geographic information systems, as well as systems for Earth imaging via satellites and airplanes, computer-aided design, navigation, surveying, cartography, location-based services, facilities management, etc.


Numerous vendors work within each of these technology domains that did not, until they joined OGC, collaborate with their competitors to form agreements on how geospatial data should be structured and shared, and how their respective systems might better communicate, or interoperate. This lack of communication, coupled with the many different ways of measuring and mathematically representing the Earth, produced a complex and non-interoperable geoprocessing environment. Moreover, there are user-side semantic issues. For example, without coordination, no two highway departments will use the same attribute schemas, measurement types and data types to describe a road. Their “metadata,” or data describing their data sets, also use different schemas, making automated data discovery and data sharing difficult.


Overcoming Havoc with Open Standards
According to a recent Delphi Group report, “The Value of Standards,” there is a clear and sudden shift in attitudes toward software standards (see “What Is an Open Standard?” below). Delphi’s conclusions are striking: “The climate of economic constraint and risk aversion, along with the mandate to integrate systems on both sides of the firewall, has created a sea change in the sense of imperative to adopt software standards.”


The report portrays a shifting landscape in which standards will provide the foundation for long-term advances in the way software is built, bought and deployed. It appears that interoperability is seen to be much more important than just a year or two ago. This realization is reinforced by the success of the Internet and Web, where open standards such as HTTP, TCP/IP, XML, SOAP and ebXML give users a taste of what interoperability is truly about.

 

 
   
 
 


Open standards address user needs that can only be met by cooperation among and between technology providers. Overall, users want to maximize the value of past and future investments in systems and data. In the geospatial world, that general statement points to the following user needs:

1. The need to share and reuse data to decrease costs, obtain additional or better information and increase the value of data holdings.
2. The need to choose the best tool for the job and the related need to reduce technology and procurement risks —i.e., the need to avoid being locked into one vendor.
3. The need to leverage investments in software and data, such as enabling more people to benefit from using geospatial data across applications without the need for additional training.


An open framework that addresses these basic needs makes it possible for vendors to address a new array of user needs that require a standards foundation. These additional needs include:

1. The need to organize geographic data stored in text and on video, audio and other media.
2. The need to access and process on-line sensor data (a sensor is always someplace) from multiple sources.
3. The need for location-based services that are portable across devices, networks and providers.
4. The need to apply different symbology to data for different applications.
5. The need to take advantage of grid computing for geoprocessing applications.
The solutions that vendors will offer to fill these needs must have a standards platform that enables them to establish new markets and new opportunities for growth.

The OGC Model
One might argue that governments, industries, professions and disciplines are obliged to their stakeholders to create a shared information framework that will optimally support their work in the future. OGC has learned that this happens best in an inclusive, structured, consensus-based specification process with ample input from prototyping in testbeds and real-world testing in pilot projects. OGC’s “Interoperability Initiatives” are testbeds, pilot projects and other short-term, intensive, multiparticipant “spiral engineering” activities to develop, test and promote the use of OpenGIS Specifications.


Specifications developed initially in testbeds typically are completed in the OGC Technical Committee, tested in commercial products in pilot projects, and then approved by the OGC Technical and Planning Committees for worldwide use. Interoperability Initiatives provide an opportunity for technology user organizations to steer the direction of technology by providing user interoperability requirements, which are the main guiding factors in these initiatives. Other technology domains could use the same methods to quickly develop standards that are quickly implemented in commercial products and tailored to users’ interoperability needs.


To ignore the opportunities offered by the effective use of standards to enable interoperability leaves “interoperability” to be defined by vendors’ de facto standards and to consultants who build a stovepipe system from the top down that essentially condemns stakeholders to prolonged havoc—increased cost of ownership, lack of flexibility and agility, and increased life cycle risk. Of course, vendors and consultants also play essential roles in the world of interoperability and standards, because software development, maintenance, customization and service require special skills. Success, however, lies in the ability to engage these experts and other stakeholders in the OGC specification process.


Data models also play an important part of the information space. OGC developed an XML encoding for spatial data, the Geography Markup Language (GML), that, when used with XML tools, makes it possible to resolve many of the difficulties associated with incompatible data models (see “JPEG 2000 and GML”).


In addition, it’s important to emphasize the crucial role that users play in the move toward open standards. With so much at stake, imagine what could be accomplished if a large number of people each took a small step and insisted on open standards in procurements.

Publisher’s note: This article is condensed from a chapter written by Mark Reichardt for The Standards Edge: Dynamic Tension, copyright 2003, The Bolin Group.
 

 
  See more Featured Articles
 

  See  Featured Images
 
  Subscribe to Earth Imaging Journal

 
Go to Home Page
      

 

  [none]

Copyright ©2003-2007 Earthwide Communications LLC - Powered by eNetwork Marketing