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.
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
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.Back to the top
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.Back to the top
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 can not 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.Back to the top
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
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
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:
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++
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
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 than 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:
unionare 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.
MD_CRSclass and its components classes" in order to avoid duplication. An automatic script would not have done this exclusion.
MI_Band extends MD_Band). GeoAPI merges those "geological layers".
The changes applied by human intervention is documented in the departures page.Back to the top