Figure 4-1 OGIS is an Abstract Specification. OGIS Project Testbed partners will develop DCP-specific OGIS implementation specifications.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
The OGIS Project is unprecedented in the world of geoprocessing, but it is modeled on prior and ongoing Information Technology (IT) initiatives that seek to provide "interoperability through common specification." Likewise, OGIS itself is unprecedented in the world of geoprocessing, but it is a special application of existing distributed computing technology and object technology which are evolving rapidly, partly through the efforts of these other common specification interoperability initiatives.
Because much of this technical infrastructure is still fairly new; because not all the definitions are yet universal; and because implementing OGIS in products and projects requires an understanding of the underlying technologies, we include this chapter on basic underlying IT concepts.
The chapter presents
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
Interoperability, in the context of OGIS, is software components operating reciprocally (working with each other) to overcome tedious batch conversion tasks, import/export obstacles, and distributed resource access barriers imposed by heterogeneous processing environments and heterogeneous data. "Interoperability by means of specification" means that software developers achieve interoperability by writing their software to conform to a common, agreed upon set of criteria. Application programming interfaces (APIs), for example, have served this purpose for many years. But APIs usually require that the programmer work within a particular operating system and programming language.
A specification expressed in several layers of abstraction can become more broadly used and endure longer than a specification tied to a particular operating system (UNIX, DOS, VMS, etc.), programming language (FORTRAN, C++, Visual Basic, etc.), operating environment (Windows, X Window System, etc.), or distributed computing platform (DCP) (CORBA, OLE/COM, DCE, etc.) To enable software developers to create geographic applications that will be interoperable within and between any of today's evolving DCPs, the Open Geodata Model is tiered, with three conceptual levels. (The model can be extended to accommodate more tiers as the industry elaborates new service layers.) Following the convention, definitions, and notations in Designing Object Systems: Object-Oriented Modelling with Syntropy, by Steve Cook and John Daniels, these models are:
A similar tiered architecture is described in Object-Oriented Modelling and Design, by Rumbaugh et al, where the layers are called object, dynamic and functional. The diagrams in chapters 5 and 7 use a slight variant of Rumbaugh's OMT conventions, as defined and detailed in Cook and Daniels. The OGIS will contain the Essential and Specification Models in the core spec (OGIS Part II) and will contain Implementation Models (OGIS Parts III.A-III.n) for different implementation environments, which will be DCPs such as CORBA, OLE/COM, etc. (For a full description of the dominant DCPs, see the 1996 book by Orfali, Harkey, and Edwards, The Essential Distributed Objects Survival Guide.)
Within a particular DCP, specification can take place at a finer granularity. Within a CORBA environment, for example, common representation of the object format allows object interchange between systems and/or tools. At the lowest level, detailed syntax and protocols for making and managing requests facilitate basic communication.
Above the DCP level, standard language syntax, such as SQL2 extensions or C++, can provide a consistent application or user interface, though this will require a significant amount of additional code if the API or user interface is going to interface down to more than one DCP. At the highest conceptual level, domain-specific standards promote correctness of interoperating applications in particular domains. In the case of OGIS, this is the level of information communities with their shared geographic feature type semantics, as described in Chapters 6 and 7.
All of the major distributed computing platforms (DCPs), such as the Component Object Model (COM) from Microsoft, the Common Object Request Broker Architecture (CORBA) from the Object Management Group, and Distributed Computing Environment (DCE) from the Open Software Foundation, utilize one or more of the above mentioned specification levels in achieving interoperability among components. Furthermore, they all support the client-server model of computing. But the various DCPs differ in ways that are not addressed by any single specification language. OMG's IDL (Interface Definition Language) is the ideal specification language only for developers intending to use OMG's CORBA. (It is worth noting, however, that the ISO Open Distributed Computing Committee is currently working on a draft international standard to make standalone OMG IDL - i.e., IDL without the CORBA connection - the interface definition language international standard.)
To write a language-neutral software specification, specification developers can use a
language like IDL which has mappings to multiple programming languages, or they can write
the specification using one or more of the following: formal logic; a formal specification
language like Z; English (or another natural language); or a diagramming technique like
Object Modeling Technique (OMT) (see Object Oriented Modeling and Design, by James
Rumbaugh et al). The challenge is to write a specification that is complete and
unambiguous, independent of implementation platforms, and understandable to the target
population of developers. The OGIS Project Technical Committee originally wrote OGIS in a
combination of IDL, formal logic, and English. (OMG's IDL by itself was deemed
unsatisfactory because it does not serve the needs of implementors who are not working
with the CORBA DCP.) At the time of this writing, the OGIS Project Technical Committee is
close to making a final decision regarding the formal method of expressing the OGIS
specification. This method will include OMT diagrams, Harel state charts, formal set
theory, and English. Read Designing Object Systems: Object-Oriented Modelling with
Syntropy, by Steve Cook and John Daniels, to learn why this is a good approach.
Figure 4-1 OGIS is an Abstract Specification. OGIS Project Testbed partners
will develop DCP-specific OGIS implementation specifications.
As explained in the Introduction and illustrated in Figure 4-1, OGIS is an abstract specification rather than an implementation specification. It specifies a detailed software representation of common types sufficient to characterize virtually all spatial/temporal phenomena. It must remain abstract enough to be implementable on all of the DCPs, providing an extremely fine-grained description of what must be implemented without specifying, in terms of language or DCP, how the software is to be implemented.
To meet the need to have a standard specification for each DCP, OGIS Project Testbed participants working on a particular DCP will collaborate with other Testbed participants working on the same DCP to write the implementation specification for that DCP. In this way, the OGIS Project will produce implementation specifications for each of the main DCPs which are as close to the abstract specification as possible, and thus as interoperable with other DCPs as possible. Interoperation among and between DCPs is beyond the scope of the OGIS Project, but it is being addressed by other initiatives. In fact, the COM-CORBA interoperability specification being written by an OMG working group is nearing completion.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
Webster (Webster's Ninth New Collegiate Dictionary, 1984) provides the following definitions which are useful in the context of OGIS:
lingua franca: any of various languages used as common or commercial tongues
among peoples of diverse speech; something resembling a common language.
lexicon: the vocabulary of a language, of an individual speaker, of a set of
documents, of a body of speech, of a subject, or of an occupational or other group.
Extending these definitions to software suggests that software components and/or systems that need to communicate must do so using some lingua franca. The lingua franca for OGIS is based on a lexicon of common geodata types defined in terms of primitive data types available in all programming languages. Without this lexicon of common types we cannot hope to solve the problem of interoperability.
The lexicon that functions as a lingua franca for OGIS is the Open Geodata Model. The scope of the OGIS lexicon is limited to those vocabulary elements that are needed to communicate geospatial information. Individual vocabulary elements must be expressible in a representation that can be understood and used by communicating software components.
The Open Geodata Model gives components in the OGIS Services Model a uniform communication capability and provides the essential base for predictable domain-specific extension (where a domain is a subset of geoprocessing, such as GIS or remote sensing, or an application domain such as facilities management or meteorology. You might think of the OGIS Services Model as the grammar and syntax of the lingua franca. Together, the Open Geodata Model and the OGIS Services Model form the basis for intra- and inter-community data sharing and distributed geoprocessing.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
In conventional computer programs, the functions (or procedures) that accomplish work are separated from the data they work on. Data files are opened, or "read," by functions and the data from the files is processed by one or more functions, often creating one or more new data files. By contrast, object-oriented (OO) programs are constructed from building blocks called objects; each of these self-contained software modules includes all the commands ("methods," in object lingo) and data needed to do a given set of tasks. An object performs a task when it receives a message requesting that it perform the task. Because it is "encapsulated" in this way, an object can be reused as a unit in any number of programs. By design, object-oriented programming makes it easy to generate new objects that automatically "inherit" the capabilities of existing objects. The programmer can by this means modify methods or add new ones without starting from scratch. A geoprocessing example: a new object whose data have geographic coordinates (latitudes and longitudes) might inherit another object's ability to convert its data from geographic coordinates to Universal Transverse Mercator (UTM) eastings and northings.
This sounds great on paper, but designing the objects in the first place turns out to be a big job. OO programming (OOP) is best suited for large-scale programming projects (or specifications, like OGIS) that are likely to need modification and expansion over time.
Most members of the OGIS Project Technical Committee believe that an object approach is the ideal way to realize the goals and objectives detailed in the previous chapter. However, many of these object technology believers, most of whom are software developers, also believe that until object technology and DCPs mature (each DCP has its own object approach), most OGIS implementations will include a significant amount of conventional structured code. ("Structured code" refers to software designed such that a small central program makes calls to subroutines organized in external libraries: as opposed to the "spaghetti" code of large monolithic programs with integral functions and subroutines. This approach enables libraries called application programming interfaces (APIs) to provide a standard set of "hooks" by which a program can cooperate with other programs.)
The paragraphs below outline the aspects of the object paradigm that contribute to the idea that OGIS is best implemented in objects, as much as possible. Please refer to the bibliography for useful titles on the subject of objects.
In the OO software environment, objects interact strictly on the basis of their interfaces, which neither programs nor programmers change, except to extend them by means of inheritance as mentioned above. Encapsulation controls modification to the state of an object by dictating that changes to the object's data may be made only via the methods of the object. By providing a modular way to keep state and methods together, encapsulation also tends to facilitate more natural thinking in design and construction of systems.
Hidden behind an object's interface, the exact implementation of the object's methods and the format and layout of the encapsulated data is private to the object itself. This isolation allows users of the object (that is, programmers integrating the object into systems) to concentrate on the capability provided (as defined by the interface) and not on the details of the inner implementation. This concept of encapsulation allows OGIS to be defined using interfaces. This is highly desirable because geoprocessing developers and developers incorporating geoprocessing into previously non-geoprocessing systems are thus free to provide different implementations and to update the implementations as long as they meet the interface specification.
The ability of one object to subclass or inherit some of the
functionality of another object while overriding other functionality is called inheritance.
Inheritance of the actual implementation of an object is very useful in the context of
application building. However, it is only possible if the implementation language provides
this capability. Inheritance of interfaces, the ability of one object to reuse the
interface of another object (without reusing the implementation), is possible using most
programming languages. OGIS employs interface inheritance, providing developers the
freedom to implement using object or non-object languages, while retaining the modeling
benefits of inheritance.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
The OGIS Services Model is a client-server model. That is, it is described in terms of interfaces that client programs or client objects use to communicate with "service providers," which are programs or objects that respond to client requests by returning requested data or by providing a processing function. Not all OGIS implementations will be client-server in the traditional sense of establishing a one-to-one relationship between client process and server process. Some servers, for example, might be capable of providing multiple different services. Given this situation, it is useful to use the term "service provider" instead of "server." The lexicon of the Open Geodata Model provides the basis for a common geodata transfer and geoprocessing interface between clients and service providers.
In looking at the technology foundations of distributed geoprocessing, we concentrate on data access as a special and important case of distributed geoprocessing, because:
The OGIS data access paradigm needs to be flexible enough to provide a common interface to different storage systems, including legacy systems. Geodata stored under a storage mechanism is likely to stay there for reasons of data integrity, performance, storage availability, budget, and ownership. Databases that contain geocoded information should not have to be replicated in order to provide separate access via an OGIS data access server.
In all client-server environments, a client makes a request for service to a server or service provider. The server or service provider then provides its service in a response. In the case of transactions between OGIS-enabled clients and servers, client and server components' interfaces conform to data types and software interfaces described in the Open Geodata Model and the OGIS Services Model. The request must be made and response returned in a vocabulary, syntax, and protocol that both the client and service provider understand. Underlying request-response mechanisms are already provided by the distributed computing platforms (DCPs). DCPs have a syntax and protocol which, when combined with the vocabulary of the Open Geodata Model, provide the complete request-response capability necessary for implementing OGIS applications. Similarly, database management capability is typically accessed via a database language, which, when combined with the vocabulary of the Open Geodata Model, provides the syntax and protocol for common geodata access services.
The client-server model enables application developers to isolate the requirements and
capabilities of applications and identify the roles and relationships of components that
meet requirements at various levels. Components proliferate (bringing more choice of
functionality) and interoperability improves as layers of open-interfaced services emerge.
In general, this happens as it becomes clear that most products in a generation of
software products from multiple vendors redundantly provide lower-level services to the
higher-level, more differentiated functions available in the products. These common,
lower-level services migrate downward into a service provider layer with a standard
interface that becomes a platform for the now leaner, more portable highly differentiated
functions. Figure 4-2 illustrates the evolution of geoprocessing service providers in the
context of the evolving Distributed Computing Platform situation.
Figure 4-2 With OGIS, geoprocessinggeoprocessing can track progress in distributed computing.client-server evoloution
Figure 4-2 shows the evolution from monolithic geoprocessing toward distributed object-based geoprocessing. Taking a vertical view, looking at each scenario:
Taking a horizontal view of Figure 4-2, looking at how OGIS fits into each layer:
As noted above, implementors can create OGIS-based solutions using conventional structured programming and/or object-oriented techniques. Until DCPs and OO programming have matured, many integration efforts, including OGIS integration efforts, will involve both conventional and OO programming.
In the conventional structured programming model the server responding to a client's request checks the validity of the request and then executes the API function call that matches the request. These function calls might be executed within an address space (process boundary), across address spaces, or across machine and address space boundaries. In the latter two cases, some interprocess communication mechanism must be utilized.
The object-oriented model provides the same capability, but is usually presented to the application developer as an object API (in other words, a class library). In the case of distributed object systems, the API presented by a service provider is encapsulated as a set of object interfaces with methods that implement the service provider's service capability. Distributed object systems typically hide the address and machine boundary detail from the application developer.
We make the distinction here, because OGIS needs to be implementable
using both conventional and object-oriented
clients and service providers, to integrate
combinations of conventional and object implementations. Figure
4-3 depicts four cases to further explain the requirement for
flexible interoperability between conventional
and OO OGIS implementations. Case 1 shows a conventional client
accessing a conventional service provider via a functional API.
Case 2 depicts the object client accessing an object service provider
via an object API. Case 3 depicts the situation
in which an object client must access a conventional service provider.
To accomplish Case 3 it is necessary to insert an object wrapper
to provide the object client with the interface it needs. The
term wrapper refers to the software necessary to map one API to
another. The wrapper encapsulates the conventional service provider.
Case 4 is the reverse of Case 3 and shows that a conventional
wrapper must be inserted to provide the conventional client
with the interface it expects.
From the above discussion and figure we can distill two basic specification requirements:
Developers are using the abstract OGIS spec to structure both functional APIs and object APIs. The system of OGIS interfaces to the various elements of the modern computing environment is illuminated by the "Pluggable Computing Model."
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ]
The Pluggable Computing Model provides a conceptual framework for OGIS, defining the framework in a picture that positions the OGIS Services Model in the broad context of Information Technology. The intent of the Pluggable Computing Model is to define high-level architectural concepts, not to suggest an implementation approach or impose design constraints, except at the highest level.
The pluggable computing model describes computing in terms of the interconnection of basic functional elements (clients and service providers) and the interfaces between them. The model positions the components of the OGIS Specification Model within the larger context of Information Technology. In particular, the model defines the OGIS Services Model relative to DCPs, databases, human-technology interfaces and other non-geoprocessing software. The pluggable computing model is based on standards and is evolutionary in nature. Not all of the details are known. Not all of the applicable standards have emerged. Not all of the functional requirements, especially future needs and context, are well understood. The objective of the pluggable computing model is simply to provide a common reference for:
The pluggable computing model, shown in Figure 4-4, divides a complete OGIS application environment into services that provide specific functionality to an application. Each service element is a task-oriented entity which has a specified interface and a consistent behavior. Services are grouped to reflect basic functional areas of the computing environment.
The shaded portions of the pluggable tool model, shown in Figure 4-5, represent interfaces to services from the OGIS Services Model. Thus, noting the non-shaded elements of the larger Pluggable Computing Model diagram in Figure 4-4, you see that OGIS-based applications rely on other essential services, which are not considered to be OGIS services, such as Data Management, DCP, and Human-Technology Interface Services.
The services defined in the pluggable computing model address the three fundamental forms of system integration:
Integrators seeking to make systems open to heterogeneous geodata
will need to work with OGIS at one or more of these levels.
The kinds of services shown in the model are listed below:
In addition to defining the infrastructure services of an application
platform, the pluggable computing model
describes how application developers
use service interfaces for building tools.
As shown in Figure 4-3, at the interface of each Pluggable Tool
to Data Management Services, DCP Services, and Human-Technology
Services is an API which defines the behavior and isolates
the implementation details of the services requested and services
delivered. Tools in the model are structured packages of data
and executable code which typically reference platform services
(via their supported interfaces) in addition to their own domain-specific
or private algorithms and data.
Figure 4-5 Each Pluggable Tool has algorithms, data, and interfaces to services in the distributed computing environment.
The pluggable computing model provides a consistent basis for allocating technical functions to specific portions of each service area of the model. Consistent adherence to the model (by the authors of OGIS and by OGIS application developers) will
These benefits are the characteristic benefits of open systems and open system environments. Central to the definition of open systems are the properties of scalability, extensibility, diversity, and interoperability. These "ilities," elaborated in the following paragraphs, describe the characteristics and behavior of open system environments. The pluggable computing model helps to identify and describe the properties and behavior of services which support open system environments in general and OGIS application environments in particular.
In the next chapter we describe in detail the Open Geodata Model. Every geoprocessing system requires a geodata model, which is a scheme for representing geographic information. The Open Geodata Model provides a basis for open interfaces that translate between pairs of geoprocessing systems and geoprocessing components. The Open Geodata Model makes possible a Pluggable Computing Model for geoprocessing.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
The Open Geodata Model is an extensible information model comprised of geodata types which are coded abstractions of real-world space/time phenomena. The geodata types are core information types which can be used to model application-specific software. Open Geodata Model types are created, managed, accessed, interchanged, and manipulated by a set of interoperable software component services specified in the OGIS Services Model (described in Chapter 7). This chapter describes the Open Geodata Model in detail.
This chapter and Chapter 7 describe OGIS technically in terms of object-oriented technology and geometry. Readers who are not familiar with object-oriented technology might want to prepare by reading an introductory book such as Object Oriented Technology by David A. Taylor. Readers who are not GIS programmers but who understand basic Euclidean geometry and the computer graphics involved in applications such as CAD will be able to understand OGIS. But they should also take comfort in the fact that they can already buy geoprocessing tools and middleware that contain this expertise, and their options will multiply as geoprocessing fragments into a componentware business.
We make references to Designing Object Systems: Object-Oriented Modelling with Syntropy, by Cook and Daniels because building a standard specification for modeling the Earth's entities and phenomena in software is clearly a non-trivial project that needs a strong theoretical framework, and Cook and Daniels provide some of the best object modeling theory the Technical Committee could find. In their book, after thoughtful consideration of the relationships between reality, analysis, and design, Cook and Daniels describe three levels of object-oriented design:
All three levels of model can be built by drawing annotated diagrams like the diagrams in this chapter and in Chapter 7 which are labeled as essential models or specification models. In some cases, the essential diagram for a situation will be identical to the specification model diagram for that situation. In this chapter, which is about describing the Earth model in the Open Geodata Model, the diagrams are essential model diagrams. As of this writing, the corresponding specification model diagrams (almost identical to the essential model diagrams) for the Open Geodata Model are being developed in Technical Committee working papers. In Chapter 7, which describes an invented system of software services rather an existing situation, we show the specification model diagrams instead of essential model diagrams.
The diagrams follow the conventions used by Cook and Daniels,
which are based on OMT diagrams as detailed
by J. Rumbaugh et al in Object-Oriented Analysis and Design.
The diagrams we use in this book use only some of the symbols
used by Cook and Daniels, and the symbols are explained in the
text surrounding the figures. Not all of the diagrams in this
chapter and Chapter 7 are OMT diagrams.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
The Open Geodata Model must correspond closely with the general consensus of what is important in reality that can be modeled and manipulated by geodata applications. That is, the kind of information expressible in the Open Geodata Model must be consistent with a geodata software developer's understanding of Earth forms, systems, and processes. For geographic applications with the most rigorous visual requirements, this would be a "virtual reality" model. As a practical matter, however, all representations of the earth are abstractions or generalizations of complexity, with some aspect of symbology or presentation indicating the extent or nature of the abstraction. For example, a typical USGS quadrangle map shows features such as streams or buildings, but not with the detail a ground-based observer would see. "Scale" is a convenient way to describe degree of detail, though when strictly defined scale refers only to the relation between distance units on the map and on the ground.
Software developers will use the object types of the Open Geodata Model for modeling Earth features, a more direct and comprehensive goal than modeling map and chart features, which has been the limiting goal of some traditional GIS implementations. Nevertheless, the Open Geodata Model must accommodate the wide range of existing stores of digital geographic information, many of which have been implemented as maps in an automated form.
Geographic elements to be modelled can be categorized into two broad realms: entities and phenomena.
There are many landscape elements which have aspects of both entity
and phenomena, depending on the nature of the
interpretation. For example, a stream reach could be a unique
entity, but it could also be represented as a variable flow rate
or variable water quality index from one point to another.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
In addition to entities and phenomena, another central aspect of geographic data modeling is geopositioning. Entities and phenomena are not meaningful in geoprocessing unless they are expressed in terms of a model which positions them on or above or below the surface of the earth, and perhaps also in time. Earth measurement and coordinate systems have evolved over centuries, and new technologies allow precise automatic positioning with respect to the globe. There are numerous systems for describing the exact shape of the earth, for describing coordinate positions on the earth, and for representing these in a usable form on paper or a computer screen. The assumptions of these spatial/temporal reference systems are well-known, allowing systematic transformations between them.
In the essential model of the Open Geodata Model, place and time do not correspond to software entities, but to the physical reality of entities and phenomena to be modeled. Place is a measurable piece of the real world. Time is a point, interval, or collection of points and intervals in what we perceive as the time continuum. Time and place can be measured and surveyed, and their coordinates in a particular spatial, temporal reference system can be derived. Location is the essential model idea of place and time which is represented by geometry in the specification model. (To keep the Open Geodata Model simple and general it makes sense to unify place and time, so we use the term "location" to represent both, even though t is dealt with separately from x,y,z or x,y,z,orientation in traditions like surveying and navigation, and in diverse geoprocessing systems.)
All entities and phenomena have
location attached as part of their description in the Open Geodata
Model, in addition to attributes that are not locational.
Figure 5-1 is an essential model object diagram (more specifically, a type view) that depicts an relationship between a location (which we assume is attached to some entity or phenomenon being modeled) and the coordinate geometry used to represent the locationally important aspects of the entity or phenomenon. Each rectangle in a type view represents an object type and lines between rectangles represent associations between object types. The name of the object type appears at the top of the rectangle, separated from the rest of the contents by a horizontal line. The remainder of the rectangle holds value-typed properties (integer, date, number, size, etc.) of the object type. The small black circle indicates a set, which means that a Location can have more than one Coordinate Geometry. The half-oval symbol indicates that the Spatial Temporal Reference System is an association property of the association. The small diamond symbol is used to depict aggregation, which here describes the relationship between a location and a coordinate geometry. Aggregation, as defined in Cook and Daniels, means dependence of existence. In this type view, the diamond symbol expresses the fact that a semantically correct coordinate geometry cannot exist without a real world location that it references and the spatial/temporal reference system that it uses to reference it. Described another way, a location has one or more coordinate geometries that describe its spatial/temporal domain (the subset of space and time occupied by the entity). Spatial/temporal reference systems and coordinate geometries are further defined in Section 5.9.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
The Open Geodata Model provides a common means for abstracting the Earth and Earth phenomena, both mathematically and conceptually. Both mathematical and conceptual views are in the domain of the essential model.
We present Figure 5-2 to show that the Open Geodata Model does not define for a professional discipline or an application developer the specific kinds of geographic entities and phenomena which can be described, but rather the Open Geodata Model specifies a general and flexible mechanism by which those concepts and their associated vocabularies may be articulated. That is, it does not define what a road network or a road map or a road is; it provides building blocks of (in this case) linear geometric features which can be described or annotated by additional descriptive attributes to represent a road, whether the road needs to be represented conceptually or mathematically. Similarly a Landsat scene is not a type of object in the Open Geodata Model, but it may be represented by an appropriate grid type with relevant metadata.
The two fundamental geographic types are features and coverages. Both features and coverages can be used to map real world entities or phenomena and their corresponding specific, conceptual views to an Open Geodata Model representation.
Coverages have all of the characteristics of features, and therefore, features and feature collections are the central Open Geodata Model elements and are the primary unit of access, management, manipulation, and interchange in the OGIS Services Model.
What is the difference between a feature and a coverage? A city defined
as a feature does not return a value for each point. At a given point, it may contain
another feature, or it may contain a coverage, but by itself does not return a value. A
city defined as a coverage returns for each point a value, such as an elevation or an air
quality index value. A coverage, however, can be derived from a collection of features: We
could start with a collection of features and use one or more attributes of these features
to define a coverage, the value of the coverage at a point being the value of the
attribute of the feature located at that point.
Figure 5-3 OGIS feature essential model
Typically, there are three component parts associated with features (as depicted in Figure 5-3):
As we will see later, all of these components are not strictly required by the Open Geodata Model. For example, a user of the Open Geodata Model can create a feature that has no geometry and therefore no spatial/temporal reference system (i.e., no location). However, because OGIS is designed for use in geographic applications, most features will have a location.
Features are defined such that they can be used recursively, which means that features may contain many sub-features that contain, in turn, sub-features. Features can contain a collection of sub-features or coverages which form a logically consistent grouping, in terms of resolution, accuracy, content, and context, in order to give modellers and developers flexibility to create logical and efficient systems. But developers and the users of their software need to be careful, because this recursive feature also makes it possible to create logically inconsistent collections. As illustrated in our example in Chapter 1, such inconsistency is a serious problem for anyone integrating data from different sources. Geodata interoperability will make it easier to integrate data, but both developers and end users will need to learn how to manage error and inconsistency. Depending on how the software is constructed, it may or may not be possible to compare and correlate information between feature sets to catch and resolve inconsistencies in resolution, accuracy, content, and context. Special OGIS Services Model components may be required to deal with the ambiguities and artifacts found in comparing and correlating data between disparate features (features constructed, for example, outside the control of a particular implementation or domain group) .
The feature type, as shown in the more detailed essential model type
view in Figure 5-4, has a set of properties, each of which is distinguished by a
qualifier (diagrammed using the small rectangle at the end of the association line). (The
qualifier corresponds to the attribute name in a relational model, or the member variable name
in an object oriented model.) Each property also has a value from the types chosen for
that property ("Coordinate Geometry" and "Any" in the diagram). The
qualifier and property types for a feature type are defined in a schema (see also
Section 7-1 and Figure 7-1). A schema is a description of a feature's attributes, or more
specifically, the specific attribution model for a feature in terms of primitive data
types and constraints on these types. A subset, potentially empty, of the properties are
of type Geometry and represent the spatial-temporal extent of the feature. Specific
property interfaces could include information on the data, such as accuracy information,
the object class of its value(s), and if it is NULL (has no value).
Figure 5-4 More detailed essential model of OGIS Feature Type
Feature instances are identified by an object identity (often known as an object ID or OID). The OID is unique for each feature in all data sets everywhere through time. Implementation of OIDs is left to the implementation models. Because OID is a proper type (typically implemented as a formatted string or a long integer), it can be used as a value of a property. As such, an identity-valued property represents a feature-to-feature relation. This places properties and relationships (or channels, one-way pointers) within the schema at the same standing. The use of OIDs corresponds to pointers in object systems and reference values in SQL3 based relational systems. The property set type is an abstract class that acts essentially like the row object in a relational database with abstract data types (ADT) for attributes. This is consistent with either an object programming implementation such as C++, OLE, or CORBA, or an object-relational implementation such as in SQL3.
Note in Figure 5-4 that the relation between property set and geometric property is the source and control of the relation between reference system and geometry. This means that for a geometry-typed property in a property set, the reference system is determined by the feature schema.
Since there is no limitation on the type of a property, features have a derived relation to other features that they might reference as properties.
As diagrammed in Figure 5-5, coverage is a subtype of feature (notice
the triangle "subtype" symbol) that has pairs of distinguished, or defining,
properties consisting of a geometry property and a function that is defined over the
coordinate set that is defined (delineated) by the geometry. In implementations, the
function may be defined differently for different sets of geometry. In this sense,
coverage acts as a collection class for stored functions from points to instances of a
value type. The relation between geometry and spatial reference system is the same as that
in feature, and is not repeated in this diagram.
Figure 5-5 Coverage Type essential model
The function is "stored" in the sense that it must be finitely representable to be implemented. This can be done in several ways:
Notice that the range relation is to the class of type, and not to
particular values.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
The Open Geodata Model defines a model for describing the semantic properties of a feature. The model for describing semantic properties is an attribution model (as we saw in Figure 5-4). Features have a collection of properties associated with them. These properties can be arbitrarily complex as long as they are expressible as types under the Open Geodata Model. For example, a soil type attribute may contain simply a name such as "silty loam", or it may also contain a large set of parameters like pH, density, and so on.
As with reference systems, it is necessary to provide descriptions of the attribution
model chosen for features and families of features. Therefore, the semantic component of a
feature includes its schema (a description of the specific attribution model for the
feature in terms of primitive data types and constraints on these types). From the soil
example in the previous paragraph we might expect an attribute schema similar to the
following:
Property Name |
TypeType |
Constraint |
| pH | float | 0.0 <= pH <= 14.0 |
| density | float | ... |
| ... | ... | ... |
In the OGIS Services chapter, we further refine the attribute schema concept and present the feature registry. These registries are used to contain a set of feature schemas for use within and between groups of domain users.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
In Part 2 of OGIS, the role of well known structures will be explained in detail. For the purpose of this book, which is a higher level guide, it is sufficient to note that everything in the Open Geodata Model and the OGIS Services Model can be expressed ultimately in well known structures, which are primitive programming types such as float, integer, etc. For example, the curve type is constructed with a line string (which is a set of coordinate points and the lines that join them) and the description of a reference system. A curve type will have an operation that returns a line string. All types in the OGM will have well known structure representation which will be used to construct instances of those types and which will be the result of asking those types for their well known structure representations.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
The Open Geodata Model needs to accommodate descriptions of the metadata that are associated with features. The need for and type of metadata vary widely from application to application. Thus, as with semantic properties, a generalized mechanism must be provided. In fact, it is not clear that metadata need to be associated with features at the individual feature level, but rather at the level of collections of features.
Metadata is simply a subset of the properties of a feature (or, more typically, of a feature collection) . For example, a property of a coverage representing an aerial photograph may contain simply a name such as "date flown" and a value from a date type. These properties are no different than other feature properties and can be arbitrarily complex as long as they are expressible as primitive data types under the Open Geodata Model.
As with feature properties, it is necessary to provide descriptions of the metadata element model chosen for features and/or families of features. Therefore, the metadata component of features will include the metadata's schema, which is a description of the specific element model for the metadata in terms of primitive data types.
From the example of the previous section we might expect an element
schema similar to the following:
| acquisition date | date |
| percent cloud cover | float |
| ... | ... |
In the OGIS Services Model chapter, we further refine the Open Geodata Model's metadata concept and describe metadata packages and the metadata registry. These registries are used to contain a set of metadata schemas for use within and between groups of domain users.
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]
Geographic applications deal with a wide range of geometries. The Open Geodata Model must provide the capability to deal with geometries independently of the specific geometric representation chosen by the application. What this means is that the model of geometry must be general and all-inclusive, providing a baseline representation with which all applications can reasonably coordinate for the sake of interoperability.
Because of the nature of geodata entities that need to be described in geographic applications, OGIS needs to express zero, one, two, and three dimensional topologies. Therefore, the following geodata types are defined in the specification:
OGIS features will allow for descriptions of geometry that include sets of the above types. For example, the geometry of a well field might be described as a set of points, the territory of the United States might be defined as a set of areas (closed curves), and so on. In some applications it may be necessary to define as separate types complex geometries which are combinations of the above.
Regardless of the underlying implementation, all geometries within OGIS must be able to report a coordinate geometry representation.
Geometry is the combination of a coordinate geometry and a reference system. Coordinate geometry consists of as many as four items:
Simple geometry instances are associated with a number of coordinate points that are mapped to "real world" points through the use of a spatial/temporal reference system that is constant for that particular geometry. More complex geometries can be constructed through the use of some number of simpler geometries, but they must all use the same spatial/temporal reference system. A complex polygon, for example has an external boundary and one or more "holes" defined by internal boundaries. Each simple polygon in the complex polygon is defined by a set of rings which can each be represented as a simple, closed line string (a sequence of points with linear interpolation) or as a simple (non-self-intersecting) closed curve. Similarly, any class of geometry will have an interpretation scheme associated with it that uses the associated coordinate points to perform a coordinate geometry construction that defines the extent of the geometry. The depth of the recursive definition can be as deep as needed for a complex geometric construction, but the spatial/temporal reference system must remain constant throughout the construction.
This is indicated in Figure 5-6 by the relationship from spatial/temporal reference
system to coordinate geometry, which is a subset of the relationship to the geometry.
Objects of the geometry type should be able to dump their coordinate descriptions into
well-known structures (such as line strings or closed curves, as in the above example) for
use in inter-object communication and message sending.
Figure 5-6 Geometry essential model
Coordinate Geometry attributes are:
Coordinate points are the zero dimensional coordinate geometries. The additional coordinate point attributes are:
[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ]
Reference systems define how coordinates are interpreted within the geometry of a feature. For example, the geometry of a sales region that changes over time might be defined by a spatial/temporal domain represented as a closed curve (polygon) whose coordinates are expressed in latitude, longitude, and time. Alternatively, the coordinates might be expressed in latitude and longitude with the time component being expressed within the properties of the sales region feature.
OGIS accommodates as many reference system types as possible. Specialization of these
types will be allowed; however, there must be a description that accompanies the
specialization, and the description must follow the model for general description for a
type. A reference system description must provide the fundamental information needed to
reconstruct the reference system within a different implementation environment. For
example, a vector space description must include a name, a number of dimensions, and a
list of names for the basis vectors. Additionally, the type, allowable range, and units of
values for each coordinate describing a point in the vector space might also be required.
Coordinate transformations are needed to transform coordinates in one reference system to
those of another. These transformations must be locatable in the software environment,
they must be invocable, and they must include a description of a well-defined set of
transformation parameters.
Figure 5-7 Simple spatial/temporal reference system transformation example.
Figure 5-7 shows an example of the use of a parameterized transformation between two reference systems, based on descriptions of the two reference systems. The example depicts the importing of a building footprint from a CAD system into a GIS. The CAD system defines the relationship between coordinates in the building outline. In this example, the coordinates are defined as floating point numbers that represent feet relative to one coordinate that serves as the origin. Information within the GIS is expressed in latitude-longitude coordinates. In order to transform the coordinates in the building outline, we need a transformation which accepts 1) coordinates in a 2-dimensional Cartesian system in feet and 2) the offset of the origin in latitude-longitude degrees, and which generates from these latitude-longitude coordinates. Within the transformation code, the coordinates of the outline would be changed from feet relative to the origin to coordinates in latitude-longitude degrees.
Note that in this simple example, we don't deal with the altitude of the coordinates. We simply assume that the coordinates fall on the surface of the Earth. If we had more information (for example, a digital terrain model) we could have also handled the vertical dimension.
This example points out some of the capabilities that will enable OGIS to support a wide range of geographic applications. OGIS will provide the following for the purpose of establishing each feature's location on the Earth:
Given geometry (which is essentially nothing more than a set of tuples), a spatial/temporal reference system finds locations. The reference system gives meaning to the geometry. It maps coordinate geometry constructions of the appropriate dimension to actual terrestrial locations (which is why it is shown in the object diagram in Figure 5-8 as an attribute of the aggregation relationship between location and coordinate geometry). A coordinate geometry's spatial dimension is the number of coordinate dimensions it uses to describe spatial location (usually 0, 1, 2, or 3). Its temporal dimension is the number of coordinate dimensions it uses to describe time (usually 0 or 1, i.e., a moment or an interval). The coordinates for space and time are separated, under normal usage, with the spatial coordinates coming first.
The reference system works on 'geometry' in general, not solely on points. This is reflected also in the action of transformations (see Figure 5.7). The locate function (one of the attributes of the Spatial/Temporal Reference System type) is a logical interface in the sense that it crosses the boundary between the software system and the 'real world.' To physically complete this feat, someone would have to go out and walk about measuring things (such as with a GPS) until the appropriate place was found. Time does present a more philosophic problem, since it is hard to wander around in it. Luckily, we are all well accustomed to perceiving time only as a measurement. The normal interfaces for a reference system are transformations that map coordinate sets to other coordinate sets in other reference systems. It may be that, within a particular domain group-domain group-->, a particular reference system is chosen as the standard. In this case, transformations to and from this community standard act like a locate operation.
Spatial Temporal Reference System attributes are:
Figure 5-8 Spatial Temporal Reference System and Coordinate Geometry essential model
Transformations map coordinate geometry in one spatial/temporal
reference system to coordinate geometry in another. The validity and accuracy of a
transformation are determined by how well it preserves the associated locations. In a
perfect world, transformations would perfectly preserve location. In a realistic world, we
have to give them an error budget for both absolute and relative accuracy. Error budgets
for absolute accuracy come in two numbers: an error limit, measured as a distance
(circular error) and a confidence level (measured in percentage). One interpretation is
that the confidence level percentages of the points are transformed within the error
distance of the right answer. Relative accuracy adds a limit distance, and can be loosely
interpreted as two points within the limit of one another being transformed so that the
distance from one another is changed by no more than the circular error. The confidence
level indicates a minimum probability that this happens.
Figure 5-9 Spatial temporal transformations essential model
Since a transformation cannot create data, the dimension of the domain (the input) of the transformation must be equal to or greater than the dimension of the range (the output). If the two dimensions are equal, then the transformation may be invertible (over some it its range). If the range is of smaller dimension, the transformation may still be invertible to a projection of the appropriate dimension of the original domain.
Base Information Definitions are made up of the reference system, geometry, feature, and metadata descriptions used within an application context or domain group.
An open geoprocessing application environment requires consistent implementation of the Open Geodata Model so that applications can interoperate and share data from the same data model. A Base Information Definition is an information model that provides a common, logically consistent definition of the elements from the Open Geodata Model used within an OGIS application environment. It includes elements from all of the component categories given above and provides unambiguous definitions for these as they are used within an application context. The purpose of a Base Information Definition is to limit the technical and institutional overhead associated with those operations within an OGIS application environment that deal with geodata inconsistencies and ambiguities, particularly when comparing and correlating geodata between features. Thus an OGIS-compliant application which relies on these databases may be optimized to handle a specific Base Information Definition.
The Base Information Definition is important because practical geodata and geoprocessing interoperability is not possible unless users of an application environment have a common understanding about their data in terms of characteristics such as information content (semantics), accuracy, and precision, and also a common understanding about some of the services involved in using the data. Establishing a Base Information Definition can both facilitate and enforce rigorous resolution of inconsistencies as features are introduced to an OGIS application environment.
Of course, we live in a very heterogeneous world. A given OGIS application environment may have more than one Base Information Definition, due to the practical limitations of the available source data that are used to construct the databases, or the existence of several applications within the environment which have disparate data needs and have no requirements to interrelate these data. Thankfully, as described in the next chapter, OGIS application environments may share data from disparate Base Information Definitions. These cases require that OGIS Service Specification Model components be able to deal with geodata inconsistencies and ambiguities as geodata are exchanged, compared and correlated.
The next chapter will further elaborate on the importance of Base
Information Definitions and will detail how groups of domain users
can use this idea to build what we call Information Communities.
Chapter 7 will then provide a model for constructing and using
Base Information Definitions in the context of OGIS Services.