[ Table Of Contents ] [ Previous Chapter ] [ Previous Section ] [ Appendix B ] [ Index ]


Appendix A. Glossary


  • Accuracy - is the degree to which information on a map or in a digital database matches true or accepted values. Accuracy pertains to the quality of data and the number of errors contained in a dataset or map. In discussing a GIS database, it is possible to consider horizontal and vertical accuracy with respect to geographic position, as well as attribute, conceptual, and logical accuracy. The effect of inaccuracy and error on a GIS solution is the subject of sensitivity analysis. Accuracy, or error, is distinguished from precision , which concerns the level of measurement or detail of data in a database.
  • Agent - A kind of intermediary service which acts on behalf of another service (service provider or requester) according to rules established upon its invocation. Also known as an "intelligent agent."
  • ANSI is an abbreviation for American National Standards Institute. ANSI standards have been established for many elements of computer systems to aid research and development. The existence of standards allows designers to develop general solutions to common problems.
  • Application - The use of capabilities, including hardware, software and data, provided by an information system specific to the satisfaction of a set of user requirements. See Geographic Application and Geoprocessing Application.
  • Application DeveloperApplication Developer - A software programmer who creates applications, usually by integrating a variety of pre-existing elements such as application programming interfaces and software and hardware platforms.
  • Application Platform - The collection of hardware and software components that provide the infrastructure services used by application programs. APIs make the specific characteristics of the platform transparent to the application.
  • Application Portability - The ability to move software among computers without rewriting it. This may be provided in three ways: as source code portability, pseudocode portability, or binary code portability. See User Portability
  • Application Programming Interface (APIAPI) - An interface definition that permits writing OGIS services for application programs without details of their internal implementation. Defines the behavior of a OGIS service. In the OSE model, the interface between the application software and the application platform, across which services are provided.
  • Application Software - The computing elements supporting users' particular needs. Includes data, documentation, and training, as well as programs.
  • Architecture - An abstract technical description of a system or collection of systems. Conceptually based. Does not contain the level of detail needed for construction.
  • Architectural Framework - Identifies key interfaces and services, and provides a context for identifying and resolving policy, management and strategic technical issues. Constrains implementation by focusing on interfaces, but does not dictate design or specific technical solutions.
  • ASCII is an abbreviation for American Standard Code for Information Interchange. The ASCII formatformat provides computer systems with a common language for exchanging information. Although most GIS software systems make use of proprietary binary codes, almost all systems have import-export capabilities for translating between ASCII and binary formatsformats.
  • Attribute data is descriptive information about featuresfeatures or elements of a databasedatabase. For a database featurefeature like census tract, attributesattributes might include many demographic facts including total population, average income, and age. In statistical parlance, an attribute is a "variable," whereas the database feature represents an "observation" of the variable.
  • Base document - The working draft of OGIS, maintained by the Chairman of the OGIS Project Technical Committee, which is the repository for working papers that have been submitted by Committee members.
  • Base maps provide the background upon which thematic data is overlaid and analyzed. As inputs into a GIS, the term base map is usually applied to those sources of information about relatively permanent, sometimes timeless, featuresfeatures including topography, pedology, geology, cadastral divisions, and political divisions. Within a GIS databasedatabase, such information may become part of a land base to which other information is indexed and referenced.
  • Base Earth Model - A common, logically consistent definition of the Earth Model within the Open Geodata ModelOpen Geodata Model. Includes a geodetic and temporal mathematical reference frame, and the components of SurfaceSurface Configuration, Surface Features, and Volumes which are independent of OGIS applications and have unambiguous definitions.
  • Base Standard - An approved International Standard, Technical Report, CCITT Recommendation or National Standard.
  • Base Information DefinitionBase Information Definition - An information model that provides a common, logically consistent definition of the elements from the Open Geodata ModelOpen Geodata Model used within an OGIS application environmentapplication environment.
  • Broker - A kind of intermediary service whose responsibility is only to bring other services together (typically a service requester and a service providerservice provider) and has no responsibility for satisfactory completion of the "contract" established between the requester and provider.
  • Catalog - A collection of entries, each of which describes and points to a featurefeature collectionfeature collection. Catalogs include indexed listings of feature collections, their contents, their coveragescoverages, and other metadatametadata. Registers the existence, locationlocation, and description of feature collections held by an Information Community. Catalogs provide the capability to add and delete entries. At a minimum a Catalog will include the name for the feature collection and the locational handle that specifies where this data may be found. The means by which an Information Community advertises its holdings to members of the Information Community and to the rest of the world. Each catalogcatalog is unique to its Information Community.
  • CAD or CADD refers to computer-aided design and drafting. CAD systemCAD systems are used to create mapsmaps and plans and are closely related to GIS systems. Although most CAD systems lack certain featuresfeatures essential to GIS analysis, such as the power to manage different spatial coordinate systems and databasedatabase capabilities, many CAD systems have been developed into full GIS with the addition of necessary functions.
  • Cadastral survey is the means by which private and public land is defined, divided, traced, and recorded. The term derives from the French cadastre, a register of the survey of lands and is, in effect, the public record of the extent, value, and ownership of land for purposes of taxation. Cartesian Coordinates are a system of positional reference in which locationlocation is measured along two or three orthogonal (perpendicular) axes. Every location can be defined uniquely by its X, Y, and Z coordinates. Locations in the coordinate system can be established using any unit of measurement such as meters, feet, and miles.
  • Cartesian coordinates differ from latitude- longitude coordinates in that the latter comprise a spherical (rather than planar) reference systemreference system.
  • Centroid is the term given to the center of an area, region, or polygon. In the case of irregularly shaped polygonspolygons, the centroid is derived mathematically and is weighted to approximate a sort of "center of gravity." Centroids are important in GIS because these discrete X-Y locations are often used to index or reference the polygon within which they are located. Sometimes attribute information is "attached," "hung," or "hooked" to the centroid locationlocation.
  • Connectivity is a topological property relating to how geographical featuresfeatures are attached to one another functionally, spatially, or logically. In an water distribution system, connectivity would refer to the way pipes, valves, and reservoirs are attached, implying that water could be "traced" from its source in the network, from connection to connection, to any given final point. Functional, spatial, and logical connectivity are examples of relationships that can be represented and analyzed in a GIS databasedatabase.
  • Conversion is the process of transferring data derived from existing records and maps to a digital database. Conversion is a major input problem and can consume the greatest share of time in a GIS project.
  • Communications Service Interface (CSI)- The interface by which an application platform accesses external entitiesentities which provide data transport services. The service provided is data transport among application platforms.
  • Computer architecture - The functional composition of a system and its components, the interfaces between components, and interfaces with the external environment, including users and other systems.
  • Computer Environment - The general term describing the people, hardware, software, and databasesdatabases comprising a single computer system or several network-connected computer systems, and the associated standardsstandards.
  • Digital orthoimages - Ortho-rectified images produced using photogrammetric techniques to orthorectify scans of aerial photos and paper mapsmaps.
  • Distributed Computing Environment (DCEDCE) - A collection of software components that support interoperabilityinteroperability and transparency across multiple heterogeneous platforms in various network configurations.
  • Diversity - The ability of a system or components of a system to support multiple behaviors, functions, and data typesdata types.
  • Domain - System context: A class of systems which have similar requirements and capabilities. Application context: The body of knowledge defining the range and scope of an application in terms of elements, rules and behaviors.
  • Dynamic segmentation - points along a line that vary in value, e.g. pavement thickness along a road centerline.
  • DBMSDBMS stands for databasedatabase managementdatabase management system. A DBMS is an organizational plan for the use of information within a single project, or within one unit or the whole of an organization.
  • dejure standard - A standard that has been adopted through a formal process in a standards organization.
  • de facto standard - A standard that has been informally adopted, often because a particular vendor was first to market with a product that became widely adopted.
  • DEM is short for digital elevation model, a data exchange formatformat developed by the United States Geological Survey for geographical and topographical data. Digitize is the process of converting source materials, prepared manually, into the digital codes stored and processed by computers.
  • Digitizing involves tracing map featuresfeatures into a computer using a digitizing tablet, graphicsgraphics tablet, mouse, or keyboard cursor.
  • DLG stands for digital line graph, a form of digital map developed by the United States Geological Survey. DLGs supply users with the digital version of information printed on USGS topographical quadrangle mapsmaps.
  • DTM stands for digital terrain model, a method of transforming elevation data into a contoured surface or a three-dimensional display.
  • DXF is an abbreviation for drawing interchange formatformat, a file exchange format developed by Autodesk Inc. for its AutoCAD drafting software. DXF files are ASCII records of all objectsobjects in a drawing file. DXF has been adopted more recently by GIS systems for exchanging map files.
  • Earth Model - An approach to abstracting the Earth. The data model for the Earth.
  • Emerging standard - A specification that is under consideration by an accredited standardsstandards development organization, but has not completed the process of approval by the sponsoring body.
  • Extensibility - The ability for a system or components of a system to expand by assimilating new data, software or hardware components.
  • Ethernet is a type of local-area network used for high-speed communication among computers.
  • Framework - A reusable software template, or skeleton, from which key enabling and supporting services can be selected, configured and integrated with application code.
  • Feature - A digital representation of a real worldreal world entity or an abstraction of the real world. It has a spatial domaindomain, a temporal domain, or a spatial/temporal domain as one of its attributesattributes. Examples of featuresfeatures include almost anything that can be placed in time and space, including desks, buildings, cities, trees, forest stands, ecosystems, delivery vehicles, snow removal routes, oil wells, oil pipelines, oil spills, and so on. Features are usually managed in groups as featurefeature collectionfeature collections.
  • Feature collection - A set of related features managed as a group.
  • Geographic application - Applications which pertain to the Earth and Earth phenomenaphenomena, with known spatial and temporal reference systemreference systems. Expressed in a human context versus computer context.
  • Geoprocessing application - Computer applications which model, interpret and use Earth information. The implementation of a Geographic Application on a computer. The terms "geoprocessinggeoprocessing," "geomatics," and "geotechnology" mean approximately the same thing, though some groups make minor distinctions between them.
  • Geodata - Information that identifies the geographical locationlocation and characteristics of natural or man-made featuresfeatures and boundaries of the Earth. Geodata represent abstractions of real-world entitiesentities, such as roads, buildings, vehicles, lakes, forests and countries.
  • Geodata model - A formalized system for representing geodatageodata. OGIS defines geographic data typesdata types in the Open Geodata ModelOpen Geodata Model.
  • Geospatial function (or Process) - Any function or process which handles or operates on geodatageodata.
  • GIS is the abbreviation for geographic information system. GIS are special-purpose digital databasesdatabases in which a common spatial coordinate system is the primary means of reference. GIS contain subsystems for: 1) data input; 2) data storage, retrieval, and representation; 3) data management, transformation, and analysis; and 4) data reporting and product generation. It is useful to view GIS as a process rather than a thing. A GIS supports data collection, analysis, and decision making and is far more than a software or hardware product. Other terms for GIS, and special-purpose GIS, include: Land-Base Information System, Land Record System, Land Information System, Land Management System, Multipurpose Cadastre, and AM/FMAM/FM System.
  • GPSGPS is an acronym for global positioning system. Developed for the military for navigation and surveying, the GPS relies on satellites (and ground stations) for precise determination of locationlocation. Although GPS can be used to determine location very precisely (within centimeters given the correct controls and proper use), it does not solve all the problems of locational determination in GIS databasesdatabases.
  • Handle - An index entry or unique name in software that identifies a catalogcatalog entry or other resource so that it can be found and utilized by another software facility.
  • Hierarchical database stores related information in terms of pre-defined categorical relationships in a "tree-like" fashion. Information is traced from a major group, to a subgroup, and to further subgroups. Much like tracing a family tree, data can be traced through parents along paths through the hierarchy. Users must keep track of the hierarchical structure in order to make use of the data. The relational databasedatabase provides an alternative means of organizing datasets.
  • Human Technology Environment - The environment within which people interact with information technology, typically a mouse and windowing system.
  • Human Technology Interface (HTI)- The interface across which people interact with information technology. The service provided through this interface is access to the information infrastructure and to other people.
  • Implementation - A software package that conforms to a standard or specification. A specific instance of a more generally defined system.
  • Information appliance - End-user equipment having input and display (or auditory) capabilities for communication with other users or service providerservice providers in the NII.
  • Information Storage Interface (ISI)- The interface across which information technology interacts with external storage media. The service provided through this interface is persistent storage of data, where the physical storage media is often removable.
  • Information Community - A community of geodatageodata producers and users who have a common set of geographic featurefeature definitionsfeature definitions.
  • Interface - A shared boundary between two functional entitiesentities. A standard specifies the services in terms of the functional characteristics and behavior observed at the interface. The standard is a contract in the sense that it documents a mutual obligation between the service user and provider and assures stable definition of that obligation.
  • Intermediary - A service that provides functions by which to interconnect, adapt and facilitate services offered by other parties, components or environments. Common forms of intermediaries include agent, broker, mediator and tradertrader services.
  • Interoperability - The ability for a system or components of a system to provide information portability and interapplication, cooperative process control.
  • ISO - International Standards Organization. OGCOGC has a class A liaison relationship with ISO/TC 211, the ISO technical committee working on geoprocessinggeoprocessing standardsstandards.
  • LAN stands for local-area network, a system for connecting computers so they can communicate with one another.
  • LandsatLandsat is a system of satellites which scan the earth at a variety of wavelengths. The satellites return information that can be used to inventory and analyze a variety of natural and human resources.
  • Language independent - Describes a standard or specification which is not specified in terms of a specific programming language, but is implementable in a variety of languages.
  • Legacy system - Software or databasedatabase components inherited from a previous computing model which do not fit into an open system environment without some modification. In the case of OGIS, legacy systems are modified to include an OGIS-compliant interface.
  • Line string - a set of coordinate points and the lines that join them.
  • Map scale is the relationship between distance on a map and the corresponding distance on the earth's surface. Map scalescale is often recorded as a representative fraction such as 1:1,000,000 (1 unit on the map represents a million units on the earth's surface) or 1:24,000 (1 unit on the map represents 24,000 units on the earth's surface). The terms "large" and "small" refer to the relative magnitude of the representative fraction. Since 1/1,000,000 is a smaller fraction than 1/24,000, the former is said to be a smaller scale. Small scales are often used to map large areas because each map unit covers a larger earth distance. Large-scale mapsmaps are employed for detailed maps of smaller areas.
  • Manageability - The ability to configure, reconfigure, manage and control a system or the components of a system.
  • Mediator - A service which acts as an intermediary capable of impartially negotiating between a service requester and a service providerservice provider regarding aspects of a service to be provided. The mediation function often follows broker, tradertrader or agent functions.
  • MetadataMetadata - Graphical or textual information about the content, quality, condition, origins, and characteristics of data.
  • OGIS Application - An application that references the Open Geodata ModelOpen Geodata Model, Open Geodata Model featuresfeatures, and OGIS services.
  • OGIS Service - A software component providing object management, access, manipulation, interchange, or human-technology services for Open Geodata ModelOpen Geodata Model featuresfeatures.
  • Open Geodata ModelOpen Geodata Model - That part of the OGIS Specification ModelOGIS Specification Model which defines a general and common set of basic geographic information typestypes that can be used to model the geodatageodata needs of more specific application domains, using object-based and/or conventionalconventional programming methodsconventional programming methods.
  • Open specification - A specification that promotes interoperabilityinteroperability through its public availability to developers, who use it to develop software or hardware compatible with the common resource described in the specification. Interface specifications like OGIS confer interoperability among conformant products, which become common resources to each other. Open specifications are generally consistent with related standardsstandards and are updated to conform with new standards and new technologies. They may be developed and maintained, as in the case of OGIS, by a public open consensus process. A successful open specification generally becomes a de facto standardde facto standard, and it may become a de jure standardde jure standard through formal acceptance by form standards organizations.
  • Open system - A system that implements open interface specifications and standards that promote application portability, scalability, interoperability, diversity, manageability, extensibility, compatibility with legacy components, and user portability.
  • Open System Environment (OSE) - A computer environment specified by a set of standardsstandards and profiles for interfaces, services, and formatsformats for an open system.
  • Orthorectification - Use of photogrammetric techniques to adjust and correct distortions in images.
  • Online indicates when equipment such as plotters, printers, and digitizers is turned on and is actively communicating with a computer, or is controlled by that computer. Computers in a network can also be said to be online when the network connection operative.
  • Photogrammetry uses aerial photographs to produce planimetric and topographic mapsmaps of the earth's surface and of featuresfeatures of the built environment. Effective photogrammetry makes use of ground control by which aerial photographs are carefully compared and registered to the locations and characteristics of features identified in ground-level surveys.
  • Platform is another term for computer hardware, including microcomputers, workstations, and mainframe computers, or for underlying software, like an operating system, that provides services to layered software. When discussing software, platform independence implies the software can be run on any computer.
  • Precision refers to the level of measurement and exactness of description in a GIS databasedatabase. Precise locational data may measure position to a fraction of a unit. Precise attribute information may specify the characteristics of featuresfeatures in great detail. It is important to realize, however, that precise data--no matter how carefully measured--may be inaccurate. Surveyors may make mistakes or data may be entered into the database incorrectly. Therefore, a distinction is made between precisionprecision and accuracyaccuracy .
  • Profile - A collection of standardsstandards, with parameters, options, classes, or subsets, necessary for building a complete computer system, application, or function.
  • Protocol - A set of semantic and syntactic rules that determine the behavior of entitiesentities that interact.
  • RasterRaster databasesdatabases build all geographic featuresfeatures from grid cells in a matrix. A rasterraster display builds an image from pixels, pels, or elements of coarse or fine resolution. A raster databasedatabase maintains a similar "picture" of reality in which each cell records some sort of information averaged over the cell's area. The size of the cell may again be coarse or fine, ranging from centimeters to kilometers. Many satellites, like LandsatLandsat and SPOT, transmit raster images of the earth's surface. Reflectance at a certain wavelength is measured for each cell in an image. The cells may cover areas on the earth's surface several hundreds of meters square, the area covered being a function of a particular satellite's resolution.
  • Reference Model - Provides the complete scientific and engineering contextual framework for a technology area. The underlying elements, rules and behaviors.
  • Relational Database stores data in such a way that it can be added to, and used independently of, all other data stored in the databasedatabase. Users can query a relational database without knowing how the information has been organized. Although relational databasesdatabases have the advantages of ease-of-use and analytical flexibility, their weakness can be slower retrieval speed. SQLSQL is an interface to a relational database.
  • Remote Procedure Call (RPC) - An APIAPI for remote execution of detailed functions.
  • Scalability - The ability to change the component configuration of a system to fit desired application contexts.
  • Schema - a description of a featurefeature's attributesattributes, or more specifically, the specific attribution modelattribution model for a feature in terms of primitive data typesprimitive data types and constraints on these types.
  • Semantic TranslatorSemantic Translator - A Collection of mappings between a target Information Communitytarget Information Community and a source Information Communitysource Information Community, generally held and maintained by the target Information Community, though both Information CommunitiesInformation Communities may participate in configuring it. Usually expressed in terms of metadatametadata, featuresfeatures, attributesattributes and rules that permit information integration to occur when an featurefeature collectionfeature collection is imported to the target Information Community from a source Information Community.
  • Service - A computation performed by an entity on one side of an interface in response to a request made by an entity on the other side of the interface.
  • SIF - stands for standard interchange format. SIF is a format which allows data to be transferred among dissimilar computer systems. SQL stands for Structured Query Language, a relational database.
  • Specification - A document written by a consortium, vendor, or user that specifies a technological area with a well-defined scope, primarily for use by developers as a guide to implementation. A specification is not necessarily a formal standard.
  • Standard - A document that specifies a technological area with a well-defined scope, by a formal standardization body and process.
  • State Plane Coordinate System (SPC) is a locational reference systemreference system developed in the 1930s which provides positional descriptions accurate to 1 foot in 10,000 within the United States. The SPC system divides the United States into 125 zones (5 cover Texas) and employs both Lambert conformal and Tranverse Mercator projections (depending upon a state's size and shape). Within any given SPC zone, X-Y coordinates are given in eastings and northings. A central meridian passes each zone and is given a false easting of 2 million feet. A false northing of 0 feet is established below the southern limit of each zone.
  • SurfaceSurface Configuration Model - Defines the geometric characteristics of the Earth's surface, exclusive of featuresfeatures which fall upon the surface; defined in terms of elevation, shape, roughness, slope, and aspect, with the later propertiesproperties possibly derived from elevation.
  • SurfaceSurface Feature - An entity which lies on the Earth's surface or is referenced to the Earth's surface.
  • System Internal Interface (SII) - An interface between components within an application platform.
  • TIGER is an acronym for topologically integrated geographic encoding and referencing file. This is a type of digital map developed by the U.S. Bureau of the Census to support the 1990 population census. Census mapsmaps in TIGER formatformat succeed the previous DIME format. TIGER files are available for every county in the United States and for the millions of census blocks in urban areas. Although the accuracyaccuracy of TIGER files varies from county to county, partly for reasons beyond the control of the Bureau, they are likely to improve in coming decades. The TIGER files are a particularly important resource for many urban GIS.
  • Tool - A software component, sometimes called an application object, which can act as either a service providerservice provider or service requester within an application platform.
  • Topology refers to propertiesproperties of geometric forms that remain invariant when the forms are deformed or transformed by bending, stretching, and shrinking. Among the topological properties of concern in GIS are connectivity, order, and neighborhood.
  • Translation is the process of converting data or commands from one computer formatformat to another, or from one computer language to another.
  • TraderTrader - A kind of intermediary service which acquires services from one or more providers for "resale" to a service requester. The tradertrader service insulates requester and provider services from having to interact directly with one another. The trader is responsible to the requester for all aspects of the requested service.
  • Transparency - The ability of systems or components of systems to hide the details of their implementations from other client or serverserver systems or components of systems.
  • Tuple - An ordered set. Such a set of coordinates that define a point.
  • User portability - The ability of a user to move from one system to another without having to learn everything again.
  • UTM Coordinate System, based on the Universal Transverse Mercator map projection, is a planar locational reference systemreference system which provides positional descriptions accurate to 1 meter in 2,500 across the entire earth's surface except the poles. At the poles, the Universal Polar Stereographic projection is used. The UTM system divides the earth's surface into a grid in which each cell, excluding overlap with its neighbors, is 6 degrees east to west, and 8 degrees north to south (with the exception of the row from 72-84 degrees north latitude). For any position in the UTM grid, X-Y coordinates can be determined in eastings and northings. Eastings are in meters with respect to a central meridian drawn through the center of each grid zone (and given an arbitrary easting of 500,000 meters). In the northern hemisphere, northings are read in meters from the equator (0 meters). In the southern hemisphere, the equator is given the false northing of 10 million meters.
  • Validation - The process of testing an application or system to ensure that it conforms to
  • Vector displays and databasesdatabases build all geographic featuresfeatures from points, that is from discrete X-Y locations. Lines are constructed from strings of points, and polygonspolygons (regions) are built from lines which close.
  • Vector methodsmethods are sometimes contrasted with rasterraster techniques which record geographic featuresfeatures within a matrix of grid cells. The choice between vector and raster GIS has much to do with the application being considered since both methods have strengths and weaknesses. Many current GIS permit transformation between vector and raster input and output.
  • View - SQLSQL "Select", Statement, used to provide temporary information about a given table(s) of a Database Management System without actually creating a subset or new table.
  • Note: Some of the entries in this glossary were borrowed or adapted from the on-line dictionary of GIS terms from the University of Edinburgh Department of Geography and the Association for Geographic Information.


    [ Table Of Contents ] [ Appendix A ] [ Appendix C ] [ Index ]


    Appendix B. Policies and Procedures of the OGIS Project Technical Committee


    The Bylaws of the Open GIS Consortium, Inc. state:

    "The OGIS Technical Committee is charged with creating its own internal organization and process based on the contributed resources of member organizations..."

    This appendix defines the Policies and Procedures used by the Technical Committee of the OGIS Project Track of the Open GIS Consortium, Inc. These Policies and Procedures may change by vote of the Technical Committee as the needs and purpose of the Technical Committee change.

    Sections set off from the text in the manner of this section are explanations or rationales, and are not actually a part of this policies and procedures. Rather, they reflect the rationale and reasoning behind a decision laid out in the Policies and Procedures, in order to better reflect the intent of the appendix.

    B.1 Purpose of the Technical Committee


    The Bylaws of the Open GIS Consortium state that the OGIS Project Track Technical Committee "shall be responsible for developing the Open Geodata Interoperability Specification through a cooperative consensus process involving broad public and private sector participation." and "The OGIS Technical Committee ... is responsible for presenting Version drafts of the Open Geodata Interoperability Specification to the OGIS Management Committee according to committed release schedules." The Technical Committee is the solely responsible body for the technical content of the Open Geodata Interoperability Specification, and will develop it using a fair, equal, open, and non-discriminatory process.

    It should be clear from the Bylaws of the Open GIS Consortium that the OGIS Technical Committee is designed to be a consulting body, making recommendations only to the OGIS Management Committee.

    B.2 Definitions and Acronyms


    B.3 Specification Development


    In the development of the OGIS, there must be a process that ensures fair, equal, open, and non-discriminatory processing of ideas, suggestions, and proposals. The process described in this section is a phased approach with each phase designed to enhance the specification in some way. The phases are:

    B.3.1.1.1 Phase IæDraft Specification

    During the first phase, a preliminary specification will be written that includes introductory material, the conceptual model (outlining the OGIS data and process models), and potentially the interface specifications needed to implement the conceptual model.

    B.3.1.1.2 Phase IIæTestbed

    The second phase will be an international coalition of projects. The goal of this phase is to test that the specification can be implemented, to update the specification as lessons are learned, and to provide a test bed for the interoperability of implementations. As much as possible, the phase will utilize the widest possible range of technology options in the implementation of OGIS services and clients. This breadth of technology variance will provide the experience needed to be able to confidently provide a specification that ensures the broadest range of possible implementations. The project will provide coordination of separate projects, resulting in broad testing of the specification and determination of new functionality or services that should be specified in OGIS. The TC will continue to process changes and update OGIS during this phase.

    B.3.1.1.3 Phase IIIæFinal Specification

    The final phase will be spent:

    The process of managing the evolution of the specification through these phases is the business of the Technical Committee.

    B.4 The Technical Committee


    The OGIS Project Track of the Open GIS Consortium has a body, called the Technical Committee (TC), which is responsible for the development and maintenance of the specification. The TC will operate under the general guidance of Robert's Rules of Order and will include Voting TC Members, TC Members, and Invited Guests.

    The Technical Committee will, as its primary function, vote on proposals and recommendations. Proposals can be for any purpose pertaining to the format and content of the specification, as well as, Policies and Procedures of the TC, and for other purposes consistent with the purpose of the TC. The TC will make recommendations to the MC concerning release of versions of drafts of OGIS.

    The Technical Committee will constitute Working Groups (WG) to carry out the development of new proposals. WGs will be formed, carry out their work, and be dissolved using the processes defined in the Working Groups section (4.3.2).

    The Technical Committee will constitute Subcommittees (SC) to carry out work other than developing proposals. SCs will be formed, carry out their work, and be dissolved using the processes defined in the Subcommittees section (4.3.3)

    B.4.1 Policies

    The following rules apply to Technical Committee meetings. These rules apply to all TC Members and Invited Guests.

    B.4.1.1 Composition of the TC

    As noted in the definition of the Technical Committee, the TC is established by the BOD. The TC has the following composition:

    _ The Technical Committee Chair (appointed by the BOD).

    _ Representatives of all members of the OGIS Project Track of OGC.

    _ Other individuals deemed appropriate by the BOD.

    Although each member of the OGIS Project Track of OGC may be represented in TC meetings by individuals, only Principal and Technical Committee Members may send Voting TC Members to TC meetings (and only one Voting TC Member may vote on behalf of each Principal or Technical Committee Member).

    B.4.1.2 Meetings of the TC

    Technical Committee meetings are called by the TCC. Technical Committee meetings shall be conducted under the general guidance of Robert's Rules of Order. Meetings shall be conducted by the TCC or another appointed representative of the OGC. Meetings shall occur approximately every three months. Meetings must be announced at least four weeks in advance, by paper. Minutes of TC meetings shall be distributed by paper within two weeks of the meeting.

    By "paper" this document means by the regular international postage system, or by facsimile machine. Electronic mail shall be used by the TC and its members, but certain important communications (such as TC meeting notification and TC minutes) shall be delivered by more positive means.

    B.4.1.3 Attendance at TC Meetings

    Only members of the TC and Invited Guests are welcome at meetings of the TC. Guest lectures may appear on meeting dates, but no TC business may be transacted while other than TC members and Invited Guests are present. Any TC member may send another representative of his or her company as a substitute to a TC meeting.

    B.4.1.3.1 Invited Guests

    Guests may attend meetings of the TC under the following conditions:

    They have been notified by the OGC staff that an invitation is being extended (usually via electronic mail or facsimile transmission).

    A signed copy of the following non-disclosure agreement is on file at OGC headquarters or in the possession of the TCC:


    NON-DISCLOSURE AGREEMENT



    The individual or company signing this Agreement below as the "recipient" (referred to below as the "Recipient") has asked for proprietary information from Open GIS Consortium, Inc. ("OGIS") in order to evaluate a possible business relationship with OGIS, and in connection with such evaluation, OGIS has requested that Recipient execute this Non-Disclosure Agreement for the purpose of protecting trade secrets, confidential and proprietary information owned by OGIS ("Confidential Information"). As an inducement to OGIS to make such disclosure, Recipient hereby agrees as follows:



    Recipient hereby acknowledges that any Confidential Information that may be disclosed to Recipient's officers, agents or employees during the course of their evaluation of OGIS and any of its products, whether currently developed, or under development, is and shall remain Confidential Information.



    Recipient agrees that it shall not disclose any information that it receives from OGIS and that is designated by OGIS, either orally or in writing, as being Confidential Information, to any third party except its own officers and employees to whom such disclosure is necessary in order to carry out the evaluation contemplated by this Agreement, or use such information for its own benefit, or for any other purpose, except as specifically provided herein, and Recipient further agrees that it shall use the same degree of care to avoid disclosure or use of such information as Recipient would employ with respect to its own most valuable confidential or proprietary information.


    Without in any way limiting the foregoing, all technology, specifications, research data, plans, concepts, inventions and ideas, business plans, forecasts or projections, software, hardware, software or systems designs, documentation, and code disclosed to Recipient by OGIS shall be deemed Confidential Information. In no event shall Recipient disassemble, reverse engineer, or decompile, either in whole or in part, any software delivered by OGIS to Recipient in connection with the evaluation contemplated by this Agreement.


    Recipient agrees that it shall return all documents and storage media containing Confidential Information at any time upon OGIS's request, and shall thereupon destroy any copies of such documents and media made by it for purposes of the foregoing evaluation and make no further use of such Confidential Information unless otherwise agreed upon in writing.



    The parties hereto agree that the following information shall not be deemed Confidential Information and Recipient shall have no obligation to keep confidential with respect to any such information which:



    is already known to Recipient; or


    is furnished to a third party by OGIS without a similar restriction on the third party's rights; or

    becomes publicly known through no fault of Recipient.


    Nothing in this Agreement shall affect OGIS's rights in respect of the Confidential Information under the laws of any state or country relating to intellectual property rights, nor shall this Agreement be construed as granting Recipient any right or license to use the Confidential Information except as set forth above.


    Recipient agrees that in the event of a threatened or actual use or disclosure of any Confidential Information in violation of this Agreement, OGIS's remedy at law would be inadequate, and Recipient hereby agrees that in such event an injunction restraining such use may be issued by any court of competent jurisdiction.


    The invalidity or unenforceability of any part of this Agreement for any reason whatsoever shall not affect the validity or enforceability of the remainder.



    This Agreement represents the entire agreement between the parties with respect to its subject matter. This Agreement shall be construed and enforced pursuant to the laws of The Commonwealth of Massachusetts, exclusive of its rules governing conflict of law and choice of laws.



    IN WITNESS WHEREOF, the parties hereto have duly executed this Agreement under seal as of this _____ day of ______________ , 1995.


    [Recipient]

    ___________________________ Open GIS Consortium, Inc.

    By, _____________________ By, _____________________

    Name: _____________________ Name: _____________________

    Title: _____________________ Title: _____________________




    nondisag.v1


    B.4.1.4 Agenda of a TC Meeting

    A preliminary agenda for a TC meeting shall be determined at the end of the previous meeting. The agenda is managed solely by the TCC, and may be modified prior to the meeting as appropriate. A written agenda shall be distributed to TC members at least two weeks before each TC meeting by paper.

    Members will have an opportunity to suggest changes to the agenda at the start of the meeting, immediately after accepting the minutes of the last meeting. Changes must be approved by a simple majority.

    In order to allow the business of the TC to move along smoothly, the TCC may adjust the agenda based on members' schedules, available presentations and meeting sites, etc. Members are protected from capricious agenda changes by requirements for lead time on procedural presentation and votes.

    B.4.1.5 Voting During and Between TC Meetings

    A simple majority of Voting TC Members whose companies have attended, in person or through proxy, two of the last three TC meetings, shall constitute the quorum necessary for the TC to conduct business. A simple majority of the Voting TC Members present at a meeting where a quorum is present shall constitute a proper vote on all TC Items, except on changes to these Policies and Procedures, or on final MC recommendation votes. A two-thirds (2/3) vote of Voting TC Members at a meeting where quorum is present is required to change these Policies and Procedures; in addition, the vote to change these Policies and Procedures must be announced in the preliminary agenda of the meeting and conducted via paper ballot.

    In order to avoid deadlocking TC business through the continued lack of attendance of Voting TC Members, it was felt that some flexibility in the definition of quorum was necessary. This quorum policy, in which only one half of consistently attending member companies are required for quorum, protects active members and the TC process as a whole, without ever depriving Voting TC Members of a vote.

    Voting TC Members may send substitutes to TC meetings, but these substitutes may only vote with a written proxy statement by the Voting TC Member of his or her organization. Proxy statements shall be as described in section 4.1.5.1. Voting TC Members wishing to post a standing alternate should change their technical representative via a written request to OGC to do so. A paper (postal or facsimile) vote by a Voting TC Member shall also be accepted at a TC meeting.

    In order to ensure that business moves along, we wish to allow proxy voting, duly noting the dangers of voting without physical proximity.

    The TCC may not vote in TC votes, except in a tie-breaking capacity during an otherwise deadlocked majority vote. In regard to votes that require documentation (i.e., on adoption of particular documents or based on the content of a document), one third of the Voting TC members in attendance may invoke the requirement that documentation supporting the vote must be available three weeks prior to the vote.

    The three-week rule clause ensures that Voting TC members can enforce adequate time to read, distribute and gather comments on documents before voting on the document at the following TC meeting.

    The TC can take votes by fax between TC meetings. Fax votes may be brought by motion and second at a TC meeting, or by direct action of the TCC. Quorum for a fax vote shall be equal to a majority of the number of Voting TC Members whose companies have attended, in person or by proxy, at least one of the last three TC meetings at the time that the fax vote is initiated. Fax votes may be withdrawn by simple majority vote of the TC at a TC meeting.

    Fax votes shall terminate, on a date approved by the TCC, no less than three weeks and no more than six weeks after the date that the fax voting forms are sent (by paper) to Voting TC Members. If an affirmative majority of a quorum of voters (as defined by the fax voting quorum rule above) has not returned voting forms by the deadline, the vote will be deemed to have failed. The vote will not be considered complete until either (1) the deadline has been reached and the quorum rule has been satisfied, or (2) no further votes received could change the outcome of the vote.

    It is often necessary to obtain votes between TC meetings; fax quorum rules simplify the requirements for such voting. Since an incomplete fax vote might be aborted at a TC meeting and retaken (with meeting quorum rules!), it was suggested that the TCC include in each TC fax vote wording to the effect: "(COMPANY) votes (YES NO ABSTAIN) on fax question #X. If this fax vote is withdrawn and a vote taken on the question at a TC meeting, I hereby give my proxy to vote this same way at the TC meeting on the question(s)."

    B.4.1.5.1 Proxy Format and Content

    A proxy will read as follows (bracketed items should be replaced by the actual information):

    "PROXY

    The undersigned, on behalf of [organization], does hereby appoint [proxy holder] to act as my proxy as it relates to those certain questions expected to be brought for vote within the OGIS Project. [If the proxy is for specific questions then these should be listed ].

    This proxy is valid only for those questions brought before the Technical Committee during the period [indicated the dates of validity].

    This proxy expires [indicate the date].

    [signature]

    [title]

    [organization]"

    B.4.1.6 Role of the TCC

    The TCC is responsible for the continued progress of the Technical Committee. The TCC is an unbiased member of the TC, and therefore does not vote on Items (other than in the tie-breaking capacity mentioned in Section 4.1.5). The TCC shall ensure the following:

    B.4.1.6.1 Minutes

  • The minutes must include:
  • the agenda,
  • a list of members (marked with an indication of presence, and voting status),
  • a list of non-member attendees,
  • a record of all motions, including:
  • the name and organization of the motion-maker,
  • the name and organization of the second, and
  • the name, organization and vote (Accept/Reject) of all members.

    a record of all proposal briefings (copies of actual briefing material, if possible), and

    a record of all questions and subsequent responses and discussion during the question period.

    a record of all recommendation motions and discussion.

    Minutes will be accepted (subject to any changes) at the next scheduled Technical Committee meeting.

    B.4.2 Rules for Processing a Proposal

  • From time to time the Technical Committee will vote on proposals. The rules for processing a proposal are as follows:
  • Only Voting TC Members may submit proposals. However, authors do not have to be TC Members.
  • The proposal must be received, by the TCC on the anonymous ftp site (moon.cecer.army.mil:/ftp/ogis/incoming) or by electronic mail, at least three weeks before a regularly scheduled TC meeting. The TC may vote to waive this requirement by motion and second at a TC meeting.
  • The proposal must be written such that there are only two outcomes, namely, acceptance or rejection. In other words, alternatives must be presented in separate proposals.
  • The proposal must be in the correct format (see section 4.4.1, Proposal Format for the format of proposals to change the Base Document) unless the TC votes to process the proposal in anticipation of receipt of the proposal in the correct format by motion and second.
  • The proposal must be briefed (explained in detail sufficient for general understanding of the purpose and intent of the proposal).
  • If the proposal affects the content of the Base Document, the proposal must be briefed by its proponent(s) in a WG selected by the TCC. If accepted, the WG will forward a recommendation to accept the proposal to the TC as an Item for TC vote.
  • If the proposal does not affect the content of the Base Document (as in a Proposal to Create a Working Group), the proposal must be briefed by its proponent(s) to the TC. This briefing must not exceed one hour in duration, unless the TC votes to extend the briefing period by motion and second.
  • A question period must be held where Voting TC Member questions can be addressed by the proponent(s). This period must not exceed thirty minutes in duration, unless the TC votes to extend the question period by motion and second.
  • A Motion to Table may be made at any time during or immediately following the question period. Such a motion must include a thorough explanation of the reason for tabling the proposal and can include recommended remedial action. If this motion is seconded and passed unanimously (abstentions allowed), then the proposals status is as if it had never been presented.
  • A Motion to Accept may be made immediately following the question period. If this motion is seconded and passed, then the proposals status is Accepted, otherwise it is Rejected. The Motion to Accept can contain criteria for acceptance, such as corrections or other modifications, aslong as they are detailed in the motion.
  • B.4.3 Subgroups of the TC

    In order to carry out the business of the TC in a timely manner, two different types of subgroups of the TC may be formed. These groups are called Subcommittees (SCs) and Working Groups (WGs). Each is composed solely of TC members and potentially Invited Guests. Each type of group is created by simple majority vote of the TC in the course of regular business. Working Groups have an additional documentation step that is defined in section 4.3.2.

    There are differences, however, between the types of groups.

    Subcommittees:

  • In contrast, Working Groups:
  • B.4.3.1 Membership in TC Subgroups

  • The following rules apply to membership in subgroups of the TC:
  • B.4.3.2 Working Groups

    B.4.3.2.1 Proposal to Create a Working Group

    The creation of a working group will involve the generation of a Proposal to Create a Working Group. This proposal will contain the following:

    a mission statement,

    a preliminary work plan,

    a nomination for a working group chairman, and

    an initial membership of at least three Voting TC Members.

    The mission statement must define the purpose of the new WG. The work plan portion describes the work and method of accomplishment in detail. The proposed WG must not significantly overlap the work of an existing WG, unless agreed to by the TC. The TC will then use the Rules for Processing a Proposal (section 4.2) to accept or reject the WG creation.

    B.4.3.2.2 Accomplishing the Mission

    Work groups chairmen can use whatever means appear to be most appropriate in order to provide for a fair, equal, open, and nondiscriminatory process for the generation of proposals. WG meetings should be as free flowing as possible to promote creativity. If, however, work is stalled (for whatever reason), the WGC must bring the issues causing the stall to the attention of the TC, where a vote will be made on a Proposal to Resolve an Issue. Such a proposal will contain:

    a detailed description of the issue causing the stall and

    a sub-proposal for all positions relevant to the issue.

    The TC will then use the Rules for Processing a Proposal (section 4.2) to accept or reject each sub proposal. Once one of the sub proposals pass, the issue will be resolved.

    Minutes of all WG meetings should be taken and should include:

    the agenda for the meeting (if any),

    the membership list (with present members so indicated), and

    all relevant items of discussion.

    The minutes should be presented to the TC promptly after the WG meeting is completed.

    Each WGC will maintain a set of documents that are accessible to all members of the TC. This set will include:

    Mission Statement,

    Current Work Plan,

    Minutes of All Meetings, and

    List of Work Group Members.

    WG meetings will occur only in connection with TC meetings, unless a Proposal to Hold a Special Working Group Meeting is accepted by the TCC. Such a proposal will contain:

  • the purpose of the special meeting,
  • the time (required), place (required), and agenda (optional), and
  • a statement by the working group chair that the meeting has been agreed to by a simple majority of the working group members.

    Note that this proposal does not need the approval of the TC.

    B.4.3.2.3 Proposal to Dissolve a Working Group

    The dissolution of a working group will involve the creation of a Proposal to Dissolve a Working Group. This proposal will contain the following:

    an explanation of the reason(s) for dissolution and

    an analysis of the effect of dissolution if the mission has not been satisfactorily completed.

    The TC will then use the Rules for Processing a Proposal (section 4.2) to accept or reject the WG dissolution.

    B.4.3.3 Subcommittees

    B.4.3.3.1 Creation of a Subcommittee

    The creation of a subcommittee will be accomplished by a motion of the TC. The motion must include:

    The purpose of the SC, a nomination for chairman, and a list of at least three Voting TC Members.

    The chairman must be a Voting TC Member.

    B.4.3.3.2 Accomplishing the Mission

    Subcommittee chairmen can use whatever means appear to be most appropriate in order to provide for a fair, equal, open, and nondiscriminatory process to accomplish their purpose.

    Minutes of all SC meetings should be taken and should include:

  • the agenda for the meeting (if any),
  • the membership list (with present members so indicated), and
  • all relevant items of discussion.
  • The minutes should be presented to the Technical Committee Chairman promptly after the SC meeting is completed.

    B.4.3.3.3 Dissolution a Subcommittee

    The dissolution of an SC will be accomplished by an approved motion of the TC to do so.

    B.4.4 Documents and Distribution

    The numbered document (see 4.4.1) in paper form as distributed to members is to be considered the official document. Three channels shall be used for discussion and distribution of documents within the TC. Electronic mail shall be used for day-to-day discussion and unofficial dissemination of documents to be viewed by the TC. Paper (international post and facsimile) or anonymous FTP shall be used for all official document dissemination to the TC; the TCC shall be responsible for numbering and/or naming such documents and keeping a file of all such distributed documents. Any member wishing to obtain documents via international post or facsimile must notify the TCC in writing of this desire. Diskettes shall also be distributed with documents in electronic form, if requested in writing by members to the TCC, such diskettes to be made available by international post. The format of such electronic dissemination shall be determined by the TCC from time to time; at this writing the standard formats will be PC-formatted 1.44MB diskettes with Microsoft Word, ASCII, Rich Text Format and Postscript file formats (although references to document line numbers, sections, etc. shall come from the PostScript version). Paper versions of all documents shall be stored and available from OGC headquarters.

    It was felt that electronic mail, as it exists today, is a proper medium for discussion, but not a reliable medium for important documents. Therefore, documents shall remain in paper or electronic form, distributed by post or fax. Documents are filed at OGC headquarters (under the purview of the TCC) in order to be fully available to current and future TC members.

    B.4.4.1 Document Numbers

    Official TC documents will be assigned a number. This number, called the OGIS Document Number will be assigned by the TCC at the request of members. The Document Number will be formed from the last two digits of the current year and a consecutive three digit number starting from 001. Revised documents will be assigned a number indicating the revision number. For example, the original OGIS Document Number for this document was 94-003, the first revision was 94-003R1.

    B.4.4.2 Proposal Format

    Proposals will have the following format:

    OGIS Document Number X (where X is the assigned OGIS Document Number,),

    Document Header, as follows:

    Title - the title of the document, conveying the purpose of the proposal

    Author - name(s) of the author(s) and the address, phone, fax, and electronic mail address of the primary author

    Date - the date of last modification

    Status - one of Information Paper, Proposal, Accepted Proposal, or Rejected Proposal

    References (if any).

    Background - a concise discussion of the reason(s) for the proposal in detail sufficient for clear understanding of the intent of the proposal.

    Proposal - the body of the proposal. This may include:

    Current Specification - if a change to the Base Document text, this section must be present and contain enough text so that an understanding of the changes can be reached without the need for the entire specification document. If the change is so immense that it is impractical to include the specification text, then the sections affected should be listed.

    any other sectioning necessary for readability.

    Future Work - if this proposal will result in the requirement for additional changes, not directly related to the proposal, then the remaining work should be noted in this section.

    B.4.4.3 Other Document Concerns

    All documents, with official OGIS Document Numbers, must be made available electronically to the TCC within three (3)weeks of the Technical Committee meeting. All documents must be made available in one of the following formats:

    Word for Windows 2.0 or 6.0 (preferred for proposals and other textual documents),

    Word for MacIntosh 5.0,

    WordPerfect 5.0, 5.1, 5.2, or 6.0,

    PowerPoint 3.0 or 4.0 (preferred for presentations),

    FrameMaker MIF 3.0 or 4.0, or

    ASCII Text.

    Presentations and other non-proposal documents will be accepted in PostScript format.

    B.4.5 Proprietary Rights, Copyrights, and Disclosure

    B.4.5.1 Proprietary Rights

    Proprietary information shall not be disclosed by any participant during any meeting of the OGIS Technical Committee or any subgroup of the TC.

    This section clearly places the onus of protection of proprietary rights on the owner of those rights. No discussion of proprietary technology can take place during a TC or TC subgroup meeting, protecting the participants in the meeting from accidental exposure to proprietary information (and consequent future legal problems with that participant's own intellectual property rights). If a TC member wishes to present information of a proprietary nature to members of the TC, he or she may arrange a meeting of the interested parties totally separate from the TC process and meeting.

    In addition, no information of a secret or proprietary nature shall be made available to the OGC as official documents, and no such documents (or documents marked as such) shall be made OGC official documents or forwarded to the membership.

    All proprietary information which may nonetheless be disclosed by any participant during any meeting of the OGIS TC or any subgroup of the TC shall be deemed to have been disclosed on a non-confidential basis, without any restrictions on use by anyone (except that no valid copyright or patent right shall be deemed to have been waived by such disclosure).

    B.4.5.2 Copyrights

  • All proposals intended to affect the contents of the Base Document, once submitted to the TC, (a) convey sufficient royalty free license rights to OGC to permit it to publish, license and sublicense the same freely to all third parties, and to permit OGC and all such third parties to own any derivative works base thereon without financial obligation to the submitter, but (b) do not in any way indicate that the submitter has surrendered or waived any copyright or patent in such proposal.
  • B.4.5.3 Disclosure

    It is the policy of the TC that the Base Document and all Proposals shall be restricted to member internal distribution until a Management Committee decision to release a versioned draft of the specification.

    B.5 Elections of Management Committee Representatives


    As stated in the Bylaws of the OGC, the OGIS Technical Committee has the right to two representatives on the OGIS Management Committee. The election of these representatives will be held according to the following rules.

    Nominations will be made from the ranks of Voting TC Members (an individual or an individual representing an organization already holding a seat on the MC cannot be nominated).

    There must be at least one nominee for each vacancy.

    The nomination must be accepted by the nominee.

    Each Voting TC Member may vote for one candidate per vacancy to be filled.

    The representative will be selected as follows:

    If both vacancies are open, then the two nominees with the most votes will be selected.

    If one vacancy is open, then the nominee with the most votes will be selected.

    B.5.1 Term of Office

    The term of office for TC representatives to the MC shall be as recommended by the TC. In the case of resignation, removal, death, or termination of TC Membership of a representative, the rules for election will be invoked to fill the vacancy.

    B.6 Adoption of This Document


    In order to be accepted or modified, this document must be ratified by a two-thirds (2/3) vote (under the rules herein) at a TC meeting or via paper (e.g., postal or facsimile) vote. Changes to this document are to be presented to the TC, included in the meeting's minutes, and ratified by the same procedure. Meetings in which a vote on acceptance or modification of this document is to occur must include the change in the published agenda for the meeting. It is the responsibility of the TCC to get approval from OGC counsel for any change of these Policies & Procedures after the TC votes for adoption of that change.

    B.6.1 Authorship and Revisions

    These Policies and Procedures initially were developed by the OGIS TC, chaired by Mr. Kurt Buehler of USACERL, and adopted as Technical Committee Concept of Operations. The document was then majorly revised and provided for consideration as Policies and Procedures by Mr. Kurt Buehler. The revision history of the document is as follows:

    Document 94-032 (1 December, 1994): First draft.

    Document 94-032R1 (20 December, 1994): Revisions as detailed in the adoption vote (Item #1).

    Document 95-019 (19 May, 1995). Revisions as detailed in OGIS Project Document 95-010.


    [ Table Of Contents ] [ Appendix B ] [ Appendix D ] [ Index ]


    Appendix C. OGC Background and Membership Information

    The Open GIS Consortium, Inc. (OGC) is a unique membership organization dedicated to open system approaches to geoprocessing. By means of its consensus building and technology development activities, OGC has had a significant impact on the global geodata and geoprocessing standards community, and has successfully promoted a vision of Open GISª that integrates geoprocessing with the distributed architectures of the emerging worldwide infrastructure for information management.

    By means of a formal consensus process, OGC is creating the Open Geodata Interoperability Specification (OGIS), a computing framework and detailed software specification that makes true geoprocessing interoperability possible for the first time. Member organizations' technical representatives attend meetings of the OGIS Project Technical Committee, where they collaborate in developing the OGIS. The OGC forum stimulates commercial activity and promotes public-private sector development partnerships. OGC maintains close ties with the standards community through ANSI and ISO technical committees and working groups.

    OGC's strategic direction is set by a board of directors selected for its ability to represent key constituencies in the geoprocessing community. These constituencies are interested in finding more integrated and effective ways to use the world's increasing wealth of geographic information to support problem solving in such areas as environmental monitoring and sustainable development, transportation, resource management, facilities management, agriculture, crisis management, and national defense.

    OGC's business and resource issues are addressed by the OGIS Project Management Committee, which is comprised of principal members of the Consortium, representatives of Consortium technical committees, liaisons to standards bodies and other key coordinating groups within the geoprocessing community, OGC staff, and the OGC board. Consensus works both horizontally among committee members and vertically among Board of Directors, the Management Committee, Technical Committee, and staff.

    OGC is a not-for-profit corporation supported by Consortium membership fees, as well as development partnerships and publicly funded cooperative agreements.

    The goal of the OGIS Project is to develop a comprehensive specification for the distributed processing of heterogeneous geodata. Through the OGIS Project, OGC works to bring the most advanced data processing technologies to bear on the area of geodata access and geoprocessing. Given the tremendous amounts of heterogeneous geodata now available and recent dramatic developments in geodata generation, there is a great need to focus on this goal.

    The OGIS Project was founded with limited support from a few federal agencies and commercial organizations who funded meetings to discuss the feasibility and possible scope of the interoperability project. After the original participants determined that a useful specification could be developed, OGC was formed as a not-for-profit trade association to provide a formal structure and process both for developing the OGIS and for developing other programs based on a broad vision of Open GIS. OGC now manages the OGIS Project as a formal consensus process involving key organizations in the commercial, academic, and government sectors of the geographic information community. Member organizations participate in the OGIS Technical Committee and its working groups and subcommittees, and members may also participate in the OGIS Testbed Program.

    OGC has enlisted the active involvement of official representatives from more than fifty organizations, including: GIS vendors, such as Intergraph, Genasys II, Graphic Data Systems (GDS), MapInfo, PCI, and ESRI; computer vendors such as Apple, Sun Microsystems, and Hewlett Packard; database vendors such as Oracle; integrators, such as Lockheed Martin Management & Data Systems and BBN; telecommunications companies such as GTE; and federal agencies, such as ARPA, the Defense Mapping Agency, the US Army Corps of Engineers, USDA Natural Resources Conservation Service, US Geological Survey, NASA, and NOAA. Universities, including the University of California at Berkeley, UCLA, Rutgers, and the University of Arkansas are supporting the project with considerable research and testbed activity. The Object Management Group (OMG), the pivotal consortium managing development of object technology standards, is also affiliated with OGC.

    Relationship to International Standards Community


    OGIS is on track to become a formal standard. Implementation of OGIS has been cited in the 1994 Plan for the National Geodata Infrastructure (NSDI) by the Federal Geographic Data Committee (FGDC) in recognition of the potential of the OGIS to become a significant enabling technology for the National Geodata Infrastructure (NSDI). Through the chair of the OGIS Working Group on Standards, the OGIS Project also maintains a close relationship with the ISO (International Standards Organization) TC/211 GIS/Geomatics Committee and the X3L1 ANSI (American National Standards Institute) Committee. Working groups of the OGIS Project Technical Committee are drafting the several component specifications that comprise OGIS. These drafts are circulated to the organizations and individuals in the geodata community who are most competent to judge the merits of specification details. The OGIS Project will produce a set of proposed standards that OGC intends to submit to ANSI and ISO for approval as formal standards. Prior to the formalization of those standards, some aspects of OGIS will perhaps also have been written into other standards, such as multimedia database query languages, that have a relationship to geodata.

    The OGIS Testbed Program is a key part of the OGIS Project. Coordinated by OGC, OGIS Testbed participants will implement portions of the specification for purposes of verification and improvement. OGIS is an abstract specification in the sense that it is language independent and distributed computing platform independent. Testbed teams will create parallel specifications for each of the main distributed computing platforms. Some of the testbed projects will be prototypes of systems intended to address major program requirements of the participating organizations or their clients. The first of many implementations of OGIS has already begun through OGC's Universal Geodata Access Consortium, a NASA funded collaborative involving Bell Communications Research (Bellcore), Rutgers University's Center for Remote Sensing, Camber Corporation, and NASA-GSFC (Goddard Space Flight Center). Other current and prospective testbed members include the University of California - Los Angeles (UCLA), California Resources Agency, NOAA (National Oceanic and Atmospheric Administration), Intergraph Corporation, USACERL, the National Geographic Society, the World Bank, MITRE Corporation, MacDonald Dettwiler, BB&N, the University of Arkansas, and the University of California - Berkeley.

    Because of the challenging and critical nature of OGC's approach, some of the most important intellectual leaders of the geoprocessing community have stepped forward to identify themselves with the OGIS Project and to make material contributions to the work of the OGIS Technical Committee. The participation of these individuals has indicated the degree to which the OGIS is seen by the organizations they represent to be a necessary next step in the direction of a global open system geoprocessing architecture that will facilitate economic progress and government effectiveness through the next decade.

    OGC is formed as a tax-exempt "membership corporation" (as defined in section 501c6 of the US tax code) for the purpose of furthering the consensus process organized to develop and promote Open GIS. Founded August 25, 1994 by the Board of Directors of the Open GIS Foundation (OGF), OGC has become a vital consortium of interested public and private sector organizations active in the geoprocessing community. These organizations are committed to supporting both the development of OGIS and the creation of a new generation of interoperability products positioned to stimulate global markets for both geodata and geoprocessing resources.

    The President of the OGIS Project is appointed by the OGC Board of Directors to manage the OGIS development process and the other activities of OGC. In addition to the President, the staff includes: Vice President, Technology Development; Vice President, Technology Programs, Vice President Corporate Communications; Director, Operations; Director, Academic Programs; and an administrative assistant. Within this framework the OGIS Project is organized as a Management Committee, a Technical Committee and the OGIS Testbed.

    Through its membership program the OGIS Project enables both public and private sector organizations to share in the development of a common standard for geodata interoperability and data exchange. In addition, members of the OGIS Project benefit from a uniquely effective technology transfer environment in which a wide variety of organizations are able to work together on resource and implementation issues and evolve the cooperative working relationships required for building a truly effective spatial information infrastructure.

    The membership fee structure (fees are listed in a separate OGC document at the end of this appendix Ð "OGIS Project Membership Application") distinguishes between four classes of members, as described below under OGIS Project Technical Committee.

    The OGIS Project Management CommitteeManagement Committee


    The OGIS Project Management Committee manages the OGIS Project Technical Committee and the entire OGIS Project. The Management Committee is comprised of: OGC's President; OGC's Vice President, Technical Development, who is also Chairman of the Technical Committee; OGC's Vice President, Technical Operations, who manages the OGIS Project Testbed; official liaisons to standards bodies; two or more representatives from the Technical Committee, who report between the Management Committee and the Technical Committee; the chair of the Management Committee's Earth Imaging Working Group, and management-level representatives from organizations which are Principal Members of the OGIS Project. The Management Committee is charged with strategic and business planning for the OGIS Project, final approval of the Technical Committee's specifications, management of the OGIS Testbed, and election of OGC Board members.

    The OGIS Management Committee is chaired by the President of OGC, who is responsible for initiating all business and strategic planning activities, coordinating relations with the Technical Committee, and managing the resources of the Consortium. The Management Committee meets at least three times per year. It is positioned through its membership and responsibilities to play an important role in shaping critical elements of the world's emerging geodata infrastructure.

    The OGIS Project Technical CommitteeTechnical Committee


    The OGIS Project Technical Committee is the primary operational unit of the OGIS Project. It is comprised of the technical representatives of all OGC member organizations and is charged with the creation of the OGIS. The Technical Committee does the bulk of its work through its Working Group structure, setting technology policy for the specification effort and processing Working Group proposals. Through the Technical Committee, member organizations are able to influence OGIS development by initiating technology proposals and voting on acceptance of proposals raised for consideration by the Working Groups.

    The membership fee structure distinguishes between four classes of members: Principal Members, who are granted voting representation on both the Management Committee and the Technical Committee; Testbed Members, who are granted voting representation on the Technical Committee are given special support in implementing testbed programs; Technical Committee Members, who are granted voting representation on the Technical Committee; and Associate Members, commercial, academic, and individual, who may attend meetings and subscribe to the project's information sources, but who may not vote or directly contribute working papers.

    The Technical Committee is chaired by OGC's Vice President, Technical Development, who directs its meeting process, maintains and edits project documentation, and oversees the development and integration of all specification activities. The Technical Committee meets at least four times per year in geographical locations chosen by its members, and Technical Committee Working Groups meet as necessary between full Technical Committee meetings. The open membership and voting process of the Technical Committee are designed to accommodate the needs of the broadest possible set of relevant industry participants, so that geoprocessing and geodata access in the future will serve the widest possible range of users and have as few technical limitations as possible.

    The OGC bylaws and the membership agreement place certain restrictions on members' distribution of OGIS documents, which are available to all members but which are the proprietary and confidential property of OGC.

    To facilitate the adoption of OGIS as an official standard and to ensure as much communication and efficiency as possible in worldwide geodata and geoprocessing standards efforts, some members of the OGIS Project Technical Committee are also members of the Federal Geographic Data Committee (FGDC); the ISO (International Standards Organization) TC/211 GIS/Geomatics Committee; and the X3L ANSI (American National Standards Institute) Committee. Because OGIS will in most cases be implemented with distributed object technology, the Technical Committee is also represented in the Object Management Group's Technical Committee.

    The OGIS Project TestbedOGIS Project Testbed


    The OGIS Project Testbed is an OGIS Project membership class which consists of organizations that join the OGIS Project for the purpose of working on early implementations of the OGIS specification. Such organizations make a substantial commitment of resources to application projects involving the OGIS, and they provide the vital test experience and practical feedback upon which full development of the OGIS is based.

    The Testbed is coordinated by the OGIS Project technical staff, who are responsible for defining the requirements of interoperable development environments and for arranging the information and resource sharingsharing necessary to implement true interoperabilityinteroperability among widely distributed Testbed installations. Testbed members are encouraged to participate in meetings of the OGIS Project Technical CommitteeTechnical Committee and its Working Groups, and they work closely with the Technical Committee to evaluate, test, and implement the OGIS, as well as to ensure the practical utility of the OGIS in live application environmentapplication environments.

    The Testbed objectives listed below are directed towards creating a structure that supports the evolution of the specification and its implementations to a level that is consistent with this vision.

  • 1. Create one or more APIs that support OGIS. Vendors and others will create OGIS-based APIs which provide environments in which other Testbed partners and ultimately other developers can create end-user applications.
  • 2. Work towards standardization of APIs which are developed in a common programming environment. The development of APIAPI's within individual programming environments (e.g. C++, OLE/COMOLE/COM, CORBACORBA, Java, etc.), should be standardized to whatever extent possible to ensure that the application programming environment is as open as possible.
  • 3. Create an OGIS implementation matrix demonstrating interoperabilityinteroperability at a number of levels. This matrix will track Testbed efforts on multiple distributed computing platforms, multiple geoprocessinggeoprocessing systems, and multiple application areas.
  • 4. Design and implement a mechanism(s) to certify and validate OGIS implementations. The Testbed phase will need to create the reference implementation against which conformance is measured and against which reliability, accuracyaccuracy and precisionprecision are evaluated and tested.
  • 5. Contribute, through development and implementation, to the evolution of OGIS. The Testbed sites and the Testbed Working Group will cooperate with the Technical CommitteeTechnical Committee to this end.
  • 6. Facilitate the development of implementations that interoperate across a range of existing Geographic Information System and geographic image databases.
  • 7. Cooperate with the Technical Committee, through development and implementation, to stabilize OGIS to the point where the specification is suitable for consideration by the standards community.
  • Participation in the OGIS Project Testbed is contingent upon membership in the OGIS Project and compliance with the requirements specified in OGC's bylaws. An interested member may prepare and submit a proposal for a testbed implementation for consideration by the Testbed Working Group. (See OGIS Project Document 94-023, Testbed Request for Participation.)

    Open GIS ConsortiumOpen GIS Consortium, Inc.

    35 Main Street, Suite 5

    Wayland, MA 01778

    Tel: (508) 655-5858

    Fax: (508) 655-2237

    http:/www.opengis.org


    Open GIS Consortium, Inc.



    ... dedicated to open systems geoprocessing





    MEMBERSHIP APPLICATION





    Organization (as you want name to appear in OGC documents):




    Address:


    Phone: Fax:



    Type of organization (vendor, integrator, government agency, etc.):




    Designated Business/Marketing Representative:

    Name:

    Title:

    Address:


    Phone: Fax:



    Email:



    Designated Technical Representative:


    Name:


    Title:


    Address:


    Phone: Fax:



    Email:



    OGC MEMBERSHIP APPLICATION (cont.)




    OGC defines four Levels of Membership available to public and private sector organizations interested in supporting the development and implementation of OGIS:



    Principal Members are granted voting rights on the Management Committee which determines the strategic direction for the OGIS Project and approves both business plans and technical proposals. They also vote to elect members of the Open GIS Consortium board of directors, and are granted membership in the OGIS Technical Committee. Principal Members receive as well the benefits of membership in the OGIS Testbed program.



    Testbed Members are granted membership in the OGIS Technical Committee and are also provided with technical consultation in support of OGIS implementation activities. Testbed members are entitled to work closely with members of the OGIS Technical Programs team to devise implementation strategies and are entitled to full participation in the Technical Committee and its working groups and subcommittees.



    Technical Committee Members are granted voting rights on the OGIS Technical Committee which processes proposals for development of the Open Geodata Interoperability Specification. Technical Committee members may represent their organizations in any working groups or subcommittees of the Technical Committee and have the right to initiate proposals for full Technical Committee consideration.



    Associate Members are granted non-voting membership in the Technical Committee and have access to all written and electronic communication functions of the Consortium. Associate Members are able to participate in working groups and sub-committees of the Technical Committee. Commercial enterprises, university administrative units, and qualified individual contributors may become Associate Members.



    Annual membership fees for the four Levels of Membership are as follows:



    Level of Membership Fee



    Principal Member $50,000



    Testbed Member (includes Technical Committee Membership) $20,000



    Technical Committee Member $10,000



    Associate Member (commercial) $ 4,000


    Associate Member (university and individual) $ 300



    Please enter the Level of Membership you have selected:


    Level: ____________________________ Fee: $_______________



    Payment is due upon receipt of application. Make check payable to the Open GIS Consortium, Inc. All fees paid to the Open GIS Consortium are tax exempt. Membership renewal is on an annual basis from the date of the initial application. Fees are not refundable. Contact the Open GIS Consortium office for additional information (Tel. 508-655-5858; Fax 508-655-2237). Mail this application with your check to Open GIS Consortium, 35 Main Street, Suite 5, Wayland, MA 01778 (USA).




    I hereby apply for membership in the Open GIS Consortium and agree to be bound by the by-laws of the consortium as from time to time in force.



    Authorized Signature:


    Name:

    Title:


    Effective/Renewal Date:



    [ Table Of Contents ] [ Appendix C ] [ Index ]


    Appendix D Bibliography

    Technology Foundations

    Cook, Steve and Daniels, John. Designing Object Systems: Object-Oriented Modelling with Syntropy, Prentice Hall, London 1994.

    Craig, Chambers and LeavensChambers and Leavens, Gary T. "TypeType Checking and Modules for Multi-Methods," 1994. Proceedings of the OOPSLA 1994, Portland, Oregon.

    Object Management Architecture Guide, OMGOMG Technical Document 90-991, Object Management Group, Inc., 492 Old Connecticut Path, Framingham, MA 01701, November 1990.

    Orfali, Robert; Harkey, Dan; and Edwards, Jeri. The Essential Distributed Objects Survival Guide.)

    Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; and Lorenson, William. Object Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ, 1991.

    Taylor, David A. Object Oriented Technology, Addison-Wesley Publishing Co., Reading, MA, 1990.

    Open GIS

    Anderson, David L. "NRCS Business Geospatial Applications Drive the Need for Open Systems." Geo Info Systems, May 1995 : 47-48.

    Ashworth, Mark. "GIS Extensions to SQLSQL and Beyond." ACM StandardView, 2 (1994) : 175-77.

    Astroth, Joseph. "OGIS: Planting the Seeds for Rapid Market Growth." Geo Info Systems, January 1995 :55+.

    Ayers, Lawrence F. "What Are Open Geographic Data?." Geo Info Systems, January 1995 : 60.

    Bachula, Gary R. "Geodata Infrastructure: On the Road to Twenty-First Century Economic Success." Geo Info Systems, May 1995 : 46+.

    Buehler, Kurt. "The OGIS Technical CommitteeTechnical Committee: Purpose, Status, and Future." Geo Info Systems, January 1995 : 48.

    Buehler, Kurt. "Charting Our GIS Technology Course." Geo Info Systems, May 1995 : 64.

    Buehler, Kurt. "OGIS Augments Data Transfer." GIS World, October 1994 : 60-63.

    Buehler, Kurt. "OGIS Paves the Way to GIS Interoperability." GIS World, October 1994 : 60-63.

    Buehler, Kurt and James A. Farley. "Interoperability of Geographic Data and Processes: The OGIS Approach." ACM StandardView, 2 (1994) : 163-68.

    Buehler, Kurt and Lance McKee, The Open Geodata Interoperability Guide (pending publication : June 1995).

    Cargill, Carl. "The Challenge for OGCOGC." Geo Info Systems, May 1995 : 52..

    Coullahan, Robert J. "The Complimentary Missions of OGCOGC and CIESN." Geo Info Systems, May 1995 : 57-58.

    Dangermond, Jack. "Many Paths to Open GIS." Geo Info Systems, January 1995 : 59.

    Doyle, Allan. "Software That Plays Together-A System Integrator's Viewpoint." Geo Info Systems, May 1995 : 50-51.

    Esdale, Paul. "Open Systems and Data Base Visualization." Geo Info Systems, May 1995 : 62- 63.

    Farley, James A. "The OGIS Project TestbedOGIS Project Testbed." Geo Info Systems, January 1995: 50-51.

    Fegeas, Robin G. "OGIS-Building on SDTSSDTS." Geo Info Systems, January 1995: 57-58.

    Gardels, Kenneth. "Ceres and ELIB: A Distributed Digital Library of Environmental Information." Geo Info Systems, May 1995 : 56-57.

    Gardels, Kenn. "Open Geodata." Geo Info Systems, January 1995 : 47+.

    Gardels, Kenn, et al., "The Evolution of OGIS." Grassclippings, 7.3 (1994) : 4+.

    Gardels, Kenn. "An Introduction to the Open Geodata Interoperability Specification (OGIS)." Grassclippings, 7.2 (1993) : 7+.

    Gardels, Kenn. "What is Open GIS?" Grassclippings, 7.1 (1993) : 40.

    "GIS Newslink: Meeting Brings New Members and Urgency to OGIS Development (OGIS Technical CommitteeTechnical Committee Meeting, March 15-17, 1995)." GIS World, May 1995 : 16.

    "Heavy Hitters of GIS: The 10 Most Influential People for 1995." GIS World, April 1995 : 42-48.

    Hecht, Louis G. "Open GIS Foundation Fosters Industry Synchronization." GIS World, February 1994 : 24.

    Henriksen, Clem, J.P. Lauzon and Scott Morehouse. "Open Geodata Access Through Standards." ACM StandardView, 2 (1994) : 169-74.

    Herring, John. "OGIS and the RDBMS Vendor." Geo Info Systems, May 1995 : 60.

    Ireland, Elizabeth. "Data Access is the Path to Mainstream Mapping Applications." Geo Info Systems, May 1995 : 61-62.

    Kevany, Michael J. and Nancy von Meyer, "Opportunities and Challenges: A Community Approach to Open Systems." Geo Info Systems, November/December 1995 : 16.

    Kottman, Cliff. "Interoperability = Joint Doctrine = Institution Building." Geo Info Systems, May 1995 : 60-61.

    Kottman, Clifford A. "Open GIS Software: An Industry View." ACM StandardView, 2 (1994) : 159-62.

    Limp, Fred. "State and Local Governments-Key Benefic-iaries of Open GIS." Geo Info Systems, January 1995 : 54.

    McKee, Lance. "Work Progresses on Geoprocessing Road Map." GIS World, October 1995 : 60.

    Mularz, Diane E., H. Gregory Smith and Thomas J.Mowbray. "Realizing the NSDI Vision Through a Community Architecture." Geo Info Systems, January 1995 : 52-53.

    Muntz, Richard, et al., "Integrating Distributed Object Management into EOS." Geo Info Systems, May 1995 : 58-59.

    Reed, Carl. "gIS: An Expanded Role for GIS." Geo Info Systems, January 1995 : 56.

    Schell, David. "Open GIS: Community Intellectual Property." GIS World, September 1995 : 62.

    Schell, David. "What Is the Meaning of Standards Consortia?" GIS World, August 1995 : 82.

    Schell, David. "Harnessing Change." Geo Info Systems, May 1995 : 44-45.

    Schell, David, Lance McKee and Kurt Buehler. "Geodata Interoperability-A Key NII Requirement." (White Paper submitted to the NII 2000 Steering Committee of the Computer Science and Telecommunications Board of the National Research Council, April 27, 1995).

    Schell, David. GIS Guest Editorial. ACM StandardView, 2 (1994) : 132..

    Schell, David. "Automated Geodata Interoperability." CALS/Enterprise Integration Journal, 3.4 (1994) : 57-61.

    Schell, David. Editorial. Grassclippings, 7.2 (1993) : 4-5.

    Smith, H. Gregory, and Diane E. Mularz. "Standards as the Basis for Development of a Spatial Information Infra-structure Architecture." ACM StandardView, 2 (1994) : 155-158.

    Sonnen, David H. "Standards and Interoperability: Key to GIS Market Growth." Grassclippings, 7.3 (1994) : 10+.

    Strand, Eric. "Inside OGIS." CALS/Enterprise Integration Journal, 3.4 (1993) : 58.

    Strand, Eric. "GIS Plug and Play is on the Way." GIS World, January 1995 : 30-32.

    Strand, Eric. "Federal GIS Standards: Think Globally, Act Locally." GIS World, September 1994 : 38-40.

    Strand, Eric., Rajiv P. Meheta and Raju Jairam. "Applications Thrive on Open Systems Standards." ACM StandardView, 2 (1994) : 148-54.

    Strand, Eric. "Open GIS Specification Open for Comment." GIS World, February 1994 : 26-28.

    Strand, Eric. "Open GIS Unlocks Private Geodatabases." GIS World, November 1993 : 24- 25.

    Tom, Henry. "GIS Community Participation in National Information Infrastructure (NII) Standards Efforts." Geo Info Systems, January 1995: 49.

    Tom, Henry. "The Geographic Information Systems Standards Infrastructure." ACM StandardView, 2 (1994) : 133-42.

    Tosta, Nancy. "Standards to Support the National Geodata Infrastructure." ACM StandardView, 2 (1994) : 143-147.

    Updegrove, Andrew. "Setting Standards on Firm Foundations: Consortia Structures and Consensus Building." Geo Info Systems, May 1995 : 52+.

    Updegrove, Andrew. "Forming, Funding and Operating Standard-Setting Consortia." IEEE Micro, December 1993 : 52-61.


    INDEX - Please note that the page numbers do not appear on the on-line version, this will be corrected shortly.

    -A-

    abstract data types, 39
    accuracy, 9, 37, 38, 47, 48, 50, 58, 87, 92, 93, 110
    address space, 25
    ADT, 39
    aggregation, 35, 46, 59
    AM/FM, 7, 90
    API, 11, 17, 25, 26, 27, 29, 87, 92, 110
    applets, 7, 24, 29
    application environment, 27, 30, 31, 37, 48, 88, 110
    Application Layer, 24
    Application Server Layer, 24
    architectural objectives, 11
    ASCII text, 23
    association property, 35
    attributes, 17, 36- 39, 44, 46, 50, 56-60, 62, 73, 76, 78, 84- 87, 89, 92
    attribution model, 38, 41, 92
    authoritative catalog, 67
    authoritative feature registry, 64

    -B-

    bag, 43, 61
    Base Information Definition, 48, 54, 64, 65, 88
    bootstrapping, 67
    BufferZone, 84, 85

    -C-

    CAD system, 45, 88
    catalog, 10, 15, 50, 53, 65-68, 88, 90
    Catalog creation, 67
    Catalog Entry Schema, 65, 66, 67
    Catalog Registry, 66
    Chambers and Leavens, 72, 114
    class, 72
    clients, 7, 21, 22
    closed curve, 42, 43
    Collection Type, 81
    complex geometries, 43
    complex polygon, 43
    componentware, x, 5, 6, 7, 32
    compound document, 7, 8
    conceptual view, 35, 36
    control integration, 28
    conventional programming methods, 9, 14, 20, 25, 2691
    Cook and Daniels, 17, 32, 33, 35
    coordinate dimension, 44, 46
    coordinate geometry, 35, 38, 43, 44, 46, 47, 84
    coordinates for space and time, 46
    CORBA, 4, 8, 17, 18, 19, 39, 76, 110
    corporate database, 21
    coverages, 14, 36, 37, 38, 40, 88
    curve, 42, 73

    -D-

    data access, 21, 22, 24, 29, 53, 62
    Data Access Servers, 22
    data integration, xi, xii, 28, 52, 53, 54, 60
    data sharing, xii, 3, 9, 12, 51, 52, 53, 54, 62, 70
    ad hoc data sharing, 53
    Data Sharing Examples, 58
    data transfer, xi, 3, 23, 52
    data types, xi, 9, 12, 14, 19, 22, 31, 38, 39, 41, 42, 63, 72, 81, 85, 86, 89, 90, 92
    database management, 7, 13, 22, 24, 25, 64, 89
    DBMS, 72, 73, 89
    DCE, 4, 8, 17, 18, 89
    DCP, 5, 9, 17-19, 20, 23, 24, 28, 29, 31, 50, 52
    de facto standard, 5, 91
    de jure standard, 5, 91
    dependence of existence, 35
    derivative feature collection, 50
    desktop environments, 8
    distributed access, 4, 21
    diversity, 12, 30, 58
    domain group, 37, 38, 46, 48
    dynamic segmentation, 40

    -E-

    Earth model, 32, 33
    encapsulation, 6, 11, 20, 31
    entities, 1, 17, 29, 32, 33, 34, 36, 42, 67, 89, 90, 92
    Error budgets, 47
    essential model, 32, 33, 34, 35, 37, 38, 39, 40, 44, 47, 63
    exchange of information, 49
    extensibility, 30, 31

    -F-

    feature collection, 37, 50, 51, 52, 53, 57, 58, 79, 85, 86, 88, 89, 92
    feature definitions, xi, 10, 15, 37, 49, 53, 56, 59, 90
    feature registry factory, 67
    Feature schemas, 64
    Feature type, 63
    FeatureCatalog, 65
    FeatureSchema, 63, 64, 70, 71
    FeatureTranslators, 70, 71
    format, 2, 3, 17, 20, 23, 87, 89, 93, 97, 101, 103, 104
    format conversions, 23
    formats, 2, 3, 23, 29, 87, 92, 104
    functional API, 26, 27

    -G-

    Generic Data Store, 24
    Generic Database, 24
    geodata access, 4, 5, 12, 22, 49, 72, 107, 110
    granularity of access to data, 64
    geodata collections, 49
    geodata inconsistencies, 48
    geodata interoperability, x
    geodata model, x, xi, xii, 13, 14, 23, 25, 31
    geographic coordinates, 20
    geometric entities, 42
    geometry, xi, 32, 34, 35, 37, 38, 39, 42, 43, 44, 46, 47, 48, 56, 72, 84
    geoprocessing, x, xi, xii, 2, 4, 5, 6, 7, 8, 11, 12, 13, 14, 15, 16, 19, 20, 21, 23, 24, 25, 27, 30, 31, 32, 34, 48, 49, 54, 70, 72, 90, 91, 107, 108, 110, 112
    geoprocessing channel, 5
    global positioning systems (GPS) 1, 2, 8, 46, 90
    graphics, 3, 29, 32, 89

    -

    H-

    heterogeneous geodata, x, 28, 107
    holes, 43

    -I-

    IDL, 18, 73
    imagery, 1, 29, 35
    implementation model, 17, 32, 39
    inconsistent collections, 38
    Information Communities, xi, 4, 9, 10, 12, 48-63, 71, 76, 78, 92
    source Information Community, 51, 52, 54, 70, 71, 92
    target Information Community, 51, 52, 60, 70, 71, 92
    Information Communities Model, xi, 4, 10, 49, 51, 56, 62
    information manager, 8
    inheritance, 20, 21
    Interface Repository, 76
    Internet, 8, 64
    interoperability, x, xi, xiii, 3, 4, 6, 9, 16, 18, 19, 22, 23, 26, 30, 38, 42, 48, 60, 64, 89, 91, 96, 107, 108, 109, 110
    interoperable geoprocessing, 5, 7, 27
    interprocess communication, 25
    Iterator, 80, 81
    Iterator Type, 81

    -L-

    Landsat, 36, 91, 92
    legacy geodata, 6
    level of abstraction, 32
    lexicon, 12, 19, 21, 37
    line string, 41, 42, 43
    LineString, 73
    lingua franca, xi, 19
    locate function, 46
    location, 1, 34, 35, 38, 42, 43, 46, 47, 50, 67, 74, 88, 90
    actual terrestrial locations, 46

    -M-

    machine boundary, 26
    Management Committee, xii, 5, 95, 105, 107, 109, 113
    Master Catalog, 67
    mathematical representation, 35
    message broadcasting, 29
    metadata, xi, 3, 14, 15, 24, 36, 37, 41, 42, 48, 50, 52, 54, 57, 60, 62, 64, 65, 76, 88, 91, 92
    methods, 1, 2, 3, 9, 12, 14, 20, 27, 50, 91, 94
    middleware, 6, 8, 11, 25, 32, 51
    minimum bounding rectangle, 43
    monolithic GIS, 7, 24, 29

    -N-

    network security, 29

    -O-

    object API, 26, 27
    object identity, 39
    Object Query Service Specification, 79
    object technology, xi, 16, 20, 108, 110
    object type, 32, 33, 35, 85
    object wrapper, 26
    OGIS interfaces, xi, 5, 6, 7, 24, 25, 27, 53, 63
    OGIS Project Testbed, 18, 19, 24, 109, 110, 111, 115
    OGIS Query Service, 79
    OGIS Services Model, xi, 4, 9, 10, 19, 21, 22, 27, 32, 37, 38, 41, 42, 54, 63
    OGIS Specification Model, xi, 9, 11, 27, 91
    OGM, xii, 4, 41
    OID, 39
    OLE/COM, 4, 8, 17, 110
    OMG, 4, 18, 19, 73, 79, 108, 114
    OMG Query Service, 79
    OMT diagrams, 18, 33
    OO programming, 20, 25
    Open Geodata Model, xi, xii, 4, 9, 10, 15, 17, 19, 21, 22, 31, 32, 33, 34, 35, 36, 37, 41, 42, 48, 56, 58, 63, 64, 88, 90, 91
    Open GIS Consortium, v, vi, x, 3, 95, 97, 98, 107, 111, 113
    open systems, 7, 30, 112
    OpenDoc, 4
    Operation Registry Model, 74
    OperationEntry, 75, 76
    OperationRegistry, 73, 74, 75, 76
    OperationSchema, 75
    OQL, 85
    OSF, 4

    -P-

    phenomena, x, 1, 2, 4, 11, 19, 32, 33, 34, 35, 36, 37, 56, 90
    pillaging, 53, 54
    Pluggable Computing Model, 27, 28, 29, 30, 31, 49
    Point, 2, 42
    Point vector data, 2
    Policies and Procedures, 95-106
    polygons, 1, 40, 88, 94
    precision, 48, 50, 87, 92, 110
    Presentation integration, 28
    Presentation Layer, 24
    primitive data types, 19, 38, 41, 42, 92
    process boundary, 25
    process invocation, 29
    projection functions, 44
    properties, 14, 17, 30, 35, 37, 38, 39, 41, 42, 49, 63, 64, 65, 67, 69, 78, 79, 84, 86, 93
    proprietary query language, 25

    -Q-

    qualifier, 38
    Query Languages, 84
    Query Model, 82, 84
    query string, 80, 82, 83
    Query type, 82
    queryable objects, 24
    QueryEvaluator, 81, 82, 83
    querying objects, 24
    QueryManager, 80, 82, 83

    -R-

    Raster, 1, 40, 92, 94
    real world, 17, 34, 35, 36, 43, 46, 61, 63, 89
    recursive feature, 38
    reference system, 3, 14, 15, 34, 35, 36, 37, 38, 39, 40, 41, 43, 44, 45, 46, 47, 48, 64, 67, 68, 69, 72, 85, 88, 90, 93
    Reference System Transform, 68
    reference system types, 45, 46
    remote procedure call, 23, 29
    remote sensing, x, 7, 13, 19, 56
    reuse, 21

    -S-

    scalability, 30
    scale, 20, 33, 91
    schema, 38, 39, 41, 42, 49, 52, 53, 58, 59, 60, 63, 64, 65, 67, 69, 70, 71, 76, 79, 86
    SDTS, 23, 115
    semantic integrity, 55
    semantic mismatch, 54
    semantic properties, 37, 41
    semantic properties of a feature, 41
    Semantic Translation, 69
    Semantic Translator, 51, 52, 53, 54, 61, 62, 69, 70, 71, 92
    semantics, 9, 25, 48, 49, 50, 51, 52, 53, 54, 55, 57, 82
    SemanticTranslatorDefinition, 71, 72
    SemanticTranslatorRegistry, 70, 71, 72
    server, xi, 5, 7, 8, 9, 12, 14, 16, 18, 21, 22, 25, 29, 93
    service interface, 14, 15, 29
    service provider, 21, 22, 26, 27, 87, 88, 90, 91, 93
    sharing, x, xii, 2, 3, 4, 7, 9, 12, 13, 15, 30, 49, 51, 52, 53, 54, 55, 56, 57, 62, 63, 70, 110
    slave catalog, 50
    sourceSchema, 71
    Spatial Data Access Provider, 23, 24, 25
    spatial/temporal reference system, 34-38, 43-47, 68, 69, 72, 85
    Spatial/Temporal Reference System Access, 67, 68
    spatial/temporal reference system definitions, 68
    Spatial/Temporal Reference System Transformation, 68
    specification model, x, xi, 4, 9, 11, 17, 27, 32, 33, 34, 48, 63, 70, 75, 78, 80, 81, 91
    Spline functions, 40
    SQL, 25, 85, 86, 92, 94, 114
    SQL3, 39
    standards, xii, 3, 14, 17, 25, 27, 53, 54, 57, 79, 85, 87, 89, 91, 92, 101, 102, 107, 108, 109, 110
    structured programming, 25
    subclass, 21
    subtype, 39, 72, 73, 74
    superFeatureCatalog, 65
    Surface, 42, 61, 88, 93
    swarms of objects, 24
    symbology, 33, 35

    -T-

    targetSchema, 71
    Technical Committee, iv, vi, x, xii, xiii, 5, 11, 13, 18, 20, 32, 33, 53, 69, 95, 96, 97, 100, 101, 103, 104, 105, 106, 107, 108, 109, 110, 113, 114, 115
    temporal dimension, 14, 35, 46
    TemporalObject, 85
    Time, 34, 46
    time continuum, 34
    Tools Services, 28
    topological dimension, 46
    topologies, 42
    topology, 42
    Trader, 51, 53, 79, 91, 93
    TraderSchema, 79
    Transfer Standard, 23, 58
    Transform Schema, 69
    transformation between two reference systems, 45
    transformations between types, 46
    translateFeature() operation, 71
    Triangulated Irregular Networks, 40
    tuples, 46
    Type, 39, 40, 41, 42, 59, 71, 76, 77, 78, 81, 82, 112, 114
    type view, 35, 38
    TypeFactory, 77, 78, 79
    TypeRegistry, 78, 79

    -V-

    value of dimension, 44
    vector data, 2
    video, 29
    virtual reality, 33
    Visual Basic, 17, 23, 24

    -W-

    well known structures, 41
    workflow, 24, 25, 28, 29, 31
    World Wide Web, 3, 53
    wrapper, 26

    Copyright © 1996, Open GIS Consortium, Inc.