The GeoAPI project emerged from the collaboration of several free software projects and from the work on various specifications at the Open Geospatial Consortium (OGC). You can follow the early, pre-history of GeoAPI by reading the following three posts to the DigitalEarth.org website; at this point it had no name, only a goal of bringing together multiple Java GIS projects.

• Call for a Geo-Spatial API
• Java GeoSpatial API Part II
• Java GeoSpatial API Part III

In part III, the OGC had just announced a Geographic Objects initiative which intended to define Java interfaces for geographic software. This followed earlier work on the OGC Implementation Specification 01-009 Coordinate Transformation Services which included interfaces defined in the org.opengis namespace ultimately adopted by GeoAPI.

The GeoAPI project eventually formed to pursue this work. The interfaces defined in the OGC specification 01-009 became GeoAPI version 1.0. In May 2005, the final version of the OGC specification 03-064 GO-1 Application Objects, which included GeoAPI interfaces, was accepted as an OGC standard and the matching version of GeoAPI was released as version 2.0.

The GeoAPI 3.0 working group of the OGC has formed in January 2009 to formalized and continue the work of standardizing the most stable interfaces produced by the GeoAPI project. The GeoAPI specification produced by this group became an OGC standard in April 2011.

GeoAPI is closely tied to the OGC both in its origins and in its ongoing work.

The GeoAPI project is a collaboration of participants from various institutions and software communities. The GeoAPI project is developing a set of interfaces in programming languages to help software projects produce high quality geospatial software. The core interfaces follow closely the specifications produced in the 19100 series of the International Organization for Standardization (ISO) and by the OGC. The interfaces use the org.opengis namespace and copyright to the code is assigned to the OGC. The project started with the code produced by the OGC Implementation Specification 01-009 Coordinate Transformation Services and refactored this code in collaboration with the standardization work surrounding the OGC specification 03-064 GO-1 Application Objects.

The GeoAPI working group of the OGC is a separate effort made up principally of members of the OGC and formed to continue the work of formalizing the interfaces developed by the GeoAPI project as ratified standards of the OGC. The working group decided to start the GeoAPI Implementation Specification as a new standard focused exclusively on the interfaces produced by the GeoAPI project. In acknowledgment to the earlier work and to match the numbering scheme of GeoAPI, the first specification released under this name carry the 3.0 version number.

We believe that both approaches are complementary. Web services are efficient ways to publish geographic information using existing software. But some users need to build their own solution, for example a numerical model. Many existing software packages provide sophisticated developer toolkits, but each toolkit has its own learning curve, and one cannot easily switch from one toolkit to another or mix components from different toolkits. Using standardized interfaces, a significant part of the API can stay constant across different toolkits, thus reducing both the learning curve (especially since the interfaces are derived from published abstract UML) and the inter-operability pain points.

The situation is quite similar to JDBC (Java DataBase Connectivity)'s one. The fact that a high-level language already exists for database queries (SQL) doesn't means that low-level programming interfaces are not needed. JDBC interfaces have been created as a developer tools in complement to SQL, and they proven to be quite useful.

Web services and standard data formats are useful for transferring data to the scientist who processes them. But this approach become unpracticable with the very large amount of Earth Observation data. Instead, there is a need to do the opposite way - transfer the algorithm to the data in a cloud environment. In a situation where both the data and the user (the algorithm) are on the cloud, web services and standard data formats may not apply anymore at processing time (they are still relevant for fetching the processing results however). Instead, cloud environments like Google Earth Engine or Amazon Lambdas allow execution of user-defined algorithms in Python, Java or other programming languages, where no data transfer happens from user's perspective (whether data transfers happen under the hood when some commands are executed is implementation details). But those environments are currently defining their own APIs, at the risk of vendor-lockin. Defining a standard API suitable for cloud environments is part of GeoAPI goals.

We try to carefully avoid implementation-specific API. Again, JDBC is a good example of what we try to achieve. JDBC is an example of successful interfaces-only specification implemented by many vendors. Four categories of JDBC drivers exists (pure Java, wrappers around native code, etc.). Implementations exist for Access, Derby, HSQL, MySQL, Oracle, PostgreSQL and many others.

It is important to stress out that GeoAPI is all about interfaces. Concrete classes must implement all methods declared in their interfaces, but those interfaces don't put any constraint on the class hierarchy. For example GeoAPI provides a MathTransform2D interface which extends MathTransform. In no way do implementation classes need to follow the same hierarchy. Actually, in the particular case of MathTransforms, they usually don't! A class implementing MathTransform2D doesn't need to extend a class implementing MathTransform. The only constraint is to implement all methods declared in the MathTransform2D interface and its parent interfaces.

The ISO 19103, 19111 and 19115 specifications define mostly data structures convertible to XML or database schemas. Indeed, the EPSG database schema follows closely the ISO 19111 structures. However those ISO specifications define few operations. For example ISO 19111 provides data structures for describing accurately Coordinate Reference System objects, but does not said much about how to get instances of them (except from a geodetic dataset). In terms of programming languages, the above-cited ISO specifications define mostly no-argument getter methods. Few methods performing calculation based on parameter values are specified.

Since GeoAPI targets programming languages rather than data formats, we provide some more methods performing operations from programmatic parameters. Rather than inventing our own, we fetch those methods from other OGC specifications - including retired specifications - as much as possible. Those methods are documented in various places:

• In the "Comparison with legacy OGC specifications" annex in the GeoAPI specification .
• In the list of departures from the ISO/OGC specifications (also an annex in the GeoAPI specification).
• In source code, class files and javadoc using the UML annotation associated with the OGC 01-009 specification enum or another OGC enum.

GeoAPI defines also a few convenience methods for frequently used operations (for example fetching the Coordinate Reference System of an Envelope) and methods for inter-operability with the standard library. Those methods are also documented in the departures page. Another reason is to adapt to constraints of target programming language (e.g. Java has no direct equivalent for the C/C++ enum construct).

We tried that path at the beginning of GeoAPI project, and abandoned it. Automatic scripts provide useful starting points, but their output do not alway match the expectations of developers. For example a popular approach is to generate Java classes from the XML schemas using JAXB-related technologies. Unfortunately the XML schemas defined by ISO 19139 are quite unusual, introducing a lot of redundant elements (e.g. citation property values wrapped in CI_Citation XML elements, and so on for all other properties). API generated from those schemas are twice bigger than the conceptual model.

We could derive the API from the UML in Rational Rose format instead of the XML schemas, but a lot of human intervention is still essential. The relationship between UML and programmatic interfaces is not always straightforward. For example:

• Structures of type union are expressed in Java either by rearranging the interface hierarchy, by interface multi-inheritance or by omitting the data structure, on a case-by-case basis.
• Resolution of some specification overlapping require human reading. For example ISO 19111:2007 section 3 specifies "in this international standard, normative reference to ISO 19115 excludes the MD_CRS class and its components classes" in order to avoid duplication. An automatic script would not have done this exclusion.
• Some complexity introduced by historical standardization processes can be avoided. For example ISO 19115-2 defines imagery metadata which were not ready in time for the ISO 19115 schedule. Since new attributes could not be added to the existing ISO 19115 classes, they were added in ISO 19115-2 sub-classes of the same name (e.g. MI_Band extends MD_Band). GeoAPI merges those "geological layers".
• Some additional interfaces or methods were introduced (see Why GeoAPI has some departures from ISO specifications?).

The changes applied by human intervention is documented in the departures page.