Introduction

An ad-hoc meeting was held at the June 2004 Technical Committee meeting to discuss the issue of GeoAPI Management as it applies to geospatial data and services. Discussion at this meeting focused on the management and direction of GeoAPI. After discussion, the ad-hoc approved a motion to establish the GeoAPI working group within the Open GIS Consortium Technical Committee for the purpose of addressing GeoAPI Management and the related OGC Specifications and Recommendation papers implemented in GeoAPI that apply to geospatial applications.

This document establishes an operational Charter for a GeoAPI Working Group within the Open GIS Consortium, Inc. (OGC) Technical Committee devoted to management and implementation of applicable geospatial specifications.

Mission and Objectives

Mission

The development community in building GIS solutions is sustaining an enormous level of effort. The GeoAPI project aims to reduce duplication by providing a neutral, interface-only Java API based upon existing and proposed OGC Standards, that GIS projects can use to interoperate. While the current GeoAPI project is primarily interested in Java, this does not preclude the use of other languages in the future.

Background and Problem Statement

A wide range of GIS solutions are available in Java, but each of them uses their own API. This leads to vendor and version lock-in situations, in which clients have to develop against a particular implementation and cannot easily switch implementations. The variety of APIs is also a barrier to interoperability at the Java object level. A set of interfaces accepted by major vendors would help to free the client from lock-in, and would help to increase interoperability.

The JDBC framework in Java 2 Standard Edition (J2SE) is a successful example of an interface-only specification. Vendors provide implementations of those interfaces for their particular database product. The same vendor can even provide many implementations targeting the same database, with different performance, security and ease-of-deployment tradeoff. The clients interact through the interfaces, no matter which particular implementation is actually used. The goal of GeoAPI is to achieve for GIS what JDBC achieved for databases.

UML models provided in abstract specifications are the starting point, but they are not directly useable in Java programs. Therefore UML must be expressed as Java interfaces. Since there is not always a one-to-one relationship between entities found in abstract specifications and Java concepts, some interpretations and manual re-work are required. Practical consideration related to interoperability with existing libraries (e.g. Java2D, Java3D, Java Advanced Imaging) as well as performance issues (e.g. avoiding garbage collection overhead) infrequently lead to minor departure and/or extensions to the abstract specifications. At this point in time, projects perform their own interpretation of abstract specifications, resulting in varying interpretations of the UML when it is rendered to API form.

Objectives

The objectives for the GeoAPI Working Group are:

  1. Project management of the GeoAPI SourceForge project (as W3C manages web specifications).
    • Insuring that everything that goes into this project is tied to OGC specifications and recommended practices.
    • Identifying project tasks and setting priorities and target dates for them.
    • Grouping pending tasks for successive project release versions.
  2. Development of Java API's from geospatial specifications and recommendation papers.
    • API's include but are not limited to; Topic 1 (ISO 19107), Topic 2 (ISO 19111), Topic 11 (ISO 19115), Grid Coverage Services, OGC GO-1 Application Objects, Topic 5: OGC Feature Model.
    • Collaborate with related OGC Working Groups to ensure adherence to specifications and two-way flow of information and ideas.
    • Utilize available UML in translating to Java interfaces.
  3. Requirements management for the GeoAPI project.
    • Solicit feedback on the utility and usability of GeoAPI interfaces.
    • Solicit written change requests for modification or deprecation of existing or addition of new GeoAPI interfaces.
    • Discuss, accept, modify, or reject proposed changes to GeoAPI interfaces.
  4. UML model management for the GeoAPI SourceForge project.
    • Create appropriate UML models for accepted GeoAPI interfaces.
    • Modify UML models to conform to approved modifications to GeoAPI interfaces.
  5. Validation and verification of commercial and open source implementations of GeoAPI interfaces.
    • Develop or make available Test Harnesses.
    • Develop or make available appropriate Test Procedures.
    • Incorporate tests in OGC CITE process.
  6. Manage the process of moving UML models through the spec process so they become OGC (and ISO/TC211?) specifications.
    • Identify appropriate TC/WG to propagate changes and new specifications.
    • Prepare TC211 NWIPs.
  7. Following every TC meeting, a posting on the GeoAPI site with actions, recommendations, and work items for the next quarter.

Approach

As a Working Group of the Open GIS Consortium Technical Committee, the GeoAPI Working Group will be organized and operate in accordance with the Standard Operating Procedures of that body. Activities of the GeoAPI Working Group related to the organization, coordination, and execution of interoperability experiments will be performed in accordance with the Standard Operating Procedures of the Open GIS Consortium Interoperability Program.

Work Plan

GeoAPI is an umbrella API incorporating several specifications and working groups. Progress in this domain will be achieved as follows:

  1. Development and maintenance of a GeoAPI roadmap including business objectives, requirements, Measurements of Effectiveness (MOE), technologies, integration/architecture patterns, and specifications/standards.
    • Provide Java API's for geospatial specifications and recommendation papers to include but not limited to the following: Topic 1 (ISO 19107), Topic 2 (ISO 19111), Topic 11 (ISO 19115), Grid Coverage Services, OGC GO-1 Application Objects, Topic 5: OGC Feature Model.
  2. Managing partnerships with other organizations as appropriate � drawing on expertise from the broader geospatial community.
  3. Identification of on-going efforts and organizations addressing issues identified in the roadmap.
  4. Formulation of rules for translating UML entities to Java interfaces.
  5. Application of rules to translate UML to Java, including interpretation and manual revision steps.
  6. Validate resulting Java interfaces against UML, using automated tools where possible.
  7. Establish, manage, and execute GeoAPI Interoperability Experiments and infrastructure to mature and validate the roadmap. Test and validate the use of broad, standards-based technologies in conjunction with adopted and in-work OpenGIS specifications.
  8. Promote the successful results of GeoAPI work for adoption and practical implementation in the community.

Coordination

Membership in the GeoAPI SourceForge project is encouraged, but not limited to OGC members. This is to allow broader participation, and reflects the existing membership that is a cross section between OGC, ISO, and non-member academics and organizations. The GeoAPI project is also related to a number of existing open source GIS initiatives, including but not limited to GeoTools, degree, uDig, GeoServer, Gnumeric, Seagis, and OpenMap. Coordination between this working group and these projects is planned.

Membership

The OGC GeoAPI Working Group is open for participation by all interested OGC members.