Inside
the OpenGIS Specification
Lance McKee
Vice President Public Sector Programs and Corporate Communication
Open GIS Consortium, Inc.
lmckee@opengis.org
and
Cliff Kottman
Chief Scientist Open GIS Consortium, Inc.
ckottman@opengis.org
As one would expect, you can find on the Web many maps and images of the earth. You can zoom in or out of MapQuest’s street maps to get travel maps, and you can learn the distance or automobile travel time between two locations. If you know where to look, you can get weather maps, maps of Superfund pollution remediation sites, or images of the Earth that show the El Nino stretching across the Pacific Ocean. But much more should be possible. Because digital technologies are so flexible and "mixable," we should have at our fingertips, via the Web, the benefits of three decades of progress in geographic information systems (GIS), earth imaging, and automated mapping and facilities management (AM/FM). Most people are not very familiar with these technologies because the technologies and the data they create are complex, extremely diverse, and usually incompatible. Users must possess considerable expertise to overlay, combine, or analyze together different map layers or images of the same geographic region. Converting from one format or type of data to another is cumbersome, time-consuming, and error-prone.
In the OpenGIS Consortium, Inc. (OGC), expert geoprocessing technology users work with GIS software vendors, earth imaging vendors, database software vendors, integrators, computer vendors and other technology providers to reach agreement on the technical details of open interfaces that allow these systems to work together over the Web. Common software interfaces, a kind of digital "lingua franca," offer the only way to enable overlays and combinations of complex and essentially different kinds of geographic information to happen automatically over the Internet. Software developers and integrators who either provide geoprocessing software or who seek to integrate these capabilities into general purpose information systems will add these open interfaces to their software. When this happens, users will benefit from a dramatic improvement in Web-based geospatial capabilities. Initially it is the large government users who become involved because of their critical strategic interest. But major user corporations, such as telcos and transportation companies, are beginning to participate in OGC, and all users will be affected as interoperable products become deployed and accessible via the Web.
Interfaces that conform to OGC’s OpenGIS Specification will make many kinds of activity easy:
* Geospatial information should be easy to find, without regard to its physical location. Just as a search engine will show you a list of Web sites that offer recipes for cranberry muffins, a spatial search engine should show you a list of sites that offer maps showing cranberry bogs in Massachusetts.
* Geospatial information from different sources should be easy to integrate, combine, or use in spatial displays and analyses, even when the sources contain dissimilar types of data (raster, vector, network, etc.) or data with different feature-name schemas. It would be easier to share, merge, and compare digital map data if, for example, each "information community," i.e. community of people who share a feature-name schema, had automated "semantic translators" that knew the difference between that community’s schema and the schemas of other information communities. Such translators would provide, for that community, a standard way to translate between terms such as "dead-end" and "cul-de-sac".
* Geospatial information from different sources should be easy to geometrically register (to a spatial reference system), superimpose, and render for display. GIS is based on the metaphor of overlaid clear plastic maps. You can, for example, by overlaying a clear plastic map of wetlands on a map of public lands, create by hand a new map of public wetlands. Similarly, but much more effectively, you can superimpose digital thematic maps in a computer and derive new maps. This is a very powerful technology with many applications, and it is on the verge of becoming accessible to a much broader set of users, because the capability to overlay data from different online sources is about to become automatic.
* Special displays and visualizations, for specific audiences and purposes, should be easy to generate, even when many sources and types of data are involved. Anyone who can create or modify a Web site should be able to add links to provide map displays and other information services that depend on spatial data. An organic food store, for example, might want to show Web site visitors a map of local farms that supply the store’s produce (automatically updated from a database of current inventory), and they might like to provide, superimposed on the same map, customized travel directions for produce trucks to reach the store. A city government might like to add to their Web site an Airport Commission page showing alternative proposed new airport access roads, with links that allow one to superimpose the city’s traffic management map data, zoning maps, and maps of projected growth and development.
* It should be easy, without expensive integration efforts, to incorporate into enterprise (and consumer) information systems geoprocessing resources from many software and content providers. Such a resource might, for an environmental manager, extract from data at one site a set of features, such as regions of sandy soil, that coincide geographically with a set of features in data at another site, such as regions where the land surface slopes more than 10 degrees from horizontal. For a marketing manager, such a resource might extract from data at one site a set of features, such as neighborhoods in which most parents work, and from another site a road map, and calculate the best site for a take-out restaurant. Or such a resource might take a pair of Earth coordinates originating from a car’s GPS, use those coordinates to select sites that contain 1) information about local restaurants and 2) information about local roads, and then access another resource that calculates driving directions and the time it will take to reach the nearest Chinese restaurant.
OGC’s goal is to make these activities easy, through open interfaces. Taken together, the library of open interface specifications being created in OGC are called the OpenGIS Specification. The OpenGIS Abstract Specification documents specific behaviors in a formal way that conformant interfaces must provide. The Abstract Specification also establishes a basic architecture and a set of "well known types" (information structures) used in OpenGIS conformant interfaces. Through a formal process of consensus-building requests and submissions, THE OpenGIS Abstract Specifications give rise to OpenGIS Implementation Specifications which are engineering specifications that software developers use to develop OpenGIS conformant interfaces for their software products.
Below we look at specific capabilities enabled by the OpenGIS Implementation Specifications that have been completed and the OpenGIS Abstract Specifications that will provide a basis for new Implementation Specifications.
The OpenGIS Simple Features Implementation Specification addresses tools for handling data such as streets, land use zones, property lines, watersheds, etc. which are represented with simple vector figures. Interfaces that conform with this specification can communicate geometry (using simple vector figures composed of points, lines, and polygons), spatial referencing (such as Mercator projection and Longitude/Latitude), and feature attributes (such as zoning category or type of road). Soon, geoprocessing software vendors will deliver OpenGIS-conformant server and client products which will mix and match to service end user demands. The services provided will enable users to sort and modify geographic features using such operations as intersect, union, subtract, spatial buffer, and select by attribute or location. Such an operation might, for example, extract a set of all the shoreline features within a certain rectangular region, or within 20 kilometers of specified point. Conformant server software may also respond to client requests to modify or add to the features and feature collections under the control of the server. A civil engineering firm, for example, would be able to log in remotely to a public works department’s municipal facilities GIS server via the Internet so the firm’s engineers could add data representing new curbs, highway bounds, storm drains, sewer lines, etc. It wouldn’t matter that the engineering firm and the city were using software from different vendors.
The Simple Features specification is available to the public at http://www.opengis.org.technology.
SQL, OLE/COM, and CORBA profiles of the specification are available. This specification is general in the sense that it is not specifically for the Internet. The OpenGIS Web mapping specifications, which relate only to Web mapping, depend on the Simple Features Specification.
The OpenGIS Grid Coverage Implementation Specification addresses satellite images, aerial photos, digital elevation data, and other kinds of "gridded" data. (Note that the OGC Technical Committee uses a special definition of "coverage," described on page _[Kim, see paragraph describing "Topic 6"]_ which is different from the definition used by some GIS software vendors.) A client application with an OpenGIS Grid Coverages conformant interface can communicate across a network with servers that have OpenGIS Grid Coverages conformant interfaces. It doesn’t matter that the servers are from different vendors. The client can access the data held in the servers so a user can view it, panning and zooming, and a client can also instruct the servers to perform simple grid-based operations on the data held in those servers. Such an operation might, for example, extract a set of all the grid cells within a certain geographic region that have a value corresponding to a water temperature between 15 and 18 degrees Celsius. Or it might simply extract a view of a digital aerial photo for display underneath a view of a property line map. Like the simple features specification, this specification is not specifically for the Internet, but the Web mapping specifications depend on it.
The OpenGIS Grid Coverages Implementation Specification is available to OGC members now and will be available to the public later in 2000. SQL, OLE/COM, and CORBA profiles are included in the spec.
The Simple Features specification and the Grid Coverages specification use the same procedures to communicate details of geodesy and geometry, so data of both types can be "georeferenced" or overlaid using the same spatial reference system. (This works at a basic level in the current versions, but the capability is not fully specified yet. An OpenGIS Coordinate Transformation Specification now in development will make the georeferencing capability much more robust.) Georeferencing, it should be noted, depends on the resolution and accuracy of the data. Besides the fact that accuracy is never perfect, the resolution and accuracy level of two data sets are likely to be different. So it may happen, for example, that a shore road as represented in a transportation data set will appear to be offshore in a bay as represented in a hydrology data set, even though the views of each data set are identically and correctly georeferenced.
The OpenGIS Catalog Services Implementation Specification provides a common architecture for online automated directories, or clearinghouses, of Web-based geospatial data and geoprocessing services. It is available to OGC members now and will be available to the public later in 2000. SQL, OLE/COM, and CORBA profiles are included in the spec. This catalog specification establishes a standard way to create catalog entries that describe online geospatial data and geoprocessing services and point to their URLs. It also establishes a standard way for an online geospatial data resource or processing resource to present the "metadata" that describes itself. This is analogous to the standard way that non-geospatial Web sites describe themselves. (The catalog specification does not impose a particular metadata format, but instead imposes a set of protocols for invoking behaviors that set, retrieve, compare, and expose metadata.) Such self-description is important because it enables Web crawlers and search engines to find and index information about hundreds of thousands of Web sites.
The catalog specification provides the infrastructure for "spatial search engines." This specification, which owes a debt to digital libraries research, the Z39.50 document indexing system, and to metadata standards efforts in ISO TC/211 and FGDC, provides a blueprint for a system that will enable users (and software mechanisms) to quickly and easily search the Web for data about a particular geographic point or region. For example, for a given region, you will be able to search for "themes" such as soil type, properties for sale, public high schools, elevation, wetlands, railroad rights of way, land use, vegetation, surface geology, or mean temperature. You will be able to add search criteria such as date of data collection, data owner, data price, and data resolution. You (or your application, or applet, or browser) will also be able to search for simple or complex online geoprocessing services that will operate on the views of data that you have selected. A series of Web site accesses, manual or automatic, might thus produce for you a map of properties for sale in Placid City which have deciduous trees, are approximately level, are at most a mile from the nearest railroad or interstate, and less than a mile from a public high school.
Five new, unfinished specification topics are listed in the OpenGIS Specification Plan and Schedule. They are listed below. In the normal Technical Committee process, these are created first as "abstract specifications" and then as "implementation specifications". However, in OGC’s Interoperability Initiatives, it is possible that some implementation specifications will be "rapidly prototyped" before they are documented as abstract specifications.
The OpenGIS Presentation Specifications (this name may change) address basic Web computing image access, display, and manipulation capabilities. That is, they specify the request and response protocols for open Web-based client/mapserver interactions. The first of these specifications, described below, are the product of OGC’s successful Web Mapping Testbed Phase 1. They depend on the already-available OpenGIS Specifications described above, and they provide the foundation on which pending OpenGIS Specifications will build an increasingly robust open environment for Web mapping.
"Web Mapping" refers, at a minimum, to the following actions:
A Client makes requests to one or more Catalog Servers (based on the OpenGIS Catalog Services Specification) to discover URLs containing desired information.
Catalog Servers return URLs and also information about methods by which the discovered information at each URL can be accessed.
The client locates one or more servers containing the desired information, using OGC’s catalog server technology, and invokes them simultaneously.
As directed by the Client, each Map Server accesses the information requested from it, and renders it suitable for displaying one or more layers in a map composed of many layers.
Map Servers provide the display-ready information to the Client (or Clients), which then display it. (Clients may display information from many sources in a single window.)
There are three main candidate OpenGIS interfaces that support Web Mapping: GetMap, GetCapabilities and GetFeatureInfo; each was been demonstrated at the conclusion of Phase 1 of the Web Mapping Testbed and each is likely to be finalized and released to the public in the next few months. These are "magic words" that can be "spoken" by a client (for example, your desktop platform) to cause interface-enabled servers listening in on the Web to do the "heavy lifting" in the Web Mapping scenario. The heavy lifting includes finding remote data store servers, requesting data from them in specifically defined structures, attaching symbols intelligently, changing coordinate systems, and returning information ready to be displayed at the client.
Interfaces conforming to the OpenGIS Presentation Specifications will geo-enable Web sites and mobile devices for every imaginable application of geospatial technology. The value of small location-aware mobile devices containing cell phone, Internet link, and graphics display will be greatly increased by open Web mapping capabilities. Consider any of the application domains listed below. Then imagine 1) the multiple on-line servers that contain the catalogs, spatial databases, and processing services, 2) the people in the field who will use the mobile devices to get information and update the databases, and 3) the associated application domains which will benefit from access to this domain data. Wherever the purchasers of the technology have chosen not to limit their users to a solution based on single vendor client/server pairs, these uses of geodata will depend on interfaces that conform to the OpenGIS Presentation Specifications:
Agriculture and forestry
Automated mapping
Business siting, market research, and other business geographics applications
Cable, microwave, and cellular transmission installation planning
Civil Engineering
City government information services
Coastal management
Commercial vehicle operations
Education/training, distance learning, multi-disciplinary research collaboration
Electronic libraries, electronic museums and galleries
Emergency road services and 911 emergency response systems
Environmental monitoring, global and local
Facilities management
Geographic matching of prospective employees with available jobs
Geographic matching of prospective service providers with prospective clients
Global disaster/emergency/crisis management
Global maritime information and rescue system, air traffic control
Health care: telemedicine, better/faster care for rural trauma victims, patient monitoring, etc.
Intelligent vehicle highway systems (IVHS)
Land tenure system administration
Landscape architecture
Logistics
Maintenance of one’s information context and connection (personal logical network) as one moves through space, bridging media and modality; mapping electronic locations of devices (addresses) to their physical locations; using concepts of reach space, co-location, and near-by.
Military applications: surveillance, planning, training, command/control, logistics, targeting, etc.
Municipal public works maintenance and administration
Natural resource discovery, exploitation, and management
Navigation
Online multimedia yellow pages with distance calculation and way-finding
Parolee tracking
Precision farming (GPS-guided controlled delivery of nutrients and chemicals based on Earth imagery or automated GPS-located soil or crop sampling)
Product distribution/warehousing optimization
Public administration networks
Public safety - fire and police departments
Recreation: hiking, boating, etc.
Route guidance, dynamic route planning, multimodal trip planning, and traveler services
Science: climate research, agronomy, biology, ecology, geology, and others
Security monitoring and intrusion response
Small farm and garden services and locale-specific resources
Special wayfinding for elderly and disabled
Support for "green" standards
Telecommunications network planning -- mobile communications
Traffic management, parking management
Traffic/weather information
Transportation planning
Urban and regional planning
Virtual reality landscapes from Earth images for: military, disaster relief, and rescue preparedness; civil engineering, landscape architecture; and interactive entertainment
Water resource management
The OpenGIS Feature Identity & Relationships Specification will specify interfaces that unambiguously model behaviors of feature identifiers. When a map layer (or "feature collection") contains multiple identical features, when features move, and/or when it is possible to access many different maps, it is sometimes necessary to have "feature identifiers" that help identify a particular feature in different maps as being the same feature. Different software systems with different feature identification approaches need a way to communicate such information, and that is what this specification will provide. For example, the electric company and the telephone company need to identify the same pole in both the electric company’s and telephone company's databases by its identity, as well as by its position. This specification will also specify common interfaces for communication about relationships between features (over, under, intersects, etc.) The Abstract Specification is in development. The OGC request for proposals (RFP) is almost complete, but won’t be approved until some time in 2000.
The OpenGIS Geometry Specification will extend the capabilities of the OpenGIS Simple Features Specification. (See "OpenGIS Simple Features" description above.) Interfaces conformant with this specification will allow read/write access to three-dimensional features and to two-dimensional features with geometries more complex than line strings, including ellipses, splines, and other commonly encountered shapes. The Abstract Specification for this topic is nearly complete. The OGC Technical Committee may combine this with Feature Identity & Relationships.
The OpenGIS Ordinary Coverages Specification will provide access to polygon coverages, triangulated irregular networks (TINs), segmented line coverages, and other subtypes of the coverage type not addressed by Grid Coverages. Release depends on Grid Coverages revision. There may be an initial release of this specification for OGC member review as soon as December, 99.
Coordinate Transformation provides interfaces for robust and general earth coordinate transformation services. The RFP was issued in June ’99, and the first submissions are due November ’99.
Taken together, these OpenGIS Specifications provide a solid foundation for general interoperability. More work, however, will still remain after these are completed. Each of these specifications is likely to be revised and extended, and others have been outlined in the OpenGIS Abstract Specification as "Bookshelves," but they have not been completed:
OpenGIS Abstract Specification Bookshelves:
Topic Volume Volume Name Work Group or Special Interest Group
Topic 0 OpenGIS Architecture Core Task Force Editor
Topic 1 Feature Geometry Geometry WG
Topic 2 Spatial Reference Systems Coordinate Transformation WG
Topic 3 Locational Geometry Structures Coordinate Transformation WG
Topic 4 Stored Functions and Interpolation Coverages WG
Topic 5 The OpenGIS™ Feature Feature SIG
Topic 6 The Coverage Type Coverages WG
Topic 7 Earth Imagery Case Coverages WG and Image Exploitation Services SIG
Topic 8 Relationships Between Features Feature Identity and Relationships WG and Feature SIG
Topic 9 Quality Metadata SIG
Topic 10 Feature Collections Feature SIG
Topic 11 Metadata Metadata WG
Topic 12 The OpenGIS™ Service Taxonomy The Services Architecture SIG
Topic 13 Catalog Services Catalog WG
Topic 14 Semantics and Information Communities Core Task Force and Semantics SIG
Topic 15 Image Exploitation Services Image Exploitation Services SIG
Topic 16 Image Coordinate Transformation Services Image Exploitation Services SIG and Coordinate Trans WG
Work is progressing in Topic 0 to define foundation classes and types, and to create consensus technology that allows clients and servers to "find" and "engage" other servers to perform wanted services. The notion of "cascading" servers is being forwarded, whereby, if a service is unable to perform a desired task, it looks for another server that can perform that task, and links to it until that service is complete. Domains like Cartography will be able to find and engage "best of breed" servers in disciplines such as names placement, symbol conflict resolution, generalization and simplification, marginalia creation, legends, and so on.
Topic 1 is being developed in tight coordination with two ISO groups: ISO/TC211 on Geographic Information/Geomatics, and JTC1/SC32, especially the work item on the spatial structures in Multi-Media environments. The foundation classes supporting points, lines, and polygons are already in general agreement, and the effort is rapidly reaching completion for more advanced curves, surfaces, solids, and complex figures. The result will be easy transitions within and between a myriad of applications of geospatial information including: business, academia, banking, planning, conservation, and so on.
Topic 2 develops the class diagrams for spatial reference systems and their components: coordinate systems, datums, and projections. OGC is working with the Petroleum Open Software Consortium (POSC) to create a complete and uniquely identified collection of the significant spatial reference systems used in the world today. An RFP for SRS services has been issued by OGC, and first submissions are due in November, 1999. Soon, there will be coordinate transformation services on the web that interoperate with most GIS application environments and transform data from source SRS to target SRS transparently. The result will be seamless and transparent transitions of spatial information that make it match the client's preferred projection and datum. Students, business persons, scientists, and casual users alike will never notice that the some of the sources of the maps they are looking at "don't fit" the projection in which they are being displayed.
Topic 3 addresses more general spatial reference systems, such as those provided by gazetteers, telephone numbers, addresses, and other place names. Here, work is also proceeding in concert with ISO, where there are several committees standardizing mappings between place names and geographic locations or extents. The goal is to free casual users of geospatial information from ever seeing a coordinate, but instead allow the casual user to deal naturally with city and county names, addresses, driving instructions, and other references to spatial locations we use in our everyday speech today.
Topic 4, Stored Functions and Interpolation, deals with the necessity to build computer representations of functions found in Triangulated Irregular Networks (TINs), segmented line environments, resampling of digital images, and so on. Much geospatial analysis is performed by exploiting various kinds of coverages, so consensus implementation specifications in this domain portend GIS analysis in an interoperable context. The result will allow urban designers to interact directly with environmentalists, land managers, demographers, and members of other disciplines, based on their common infrastructure of OpenGIS conformant functions.
Topic 5 is perhaps the most interesting and fruitful area within Open GIS research. Topic 5 explores the concept of "geospatial feature" and discovers that it is nearly as general as the concept of "object." Each geospatial information community establishes its own types of feature instances. For example, a transportation community may need to establish a number of feature classes that include highway, road, and lane, while a land registration may need classes for parcel, boundary, and registry. The Open GIS Consortium has defined only a single metaclass for "feature" and has opened the door for specific information communities to establish their own abstract classes, and to populate these classes with actual instances (such as a particular road or parcel).
Topic 6 concerns the special case of feature called "coverage." Coverages are distinguished by having an attribute value whose type is a coverage function. A coverage function is a mapping from a collection of geometric figures to a value set. For example, a collection of parcels may map to their areas, or to their owners' phone numbers. Interoperability of information held in coverages depends on mutual agreements on the modeling of functions and interpolation techniques. The Open GIS Consortium recently came to consensus on a suite of interfaces that allow interoperability in a subset of the coverage domain: Gridded Coverages. A Gridded Coverage is one in which the domain may be considered to be a rectangle of discrete points. The associated interfaces allow distributed clients to transparently request and receive digital images, elevation matrices, and other Gridded Coverages from clients. That is, the software takes care of the spatial reference system and other aspects of the semantics carried by Gridded Coverage. In perhaps one year's time, these specifications will be enlarged to handle more general coverages. At that time, useful coverages that reveal the current state of a subway system will be accessed by traveler's digital assistants and exploited to minimize time to destination, and coverages that describe the character of a farmer's field will be exploited to apply potash in an manner to optimize yield.
Topic 7 deals with earth imagery, and, when finalized, will specify consensus interfaces that will make earth images both interoperable and more valuable. In many ways, this topic has split into two new topics (numbers 15 and 16). The basic deliverable of associated interface specifications will be the ability to immediately bring together imagery and other forms of geospatial information (especially features with geometry and features modeled with coverage functions). The result will deliver new power and authority to weather reporting and analysis, land use and land cover analysis, remote sensing, permit processing and as-built corrections, agriculture, and many other information communities.
Topic 8, relationships between features, will provide interoperable information structures to communicate the relationship between telephone poles and transformers, for example, or the relationships between road segments, numbered highways, and bus routes. The beneficiaries will include those who model infrastructure such as water, gas, and electric distribution, and telecommunication. The ultimate impact is less expensive and more reliable infrastructure services for the entire population of the earth.
Topic 9, quality, is intended to provide interfaces that communicate the appropriateness for a specific application of an information source (or of a process) available on the net. These interfaces will ensure that accuracy and completeness of content are consistent with the scale and criticality of the application. This will enable the appearance of information sources and services that deliver a variety of qualities of service, and that can be marketed for their low price, speed of operation, widespread application, and ease of use. For example, farmers may wish to model their fields on a 10-meter scale (where each 10 meter by 10 meter plot is assumed to have constant attributes). Quality interfaces would allow the farmer to ask remote sensing sources to report their findings at a compatible resolution, thereby enabling the farmer to avoid purchasing unwanted information.
Topic 10, feature collections, reports on progress toward interfaces that allow for interoperability in the aggregation and disaggregation of features. This allows GIS designers to cope with the recursive nature of feature definitions. It seems every geospatial feature can be dissected into smaller ones, or aggregated into larger ones. Feature collection interfaces would allow for precise expression of the semantics behind the aggregation implicit in every collection of features. One positive impact: the result sets that are generated by geospatial queries will be able to communicate their meaning more precisely.
Topic 11, metadata, is, like topics 1 and 2, being developed in close cooperation with ISO/TC211. With the help of ISO and OGC, the GIS community is coming to consensus on the names and contents of essential and expanded metadata, and is beginning to agree on common metadata behaviors. The result will be catalogs that are complete, current, accurate, and easily useful for the user of geospatial information and services. A major beneficiary will be the disaster management community who will be able to find critical current information quickly and reliably.
Topic 12, service taxonomy, contains the current vision of OGC from the standpoint of a collection of services. OGC is addressing these services one at a time, but at an ever accelerating pace. Soon end-to-end services that conform to OGC standards will be available.
Topic 13, catalog services, is one of the most critical in GIS. Without catalogs, one cannot find data or services, or announce one's data and services to others. Catalogs are registries that hold information (largely metadata) that enable one to find a handle to relevant information, and thus to access and exploit it. Similarly, catalogs provide a mechanism for one to announce that one’s information community exists, or that a potentially useful data set (or process) exists, along with instructions on how to obtain it.
Topic 14, semantics and information communities, is designed to provide interfaces that empower user communities to construct their own class libraries, service taxonomies, and semantic translation tables. This topic area is huge and reaches far into the future, as semantic translation tables will be constructed joining hundreds of information communities. The result will be an environment where information collections will (perhaps virtually) contain the joint holdings of many authorities, and the owner of each feature is responsible for its integration into the whole, and responsible for extensions to the joint class library to account for it's unique features. Imagine a county data store where the water department is responsible for the water distribution data, the electric company responsible for the electricity distribution data, and so forth, yet all the features are properly registered relative to each other, and all the participants respect a common core class library. The result will be an economical data store of unprecedented utility to urban planners, infrastructure maintainers, public works initiatives, disaster management, and many others.
Topic 15, image exploitation services, addresses the special needs of the information communities that depend on aerial imagery or similar remotely sensed data for the creation and maintenance of spatial data stores. Federal and regional government agencies and large mapping organizations dominate this niche, but it is also occupied by farmers, foresters, and others who need quick assessments of land cover and land use over large areas. The scope of this topic includes photogrammetry and the measurement of ground objects based on calculations involving measurements of the images of the objects.
Topic 16, image coordinate transformation services, provides interfaces of a mechanical nature that support Topic 15. Specifically, this topic provides for the evaluation of functions (and their Jacobians) that map between ground coordinates, image coordinates, and stereo coordinate systems.
OGC develops both "core" and "domain" technologies. "Core technologies" refers to OpenGIS Specifications for interfaces that will be broadly applicable in all geospatial application areas. "Domain technologies" refers to OpenGIS Specifications for interfaces that enable diverse systems within an application domain to interoperate with respect to that domain’s special processing requirements. "Networks," for example, in telecommunications facilities management have a different meaning than "networks" in transportation management. No domain technologies have yet become part of the OpenGIS Abstract Specification, but there will be special interfaces for application domains as industries, disciplines, and professions bump up against the interoperability limitations of the "core" OpenGIS Specifications. Just as OGC’s Management Committee regularly prioritizes core specifications and includes them in the Plan and Schedule, domain specifications will also make their way into the Plan and Schedule.
There is strong sentiment among OGC members to use Interoperability Initiatives like the Web Mapping Testbed to produce OpenGIS Specifications, as opposed to creating all of them through the Technical Committee process. Phase 2 of the Web Mapping Testbed will focus on map authoring and publication, integrating graphical data and data elements (legends, symbolization, etc.), clients that can exploit XML-encoded information, further work on catalog and discovery services, and work on transporting XML encoded data over the internet. New Interoperability Initiatives, still in the planning stages, will address other capabilities. For example, the proposed Information Community Environment/Testbed will address connection of legacy databases and systems into an interoperability framework, implementing new approaches to handling geographic feature semantics. The proposed Production and Publishing Testbed will yield mechanisms for enabling data producers and service providers to connect to an interoperability framework through their value chains: e.g. from sensor, to ground station, to archive, to dissemination in the data producer case. Interoperability Initiatives offer major geoprocessing user organizations an opportunity to achieve specific interoperability objectives in a short time, and they offer geoprocessing technology providers the opportunity to recover part of their investment in OGC, become intimately familiar with critical needs of important customers, and work closely in the testbed with potential commercial partners.