FAQs - OGC and "Openness"
- What is OpenGIS®?
- What is an "open standard"?
- Does OGC develop open data formats? What is GML?
- Why are there different membership levels in OGC?
- What are "open portals?"
- What are "open procurements?"
- What can users and buyers of GIS and other geoprocessing software do to get more "openness"?
- Does OGC promote standard data models and standard metadata schemas?
- How do OpenGIS Specifications support system integration?
- What is Interoperability?
- What are "open systems" and "open interfaces?"
- What is an "open platform?"
- Why are architectures important?
- What is an application schema?
Q: What is OpenGIS®?
A: OpenGIS is an adjective describing specifications and other products of OGC's consensus process that support transparent access to heterogeneous geodata and geoprocessing resources in a networked environment. The goal of OGC is to provide a comprehensive suite of open interface specifications that enable developers to write interoperating components that provide these capabilities.
OGC registered the trademark "Open GIS" and OpenGIS® in countries around the world to assert the importance of open standards in geoprocessing and to protect its standards with a legal brand. A software vendor whose software implements interfaces based on OGC’s standards can claim that a product "implements" particular OpenGIS Specifications. If the product has passed a conformance test for a particular OpenGIS Specification, the vendor can claim that its product conforms to that version of a specification and it can use OGC’s trademarks to assure buyers of the veracity of those claims. The phrase "open GIS" (with a small "o") is also a trademark of OGC, with the same meaning as "Open GIS," though "open GIS" is not a registered trademark.
[ Top ]
Q: What is an "open standard"?
A: OGC defines an open standard as one that:
- Is created in an open, international, participatory industry process, as described above. The standard is thus non-proprietary, that is, owned in common. It will continue to be revised in that open process, in which any company, agency or organization can participate.
- Has free rights of distribution: An "open" license shall not restrict any party from selling or giving away the specification as part of a software distribution. The "open" license shall not require a royalty or other fee.
- Has open specification access: An "open" environment must include free, public, and open access to all interface specifications. Developers are allowed to distribute the specifications.
- Does not discriminate against persons or groups: "Open" specification licenses must not discriminate against any person or group of persons.
- Ensures that the specification and the license must be technology neutral: No provision of the license may be predicated on any individual technology or style of interface.
By this definition, a de facto standard established by one company or an exclusive group of companies or by a government is not an open standard, even if it is published and available for use by anyone at no charge. The Web, and the Spatial Web, cannot depend on proprietary standards.
[ Top ]
Q: Does OGC develop open data formats? What is GML?
A: In the not so distant past, it was important to know whether your data was in a particular vendor’s (published or unpublished) format, such as SHAPE or DXF or in an open government format such as TIGER or VPF, or in an exchange format such as SDTS or SAIF. Now, format is not a major issue when vendors’ systems communicate through open interfaces. People sometimes want to archive whole data sets in the format native to the software they are using, or in an exchange format, but bulk conversion of data files from one format to another is becoming less and less necessary. The new world of ‘open’ enables conversion "on the fly" when the data are needed, "invisibly" to the user. This not only avoids the enormous investment in converting data that may never be used afterwards, but it makes it easy to provide or find up-to-date data as well.
Ironically, the Web provides justification for something like a universal open format: Virtually all Web browsers now include software to process text encoded in the eXtensible Mark-up Language (XML). XML can be described as a language for creating self-describing data files, that is, data files whose headers explain how to interpret the data that comes after the header. This has turned out to be a very powerful concept. Scores of industries and professional domains have seized on the opportunity to develop XML schemas (essentially formats) to capture the specific kinds of information that need to be shared within those industries and domains by organizations whose legacy systems are very different from each other’s.
Similarly, the members of OGC developed the Geography Markup Language, which is well on its way to becoming the standard XML encoding for geospatial information. It happens that XML-encoded geospatial metadata, (parts of which conform with GML) are a keystone element of the OGC Web Services architecture that makes possible detailed, complex, automated searches for spatial data and spatial services on the Web. Also, GML separates content from presentation, so the way in which data is presented (on desktop systems and PDAs, for example) is entirely under program control and can thus be tailored automatically to suit display device capabilities or application requirements. Very importantly, one of the major breakthroughs with GML is that, when used with XML tools, GML makes it possible to resolve many of the difficulties associated with incompatible data models.
It is not difficult to create profiles (application-specific variations) of GML, and this is what most data developers will do. The Ordnance Survey of Great Britain and the US Census Bureau (in its TIGER data) have committed to GML. But everyone in the geoprocessing industry should be aware that it is also easy to create new XML schemas for geographic information that are not profiles of GML, and herein lies the risk of a new obstacle to interoperability.
[ Top ]
Q: Why are there different membership levels in OGC?
A: OGC is a membership organization supported solely by membership fees and fees paid by sponsors of Interoperability Initiatives. Membership levels are designed to accommodate different organizations' range of commitment, ability to pay, benefits of membership and reasons for joining. These considerations are balanced against the longstanding policy to make membership affordable for every organization that wants to be involved and the need to pay staff and consultants to organize meetings, promote the consortium and its activities, and maintain the Web site and specification documents.
[ Top ]
Q: What are "open portals?"
A: Geospatial portals can be thought of as the "hubs" or "geoinformation resource supermarkets" in the Spatial Web. A portal is a Web site that gives visitors organized access, typically through catalog services (services not too different from those provided by search engines), to data and processing resources on the Web, and perhaps also to people, organizations and publications. A portal offers an organized collection of links to many other sites. A portal thus can be used to aggregate content. And by attracting a large number of visitors who share a common interest, a portal also aggregates content seekers for the benefit of content providers and potentially for the benefit of that community of content seekers.
Users of geospatial portals based on the OpenGIS Portal Reference Architecture are able to immediately access – pan, zoom, compose, save and print – views of digital geospatial content held on diverse Web-connected servers. Multiple maps from multiple servers can be overlaid and "flipped through." Data providers register their data for access via the portal. Applications (and other portals) can integrate portal resources into information offerings and work flows.
The OpenGIS Portal Reference Architecture is a comprehensive, flexible, vendor-neutral framework for implementing geospatial portals, a design that is based on a collection of OpenGIS Specifications for software interfaces and GML encodings. It details the kinds of requirements that need to be considered in various spatial portal application scenarios and shows how to meet those requirements with components whose interfaces implement OpenGIS Specifications.
Software comprising a portal can be from one or several vendors. The key criteria for an open portal is that it be fully interoperable with all the other spatial resources on the Web that are equipped with interfaces, encodings etc. that implement OpenGIS Specifications.
[ Top ]
Q: What are "open procurements?"
A: Open interfaces make it possible to specify in a procurement a type of software component, rather than specifying one particular vendor’s software. The goal is to be able to build incrementally with "best of breed" components, and to be able to "swap out" and "swap in" software components. For example, the procurement language might be, "Application shall implement a geocoding service that is accessible via the OpenGIS Location Service Geocoder Interface Specification." This offers geoprocessing software buyers unprecedented savings and flexibility. With respect to a geospatial portal or other Web-based geospatial solution, whether or not the solution uses components from multiple vendors, all of its connections to outside resources and users must be through open interfaces. If not, the implementation remains a closed system, a stovepipe, an island of automation that prevents present and future inter-institutional interoperability.
Open standards make open procurements possible. The open procurement specifies functional requirements and interoperability requirements. Products can easily be benchmarked in an interoperability pilot. Vendors that meet contractual requirements and demonstrate functional requirements and interoperability are qualified to provide components. This multi-vendor procurement process has been used successfully by numerous government organizations over the years.
[ Top ]
Q: What can users and buyers of GIS and other geoprocessing software do to get more "openness"?
A: Standards setting ultimately depends on users buying products that are based on standards. Vendors in OGC who have committed significant resources to developing the OpenGIS Specifications, with input from users, do so as an act of faith. They have implemented many of these specifications in products, but they depend on their customers and potential customers to understand the standards and ask for them. Public and private sector organizations owe it to themselves, their customers, shareholders, stakeholders, data sharing partners and constituencies to use the OpenGIS Reference Architecture (ORM) and the OpenGIS Portal Reference Architecture as models for their next purchases. These reference architectures make it easy to discern which OpenGIS Specifications are relevant to their needs. At a minimum, they need their local governments to ask for OpenGIS Geography Markup Language (GML), Web Map Server (WMS) and Web Feature Server (WFS) Specifications in software procurements.
Vendors and consultants must encourage their customers to make their data available in GML. (This doesn't mean users need to change their data models. They just need to convert their data to GML so it can be "understood" by XML-parsing software.)
User organizations in OGC that have committed resources to developing the OpenGIS Specifications by providing requirements in testbeds and pilot projects need other user organizations to help "move the ball forward." Particularly with respect to governments’ needs to protect critical infrastructure and citizens in time of disaster, widespread user acceptance of open standards is critical. Similarly, industries that depend heavily on geospatial information are motivated to reduce their costs of system integration and data integration, and they can do this best if all their internal geoprocessing systems and the geoprocessing systems of data sharing partners are interoperable. In areas like location-based services and sensor webs, the opening of whole new markets depends on product strategies based on open standards.
So, it is incumbent upon buyers of geoprocessing software, data and services to carefully review their requirements and draft interoperability architecture documents that lead to purchase of solutions that implement the appropriate OpenGIS Specifications. This can be done piecemeal, one upgrade or add-on at a time, or, if it is time for the organization to put a whole new solution in place, it can be done comprehensively, all at once. OGC and OGC's members can help by examining use cases and explaining where open interfaces can be specified into the architecture on which procurements will be based.
Much is at stake, and much will be set in motion when a large number of people each take a small step in the direction of openness.
[ Top ]
Q: Does OGC promote standard data models and standard metadata schemas?
A: OGC encourages these efforts, recognizes their value and their limitations, and provides a framework of software interface standards and data encoding standards that helps people make the best possible use of others' data despite dissimilar data models and metadata schemas.
A data model details how to take real world objects or phenomena and make them useful in computer applications. In the geospatial world the focus is on points, lines, polygons and attributes of geographic features.
Metadata is "data about data," important in finding data and evaluating its usefulness for a particular purpose. A metadata schema is a template or structure for metadata.
Without coordination, different people and organizations working at different times on different kinds of projects produce data using different data models, and they describe their data using different metadata schemas. The differences have made it very hard to share and combine data. Coordination efforts are underway in many countries to develop and adhere to standard data models and standard metadata schemas. However, a nationwide standard that meets both local and national needs is very difficult to achieve, and the cost of attaining consistent data content seems to many (particularly those at the local level) to make this an unreachable goal.
It happens that standard data models and standard metadata schemas can be very useful even if no one follows them precisely. The standards will have an important role as "Rosetta stones" that enable users to "imperfectly" map data in a "local" data model to a common model, thus making their data "as useful as possible" to others. One-to-one mapping of data models is unworkable when there are thousands of models to map between. GML enables a one-to-many solution.
One-to-many mapping of data models is made possible by XML tools. The XML tools (prototyped in OGC's GOS-TP and CIPI-2 pilot projects) map GML-encoded data from a local model to the national model and vice versa. The data thus becomes "as useful as possible" to the data sharing partner who uses a different model. Certain elements of one model do not map to the other, but the XML tools make these inconsistencies plain in all their details, so that it is easy for data managers to focus on the critical schema elements that don’t map. This makes both data sharing and data coordination much easier. It makes it easier for people at the local level to accommodate national standards in an affordable and practical way, and it makes it easier for people at the national level to work with local data that hasn’t been converted in all its details to the national standard.
Another benefit of the GML approach is that this technology makes content standards easier for software vendors and integrators to support. Currently, content standards are expensive to support, and smaller companies that do not support them are at a disadvantage. The new approach thus enhances competition, increasing the choices available to users in the market.
[ Top ]
Q: How do OpenGIS Specifications support system integration?
A: Integration in our industry means making spatial data accessible from multiple technologies and software vendors and making spatial data and spatial functionality available to other IT systems such as customer response management, logistics, location-based services for wireless devices, etc. The benefit is that users can thus access, combine, and disseminate geospatial information from distributed and varied information sources. Integration streamlines workflow and reduces costs of information production, maintenance and dissemination.
Integration is far more efficient, with significant immediate and downstream cost savings, if the integration can be accomplished with open standard interfaces instead of proprietary and/or custom interfaces. Enterprise systems integrated using open interfaces can enjoy the "network effects" that result from the same interfaces being used in the world outside the enterprise. An open interoperability platform motivates vendors to introduce more tools, components, and niche solutions for integrators to employ. OGC’s goal is to create a single, vendor-neutral infrastructure for integration that works everywhere, across all platforms, technologies and types of devices.
[ Top ]
Q: What is Interoperability?
A: Software interoperability describes the ability of locally managed dissimilar systems to exchange data and instructions in real time to provide services (computing services as in "client/server" or "Web Services"). Interoperable systems are generally distributed (i.e., at different places on the network), though in OGC’s case, interoperability also applies to different types of systems or similar systems from different vendors communicating while running on the same computer. The interoperability challenge, successfully met by means of consensus reached in inclusive consensus processes, is to balance the users' need for compatibility with the autonomy and heterogeneity of the interoperating systems.
It is important to remember that proprietary algorithms typically run unseen in the "black box" component whose public face is the open interface. Some server components will outperform others and/or offer capabilities not offered by others, though they may all communicate with clients through a common interface. In an interoperable environment, competition among vendors is based on such differences in capabilities and performance, and is not based on which format the user’s data is stored in, or which software provides the display function.
Interoperability also refers to interoperability across time (evolution of systems over time with backward and forward compatibility). When users participate in standard setting, backward and forward compatibility have a high priority.
Recall that the Internet Protocols (IP) were introduced as inter-net protocols, for inter-networking, that is, moving data between different networks. At the time there were many different networks, whose names we no longer remember. Inter-networking gave way to the use ONLY of the IP protocols. The result was the Internet and then the World Wide Web, which provided a platform, an interoperability platform, supporting an extraordinary proliferation of services and applications. This is the appropriate model for a geoprocessing interoperability platform.
[ Top ]
Q: What are "open systems" and "open interfaces?"
A: The definition of open systems has changed over time, but today open systems are usually considered to be systems that interoperate through open interfaces. An interface is simply a common boundary, a means to make a connection between two software components. An interface on the client presents an ordered set of parameters (with specific names and data types) and instructions (with specific names and functions) to an interface on the server that is structured to read and respond to just such a set of parameters and instructions. Thus an interface enables one processing component to exchange data and instructions with another processing component.
Some interfaces satisfy part but not all of the "openness" definition above. The information technology world has been steadily evolving toward greater openness, so many older systems still in use interoperate in what now appear to be limited ways. Such systems from a variety of geoprocessing software companies use interfaces that the companies have published for coding by integrators and application developers. Reaching that situation was progress, considering that at one time, few proprietary interfaces were published. From today’s perspective, however, there are reasons not to depend on such published, but proprietary interfaces.
- In the old paradigm, a client system needs a separate interface for each vendor’s system. The biggest advantage of open interfaces is "build one, access many." With truly open systems, solution providers no longer need to build custom interfaces. Users are no longer isolated in technology stovepipes and no longer captive to ("locked in to") single vendor solutions. "Stovepipe" is a metaphor commonly used to describe systems that are integrated "from top to bottom" but isolated laterally, i.e., from other systems. A stovepipe system might be a system from a single vendor or it might be a system built by an integrator, but it is not an open system.
-- From time to time, vendors change or enhance their interfaces, forcing client systems to change and forcing users to upgrade, perhaps without notice or opportunity for input. In contrast, the consensus process in a consortium like OGC gives integrators and application developers both notice and opportunity for input, increasing the level of continuity in new releases. Open standards impose a few constraints on developers, but they open huge opportunities, as demonstrated by the explosion of innovation and business opportunity that has resulted from the Web.
-- Integrators and application developers will probably spend more time learning how to use the proprietary interfaces than they will spend learning how to use OGC’s interfaces. One bad result of the old paradigm has been that integrators tended to learn and then use one system exclusively simply because the cost of mastering more than one is too high, which further limits the choices available to the user. One reason open systems result in greater innovation is that they remove this burden from development budgets, freeing resources for innovation.
[ Top ]
Q: What is an "open platform?"
A: The meaning of open platform depends on the context. In general, the term platform used to denote any specific hardware and operating system combination, such as the Windows/Intel platform or the Solaris/SPARC platform. It is now used more generally to describe an application programming interface (API) or set of APIs that provide access to computing power, database, GIS or other services hidden "underneath" those APIs. The acronym "API" is giving way to "interface" in programmer-speak. By the definition of "open" in this paper, no single vendor provides an open platform unless all the exposed interfaces are open interfaces. An open platform needs to be like the IT industry’s Web Services platform, which is still, as of August, 2003, largely unencumbered by proprietary restrictions and is the product of a consensus process.
[ Top ]
Q: Why are architectures important?
A: Today's enterprise information systems depend on interfaces that enable disparate parts of the systems to work together. An architecture provides an overall plan that shows what parts are needed, based on current and projected workflows, and what interfaces and data models are needed. Architectures can be based on proprietary or open interfaces. Architectures based on OGC's OpenGIS Reference Model use open interfaces based on OpenGIS Specifications. Such open architectures enable the integration of components from any vendor that implements the open interfaces, and they provide for direct (no integration required) interoperability with other systems architected using the same open interfaces.
[ Top ]
A: An application schema is an information model for a specific information community. An application schema is set of conceptual schema for data required by one or more applications. An application schema contains selected parts of the base schemas presented in the ORM Information Viewpoint. Designers of application schemas may extend or restrict the types defined in the base schemas to define appropriate types for an application domain.
[ Top ]