1. OpenGIS background and concepts
UniPHORM: OpenGIS

2. Why OpenGIS? Extend Open Systems benefits to GIS
Achieve “inter-operability” between systems, data, functionality
Establish a “common language” and “unified model” for GI
Open Systems as an idea now exists for many years and has born fruit in several areas within IT (Information Technology). Many developments have already entered the mainstream in a way that we probably do not recognize the benefits properly - since we do not really remember how we could do without these specifications: just think of standardisation efforts for the UNIX operating system, for database access and networking protocols!
All these initiatives have focused on the theme of interoperability between components of complex systems. Interoperability across products from different vendors on heterogeneous and distributed platforms, between data sets and functions (operators, algorithms).
What does this all mean for GIS? These undoubtely are complex systems, and have until a short time ago suffered from the proprietary nature of most products on the market. OpenGIS is an ambitious attempt to remove these stifling obstacles and to create an open environment for geographic information processing where all ‘components’ can work together through a defined set of interface specifications.
Creating a common language between GIS components is the target we are aiming at, and it will require a well thought out approach to modelling geographic information.
UniPHORM: OpenGIS

3. OpenGIS benefits Integration with component computing standards
Quick and efficient development cycles
Avoid data transfers and redundancies
Protect investments - future proofing
Since the effort to design and implement OpenGIS is quite considerable, we cannot embark on this venture without having a clear understanding of the benefits of successful completion. Some key benefits are:
Remaining in line with a strong general undercurrent in computing. For years development has gone into the direction of component-based software and inter-component communication (e.g. OLE/COM). In order for GIS to become technically compatible with standard IT architectures, a move like OpenGIS is actually an undispensable must.
With systems becoming more and more complex with every revision cycle, there is an acute danger that current system architectures will become unmanageable in a short period of time. Component architectures enable rapid development methodologies, making application development and maintenance much easier.
Currently, moving data between systems is a tedious, expensive and error-prone task. OpenGIS aims at enabling direct operations on data sets in their respective native formats (= inter-operability!)
Development of software and data is expensive. Only wide and sustained use will ultimately justify incurring that cost. Interoperability of functional components and data sets is key to improving the business models involved.
UniPHORM: OpenGIS

4. Definition of OpenGIS®
OpenGIS – Open and interoperable geoprocessing, or the ability to share heterogeneous geodata and geoprocessing resources transparently in a networked environment. “The highest level of the interoperability specification.”
OpenGIS Specification (“OGIS”). A software specification that enables geodata sharing and geoprocessing interoperability. An interface standard for interoperable geoprocessing.
Open GIS Consortium, Inc. A member-based consensus forum dedicated to the development of OpenGIS technologies and the integration of geoprocessing into enterprise computing.
“OpenGIS” is used within a set of different contexts: for the concept of OpenSystems within GIS; to name a set of related specifications required to implement OpenGIS concepts; and as the name of the consortium working towards these goals.
OpenGIS concept: sharing of data and functionality without data transfers requires documented and freely available (“open”) interface specifications. Only then it will be possible to perform standard requests over a network against a service and receive the required response from any OGIS-compliant server.
The OGIS specification is an INTERFACE standard - as opposed to many DATA (TRANSFER) FORMAT standards previously and currently developed.
The Open GIS consortium.
UniPHORM: OpenGIS

5. Technology Development Overview
Develop technical specifications for interoperable geoprocessing
Develop an Abstract Specification that is independent of computing platforms
Becomes more comprehensive over time
Map this one specification to Implementation Specifications particular to computing platforms
Completed in stages, by functional capability
May introduce Abstract Specification changes
Maintain and revise specifications as needed
Technical specifications are being developed on two distinct levels:
Abstract specifications formalize concepts; these can be mapped on one or several
Implementation specifications, which take into account different options for inter-process communication available on specific platforms and computing environments.
Examples for different implementation specifications of the same abstract concepts are CORBA, COM and SQL. Full completion of these implementation specifications is optional.
UniPHORM: OpenGIS

