Make your own free website on Tripod.com

[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ] [ Next Section ]


4. IT Foundations of Interoperable Geoprocessing


4.1 Introduction

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 ]

4.2 What is Interoperability by Means of Specification?

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.

4.2.1 OGIS is Independent of Distributed Computing Platform (DCP)

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 ]

4.3 Open Geodata Model Provides a Common Spatial Language

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 ]

4.4 Object-Orientation

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.

4.4.1 Encapsulation and Interfaces

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.

4.4.2 Implementation Inheritance versus Interface Inheritance

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 ]

4.5 Clients and Service Providers in the OGIS Context

4.5.1 Introduction

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.

4.5.1.1 Distributed Computing Definitions

  • Clients - Clients are components, within a client-server context, that require a service. Even though clients may also provide service to higher order clients in the client-server model, the fundamental aspect of clients in all of the following discussion is that they are the requesters of some service.
  • Service Providers - Service providers are components, within a client-server context, that provide a response to a specific client request for service. Even though service providers can also be clients in the client-service provider model, the fundamental aspect of service providers in this discussion is that they are suppliers of some service.
  • Data Access Servers - Data access servers are components, within a client-server context, that provide data access in response to a specific client request. Even though data access servers can also be clients in the client-service provider model, the fundamental aspect of data access servers in this discussion is that they are suppliers of access to data.
  • 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.

    4.5.2 OGIS in the Context of Evolving Client-Server Models

    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:

  • Presentation Layer: Applications increasingly rely on user interface resources in the operating environment (X Window System, Visual Basic and "Controls," etc.) instead of a user interface that is proprietary and tightly coupled to the application. To manage a variety of cartographic and interactive data manipulation issues, this layer will need OGIS interfaces. Even if the underlying services that the user interface invokes, such as a region function or a viewscape function, are located on different platforms and operating systems, the portion of the application "closest to the glass" will need a particular interface to OGIS. For example, if a developer wants to include and exclude certain classes of geographic features or labels for display while the user is viewing a geographic image and zooming in and out, the user interface will need to communicate with the Application Server Layer or other underlying layers that store or manipulate these features. In this book, we will call user interface and associated process management the human-technology interface.
  • Application Layer and Application Server Layer: Applications in general, even in desktop computing environments, are becoming increasingly component-based, shedding direct responsibility for common functions such as graphic display and user interaction, as well as printing, faxing, and online help. Such common functions become available as Application Servers, always available in the operating environment to any application request that conforms to their service interfaces. As explained above, geoprocessing applications are just beginning to go through this change, giving up common geoprocessing functions into a shared pool of Application Servers available in the computing environment. Geoprocessing "applets" and the geoprocessing middleware below them will communicate through OGIS interfaces. These "lightweight" applications are easy to write because they can provide services through easily written interfaces instead of integral subroutines. The user benefits because an abundant selection of niche products appear, geoprocessing "applets" appear in previously geoprocessing-barren application domains, and integrators can inexpensively and quickly integrate applications into workflow solutions.
  • Spatial Data Access Provider Layer: Spatial Data Access Providers bidirectionally translate application semantics and database semantics. For example, an application sending a query to a database will likely send the query in terms of a particular geodata model, whereas the database understands only SQL or a proprietary query language. In addition to mediating queries and responses, this layer enables Applications and Application Servers to access other database management services related to security, version control, etc. Included in this layer are currently available commercial products that give GIS applications an interface to specific general purpose relational database management systems. In the future, proposed OGIS-based middleware at this level will give any OGIS-based application access to data in any database management system equipped with the middleware.
  • Database Layer: We use the term "database" to refer to a database management software product such as Oracle or Access, not simply a collection of geodata. Major database vendors have become more interested recently in offering database products that accommodate geodata, which benefits the geoprocessing community because 1) modern databases are fast and offer a range of features such as security and version control which may not be available in traditional proprietary spatial database systems, and 2) integrators and their customers can more easily integrate geoprocessing into software and decision processes when the users' geodata resides in the same database as the users' other data. In the OO future, traditional databases may yield to ubiquitous data objects. In the present, most geodata (especially if Earth imaging data is considered) resides in files and directories that have consistent structure but none of the flexibility and power of a modern database. Some of these geodata stores are currently accessed through special purpose (and usually quite limited) query systems which could be fitted with OGIS interfaces; but probably most of this geodata will instead be transferred in the next five years into modern databases that are much more capable than older databases of managing huge volumes of non-tabular data.
  • Hardware and Network Layer: DCPs and hardware and network standards make the hardware and network layer transparent to geoprocessing issues.
  • 4.5.2.1 OGIS is Implementable using OO and Non-OO Techniques

    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.


    Figure 4-3 Conventional and object-oriented clients and service providers. A developer can use wrappers to integrate disparate client-service provider pairs.

    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 ]

    4.6 The Pluggable Computing Model - OGIS in the Overall IT Context

    4.6.1 Introduction

    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.

    4.6.2 Technology Context -How OGIS Relates to Non-Geoprocessing Software

    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.


    Figure 4-4 The Pluggable Computing Model depicts interfaces essential to OGIS.

    The kinds of services shown in the model are listed below:

  • Human-Technology Interface Services include the familiar features (such as windows and a pointing device on a computer) that enable a user to interact with an information appliance. Building on these basic service elements, another Human-Technology Interface Service is a Graphical User Interface (GUI) that adheres to a standard style guide to produce a consistent look and feel across applications. These services support separation of visual presentation and related behaviors from the underlying Tools Services (see below) that drive those behaviors. Human-Technology Interface Services services also incorporate problem domain and organization-specific issues of workflow control, task sequencing, and event notification. Services in this group may include management, documentation, evaluation, assessment, policy-enforcement, maintenance, and other activities. For example, an integrator might use Visual Basic to create a customized user interface to facilitate a department's global order processing operations. User manipulation of geographic displays of factors related to order processing would be performed by the custom interface cooperating with one or more Pluggable Tools.
  • Tool Services provide any of the additional functionality needed to support the end user and the application. Examples of Tool Services include functions for program manipulation (as opposed to user manipulation) of data objects (e.g., manipulation of geodata, imagery, graphics, audio and video), interchange of data between external formats and environments, and analysis of data in support of workflow or decision-making processes. (Many current vendors of monolithic GIS products will likely become vendors of GIS tools - components and applets - as the general computing model moves in the direction of the Pluggable Computing Model.)
  • Data Management Services deal with the management of structured data, text, imagery, graphics, and other data such as voice and video that are defined to be independent of the processes that create or use them, maintained indefinitely, and shared among many processes. These services broadly cover the definition, storage, maintenance, management and access of object entities and the relationships among them. These are the services typically provided by products from database vendors, though they can also be provided by special purpose file management programs or by object-based systems, as explained in the earlier discussion of client-server data access Architectures.
  • Distributed Computing Platform (DCP) Services provide a standard communication mechanism which may be used for inter-tool and inter-service communication within a distributed network environment. Services may include message broadcasting, process invocation, remote procedure call, data communication, transparent file access and network security.
  • Operating System Services include both the low-level services that manage hardware resources and the higher level software mechanisms that facilitate user and application interaction with the hardware and operating system.
  • Hardware Platforms consist of the hardware components of a workstation or server. The hardware platform provides the central processor, local memory, and communications devices that make up the physical components of the system. Peripheral devices are normally attached to a hardware platform, are independent of other portions of the Architecture, and are accessed through other system services such as the operating system.
  • 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.

    4.6.3 Benefits of the Pluggable Computing Model

    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.

  • Scalable application environments enable flexible matching, or "right-sizing", of the set of tools (Tool Services in the model) to the needs of a geoprocessing application. For example, not all map display applications require full geodata management capabilities, so in these applications only a subset of OGIS services need be accessed. The configuration of tools in scalable environments can be based on the task and the characteristics of the overall application, instead of the arbitrary contents of a "one size fits all" monolithic software package.
  • Extensible systems support flexible assimilation of outside data and software into an application environment. This includes the ability to leverage legacy systems (pre-existing data and software) through encapsulation, providing an interface that endows them with standard object behaviors so they become part of an OO environment. An extensible geoprocessing application is one whose functionality can be made to grow as the requirements of the geographic application mature.
  • Diverse systems support a broad range of application domains either through extensibility or the inherent richness of functions in the existing tools. Diverse systems can be thought of as "horizontal" or "enterprise" application environments which support different styles of work and fuse disparate data types within an organization's workflow processes.
  • Interoperable systems support integrated, cooperative and interchangeable tool sets. The mechanisms for enabling interoperable tools are primarily supported by the infrastructure services of the application platform: the Human-Technology Interface Services, Data Management Services and DCP Services of the pluggable computing model. Interoperable systems enable tools to be replaced such that no changes to other tools in the environment are required and new tools automatically cooperate with other tools in the environment.
  • 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 ]


    5. The Open Geodata Model


    5.1 Introduction

    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:

  • The essential model is a description of a real-world situation, like the Earth model described in this chapter. Building an essential model helps to establish the facts that need to be modeled. The building blocks of the essential model are object types and event types.
  • The specification model describes software at a high level of abstraction. OGIS is a specification model.
  • The implementation model is concerned with establishing patterns of control flow within software. This model takes into account the limitations imposed by computers, DCPs, and programming languages. Members of OGC are developing implementation specifications for DCPs which are lower level descriptions of software than the OGIS specification model. It makes sense to have a different implementation spec for each DCP, but there could also be implementation specs for particular programming languages, database systems, or hardware platforms.
  • 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 ]

    5.2 An Earth Model for OGIS

    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 ]

    5.3 Location: Place and Time

    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 Location and geometric representation essential model

    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 ]

    5.4 Features and Coverages

    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.

  • · An Open Geodata Model mathematical representation consists of geometrical models of space in one, two, or three dimensions plus a temporal dimension. It also defines the spatial and temporal reference systems in which these models are embedded.
  • · An Open Geodata ModelOpen Geodata Model conceptual viewconceptual view refers to how humans perceive the world around them in a geographic context. The conceptual view has both a visual component, which is an abstraction or symbolization of reality (including graphical, textual, and imageryimagery elements), and an intuitive/interpretive component which provides meaning and understanding. The conceptual view is unique for each person or group of people. But for practical reasons, i.e. to enable communication, the conceptual view needs to be expressed in a common semantic form and style. For example, consider "standard" mapsmaps, in which common colors and symbologysymbology are used to represent Earth phenomenaphenomena.
  • Figure 5-2 depicts a situation in which two conceptual views have been constructed from the real world. The first view is one that a cartographer might have and shows building outlines and streets. (More information would be associated with this view such as the symbology of the roads and building outlines, depending on the scale of map output). The second view is one that a tax assessor might have and shows lots and lot numbers. (More information would be associated, such as the value of the improvements to the lots). These conceptual views can be abstracted further to Open Geodata Model types. In the cartographic view, the building outlines and roads are abstracted to polygons and lines, respectively. In the tax assessor view the lots are abstracted to polygons. In both cases, of course, a spatial/temporal reference system would be used to locate these geometries with respect to the earth.

    Figure 5-2 Open Geodata Model abstractions accommodate any conceptual view

    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):

  • A description of the geometry of the phenomenon with associated spatial and/or temporal reference system, including a statement of the resolution and accuracy of the geometric model.
  • A description of the semantic properties of the phenomenon; that is, how it is defined in the lexicon of a particular domain group. (A domain group is a group of users who use many of the same feature definitions. A group of surveyors, for example, might use the same definitions for roads.)
  • MetadataMetadata - other information that might be needed to position the phenomenon in the context of the application environment or user community.
  • 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) .

    5.4.1 Feature: The More Formal Definition

    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.

    5.4.2 Coverage: The More Formal Definition

    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:

  • It can be exhaustively represented. Since this implies a finite number of point-value pairs, this technique can be only be used for functions on sets of points. Soundings in bathymetric charts fall into this category.
  • It can be set to a constant for a finite set of "patches." The most common example of this is the polygon coveragecoverage that defines the function as a constant for each polygon in a collection of polygonspolygons. The usual method of dynamic segmentationdynamic segmentation, rasterraster images, and grid-cell based coveragescoverages also uses this technique.
  • It can be defined analytically for a finite set of "patches." Triangulated irregular networksTriangulated irregular networks (TIN) define values via linear interpolation across a collection of triangles. Grid-post coveragescoverages use a variety of interpolation schemes, such as bilinear, biquadratic, or bicubic polynomials. Spline functionsSpline functions define continuous functions (usually polynomial or rational functions) over patches in a similar manner. Most spline functions use quadrilateral patches in the coordinate space, but triangular ones are also used. TINs and splinessplines are reserved for numeric-like values that can be treated by analytic mechanisms.
  • 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 ]

    5.5 Semantic Properties - Attributes of OGIS Features

    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 ]

    5.6 Open Geodata Model is Implementable with Well Known Structures

    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 ]

    5.7 Metadata -Properties of Features and Feature Collections

    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:

    Element Name
    TypeType
    acquisition datedate
    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 ]

    5.8 Geometries in OGIS Features

    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:

  • Point - a zero-dimensional topology, this type specifies a geometric "location."
  • Curve - a one-dimensional topology, this type specifies a family of geometric entities including line segments, line strings, arcs, b-spline curves, and so on.
  • Surface - a two-dimensional topology, this type specifies a family of geometric entities including areas (the inclusion of points within a closed curve or set of closed curves) and surfaces that are defined in other ways.
  • Solid - a three-dimensional topology, this type specifies a family of geometric entities including volumes (the inclusion of points within a closed surface or set of closed surfaces) and solids that are defined in other ways.
  • 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.

    5.8.1 Geometry: The More Formal Definition

    Geometry is the combination of a coordinate geometry and a reference system. Coordinate geometry consists of as many as four items:

    1. A sequence of coordinate points all from the same reference system.
    2. A collection (bag) of other geometries, all from the same reference system.
    3. An interpretation algorithm that uses these geometries and coordinate points to 'construct' a coordinate geometric entity that indirectly defines the extent of the geometry in time and space. (Sometimes, for example, the developer or the user might want to define an extent of the geometry that's much simpler than the geometry itself, such as a minimum bounding rectangle.)
    4. A spatial/temporal reference system that maps between the coordinate geometry and location, giving the geometry a 'real world' interpretation.

    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:

  • The coordinate dimension that is the dimension of the coordinates that define this geometry, which must be the same as the total dimension of the spatial reference system.
  • The dimension that is the inherent dimension of the object itself, which must be less than the coordinate dimension.
  • The extent function "is in (coordinate)" which is a Boolean valued function that defines the extent of the geometry. It determines whether a coordinate point in the spatial reference system is in the geometry being defined.
  • The interpretation is an algorithm that takes the defining coordinate points or aggregated geometry and defines the extent of this coordinate geometry entity.
  • Coordinate points are the zero dimensional coordinate geometries. The additional coordinate point attributes are:

  • The projection functions (one for each dimension) give the numeric values of each of the coordinate dimensions.
  • The value of dimension (for example, curve, surface, solid) and the interpretation (for example, linear, spline) will distinguish most subclasses of coordinate geometry.

  • [ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Next Chapter ]

    5.9 Spatial Temporal Reference Systems

    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:

  • A well-defined set of general reference system types (Mercator Projection, Longitude-Latitude, State Plane Coordinates, etc.), including the definition of their description parameters and mechanisms for specializing them by varying the values of their parameters.
  • Mechanisms for registering completed descriptions and for connecting specific reference system descriptions with specific features.
  • Mechanisms for describing and invoking transformations between types (general and specialized) with specific transformation parameters.
  • 5.9.1 Reference Systems and Coordinate Geometries: The More Formal Model

    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:

  • The space dimension is the topological dimension of the spatial projections of the system (usually 1, 2, or 3).
  • The time dimension is the topological dimension of the spatial projections of the system (usually 0 or 1, where 0 is a point in time, and 1 is a time interval).
  • The total dimension is the sum of the other two dimensions, and is therefore the number of coordinate dimensions required for the coordinate geometry associated to this system.
  • The locate function finds the location in the real world of a coordinate point or geometry.
  • Figure 5-8 Spatial Temporal Reference System and Coordinate Geometry essential model

    5.9.2 Transformations: The More Formal 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.

    5.10 Base Information Definitions and Information Communities

    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.