6. OpenGIS Abstract Specification Request for Information
Technology Development Approach Implementation Specification Development
OpenGIS Abstract Specification
2.0
Implementation
Specification
Request for Proposal
Request for Information
Request for Proposal
Schedule of developments
To formalize the step from abstract to implementation specification, there are several possible routes to go:
OGC can issue an RfP (Request for Proposal) if it is agreed that the abstract specification is already stable and implementation is very likely to succeed right away.
If a more cautious approach is warranted, an RfI (Request for Information) is issued first, which may be followed by an RfP. Using this approach, it is possible to identify potential trouble spots early on.
Only if the mapping of an abstract specification onto an implementation is rather unclear, or if some further discussion of alternative implementation strategies is prudent, OGC may first issue an RfC (Request for Comment) before proceeding any further.
These alternative approaches are discussed in more detail on the following pages.
Request for Comment
UniPHORM: OpenGIS

7. The OpenGIS Abstract Specification
Current version has an Overview and 14 topics
New topics are on the way...
The Topics:
1. Geometry Structures 2. Spatial Reference Systems
3. Locational Geometry 4. Stored Functions/Interpolation
5. The OpenGIS Feature and Feature Collections
6. The Coverage The Earth Image
8. Feature Relationships 9. Quality
10. Transfer Technology 11. Metadata
12. Services Architecture 13. Catalog Service
14. Semantics and Information Communities
The OpenGIS Abstract Specification is nothing less than a broad conceptual approach to an overall systems architecture for geographic information processing. As such a wide range of important topics needs to be covered.
The current list of topics is going to be enhanced and probably restructured in the future. These topics are the top level work items the OGC deals with. Topics can be structured and broken down into smaller chapters which then can be implemented using the RfP process.
Some of these items are worked on in partnership with other institutions across the world, with OGC serving as the coordinating platform.
This list is clearly drawing on previous experience generated at ISO (“International Standards Organisation”, see below) and other attempts at thestandardization of geographic information.
UniPHORM: OpenGIS

8. NETWORKS AND CLIENT/SERVER TECHNOLOGY
OpenGIS Specification Enables Transparent Access to Heterogeneous Geodata
Interfaces based on the
OpenGIS Specification
File Format
File Format
File Format
File Format
NETWORKS AND CLIENT/SERVER TECHNOLOGY
From the individual user’s perspective, one desirable outcome will be the free and open accessibility of geographic data across the traditional boundary lines of data formats.
Communication between systems using an agreed OpenGIS interface layer is enabling direct access to geospatial data sets in other vendor’s proprietary formats, generic databases, simple file based formats and even real-time data streams originating e.g. from GPS positioning services.
Using today’s ubiquitous connectivity through the Internet and other network services, this ultimately means that “all” spatial data sets within OpenGIS compliant data servers are in principle transparently accessible.
This is not only valid for all kinds of long transactions involving substantial work on major chunks of data, but enables real-time access to individual data items on the object / feature level for e.g. navigational services and queries.
The “blue disks” on the diagram clearly point out the character of Open GIS as that of an interface standard: data storage and processing can remain in established, vendor-specific environments. Only an interface layer needs to be added to achieve OpenGIS compliance.
File Format
File Format
File Format
File Format
File Format
File Format
File Format
Traditional
DBMS
Non-traditional
DBMS
File
Format
Real-Time
Data Feed
UniPHORM: OpenGIS

9. The Migration from Traditional GIS
Yesterday
Future
Application
Monolithic
GIS
Proprietary
or Generic
DBMS
Connection
Application
Spatial DB
Middleware
Traditional
DBMS
Universal
Server(s)
(spatially-
aware)
Application
Application Services
Proprietary
APIs
Open
APIs
The changes triggered by the OpenGIS initiative obviously will not only be visible from a data user’s perspective. One of the consequences - as we’ve already briefly mentioned before - is the disintegration of GIS software monoliths. As a first step, several vendors have already started to define interfaces between applications (GI functionality) and data stores. In some instances it was necessary to introduce a separate “middleware” layer in order to fulfill GI-specific requirements for geodata access like spatial indexing, seamless access and spatial search and retrieval. Still, interface layers between modules are mostly proprietary.
One current trend in industry is for DBMS to become “spatially aware” within the framework of universal servers, supporting “all” kinds of multimedia data. Since vendors of generic DBMS products have a vested interest in supporting a wide variety of clients, interfaces are designed to be open. Geographic data can then be accessed through data services, as well as specific spatial functionality is available as “services” to other components. Ultimately, market forces will most likely lead to all interfaces between components to be openly accessible.
UniPHORM: OpenGIS

10. The Goal of Open Geoprocessing
DATA
RESOURCES
PRECESSING
RESOURCES
USERS
Cadastral
Water resources
Land Use
Zoning
Highway
Traffic
Transit
Water supply
Sewer
Storm drains
Gas & electric
Telecom. lines
Political
Surface geology
Hazards
Public safety
Population
Real-time feeds
Earth imagery
Industry Markets
Utility Companies
Telecom
Civil Engineering
Niche Integrators
Petroleum
Intelligent Transport
Public Markets
Environment
Resources Mgmt
Infrastructure
Urban Planning
Disaster Relief
Public Safety
IVHS
Business Markets
Real Estate
Insurance
Banking
GIS
Earth Imaging
CAD
Mapping
GPS
Navigation
Facilities Mgmt.
Database software
OODBMS
RDBMS
Universal server .
Desktop publishing
Document imaging
Workflow
Decision support
The component philosophy of OpenGIS leads to a three-tiered structure for geographic information processing. These three blocks are the corner stones for overall system design:
end user applications
GI processing components
geospatial data services
User requirements from generic application segments (like public works, oil and gas, forest management, urban planning etc.) are supported by applications built from a vast pool of processing components provided by software vendors. These components in turn access data services as needed for the specific application.
In terms of an overall services architecture, we can therefore distinguish two classes of GI services
processing services (functions, routines, algorithms, transformations) and
geodata services
UniPHORM: OpenGIS

11. OpenGIS: Dynamic Interoperability
Database Server
catalogs schema coord system geodata
Database Client
schema coord system geodata representation
As opposed to static and redundant transfers, OpenGIS aims for interoperability in a dynamic environment.
Without any transfer of whole data sets, the network brings requests from various clients to a database server. As long as OpenGIS interface specifications are implemented according to one of the supported interoperability protocosl, the server fulfills the request according to the given criteria and responds by sending a collection of features back to the client.
This results in a number of obvious advantages:
data are up to date as of time of query
only data required are provided, not whole bulky data sets
interaction with original data is possible, e.g. to refine selection criteria
client does not need to know anything about proprietary structures inside the server database
All of this adds up to the chance to move freely in a whole world of geographic data, without any need to worry about proprietary environments.
(Still, the client needs to find out a lot about a given data set regarding usability and fitness for a specific use - we’ll look at this closely in the metadata chapter!)
Requests, Features, & Collections
CORBA - OLE/COM
UniPHORM: OpenGIS

12. Architectural Layers in a GIS
Component Ware
Application
Distributed Objects
Application Server
Metadata and Query I/F
Database Server
Presentation
From a system architecture viewpoint, GIS are increasingly clearly structured into 3 or 4 layers. These layers are bound together by the glue of interfacing standards - the actual substance of OpenGIS!
Database servers are accessed directly or through catalog services. Metadata support identification of suitable data sets, which are then queried by requests for specific objects.
These requests originate either from an application server (there are only few examples for this layer currently available) or directly from an application.
Applications as well as the presentation layer are built from software components, which in turn interact by functional requests.
Comparing this structure to the way many traditional textbooks look at the architecture of GI systems, we recognize that this layered approach was not present in the same way. To reach the objectives of the OpenGIS initiative, it is necessary to define a clearly structured scheme of mutually interoperable services.
UniPHORM: OpenGIS

13. Managing the Geospatial Library
G/NSDI
Stakeholders
FGDC
OGC
OMG
WWWC
ISO
Sister
Disciplines
How do we maintain and manage this whole ‘library’ of specifications once it is completely in place? This will be a task beyond the sole means of the OGC and will require the cooperatin of a number of individual stakeholder agencies and associations. Most likely - for the time being - the OGC will serve as a central coordinating body where various interests are brought together.
Specifications will have to change and grow over time as the industry, technology and needs evolve. Maintaining this huge body of knowledge and structural understanding will be the ultimate test of success for the strength of common interests within the OGC membership.
Before we can get to this point, though, we need to be able to bring the OpenGIS specifications into practical operations in all our respective fields of application. To do this in a well informed and competent way - this actually is what this course is all about !
UniPHORM: OpenGIS