GeoAPI is a standard from the Open Geospatial Consortium (OGC)
defining Java interfaces in the org.opengis namespace.
This namespace is used for Java module names and package names.
This name must be unique for making interoperability possible,
or for allowing projects coexistence in the same JVM.
Talks at OGC about standard Java interfaces
go as far as February 2000.
The first public release of Java interfaces in org.opengis packages was in the
OpenGIS Coordinate Transformation Service Implementation Specification
(OGC 01-009) standard, published in January 12th, 2001.
That specification was edited by Computer Aided Development Corporation (Cadcorp) Ltd.
The Java sources and
IDL files
(COM and
CORBA)
were attached to the specification in a ZIP file.
While the ZIP file is no longer available on the
OGC download page,
the Java source files are still mentioned in many sections of the specification:
§2 (overview),
§3.3 (object mutability),
§3.4 (error handling),
§6.3 (Java profile),
§12 (UML representation),
§13.3 (Java) and
§14.1 (guidelines for development of conformance test).
Section §6.3 starts with the following introduction:
The Java profile is specified in the attached Java source files.
Each Java package is called “org.opengis.xx”
where “xx” is the two-character package prefix in lower case.
Section §13.3 is as below:
As there are so many Java files (one for each interface as opposed to one for each package), the Java listings have not been included here. Please see the attached Java source files and JavaDoc HTML documentation.
At the time when OGC 01-009 was published,
OGC was named The OpenGIS® consortium
and its web site was hosted at http://www.opengis.org.
Consequently the use of org.opengis package name was a natural choice.
Still today, the Open Geospatial Consortium owns the opengis.org domain name
and OpenGIS is still a registered
OGC trademark.
The GeoAPI name however was not yet in use.
The Seagis project started to implement
the OGC 01-009 specification in
August 2001,
at first under its own package name for avoiding name conflicts,
later
as an implementation of interfaces published by OGC.
After ten months of development, Seagis code has been
donated to GeoTools 2
and became the GeoTools metadata, referencing and coverage core (excluding I/O) modules.
This donation brought to GeoTools its connection to org.opengis interfaces.
In September 2002, a joint presentation about Grid Coverages in Java was done at the OGC meeting in Noordwijk by Markus Müller (Degree, now lat/lon GmbH) and Martin Desruisseaux (IRD). It was followed by an informal discussion between above-cited speakers and James McGill (GeoTools), Stephane Fellah (PCI Geomatic), an UCAR reprensentative and an OGC representative (source: travel report to IRD). Following that discussion, James McGill launched in October 2002 a call for the creation of a geospatial API. The initial proposal attracted the interest of at least five open source projects. The project was created using a CVS repository on SourceForge (now migrated on GitHub). It was then that the project assumed the name “GeoAPI”. The first commit was in December 24, 2002, nearly two years after OGC 01-009 publication.
In 2003, the OGC
CRS working group started to
transition from OGC 01-009 to ISO-19111.
During the Orléan OGC meeting in April 2003,
an informal discussion happened between Markus Müller (Degree), Ian Turton (GeoTools),
Martin Daly (editor of OGC 01-009) and
Martin Desruisseaux (IRD).
It was agreed that the Java interfaces published by OGC 01-009
were not longer conform to latest UML diagrams
and that the creation of new Java interfaces will be mandated to the GeoAPI project
(source: travel report to IRD).
The first commit
of actual Java interfaces was two months later.
The org.opengis package name was used in agreement with the decision taken during above-cited ad-hoc meeting.
While the interfaces were at first generated automatically from
API defined in
XML, they were progressively replaced by
hand-written
interfaces using OGC 01-009 as a starting point.
Even if the UMLs were different,
the design approach of OGC 01-009 was still relevant.
The mapping between the old model and the new model, and how both of them map to Java interfaces,
is published in OGC 09-083r4 annex F.
Meanwhile, OGC issued a Request for Technology (RFT) on September 6th, 2002 (anticipated during the summer), slightly before open-source developers meet for the first time in above-cited OGC meetings. The RFT has been responded with the launch of GO-1 project in January 2003, with goals very similar to GeoAPI. James McGill made a call to work with open source projects in January 2004. A joint GO-1/GeoAPI meeting was hold at OGC in June 2004 and a GeoAPI charter has been drafted. The reported participants were:
GO-1 working group officially started in September 2004. The project joined its effort with GeoAPI, but kept the GO-1 name because it was the name used in the RFT before GeoAPI was launched. Version 1.0 of GO-1 was completed in December 2004, published in May 2005 and accompanied by a formal GeoAPI 2.0.0 release one month later.
There is traces of GO-1 and GeoAPI meetings in October 2003, April 2004, June 2004, September 2004, January 2005 and November 2005. Different organizations contributed to different parts of GeoAPI. Before mid-May 2009, the project had about 700 commits from IRD or Geomatys, about 400 commits from other GeoTools contributors, and about 150 commits from Polexis. The final GO-1 specification (now retired), published in 2005, lists 7 editors.
The GO-1 project was largely supported by the Polexis company. Its acquisition by Sys Technology in March 2004, and the change in priorities under the new owners, brought a halt to the GO-1 project, which in turn slowed development on GeoAPI. The GeoAPI working group has been dissolved in June 2006, but recreating the working group was proposed one year later and became effective in January 2009 as GeoAPI 3.0. This group took a narrower focus compared to GeoAPI 2.0, concentrating on the most stable interfaces, and putting the others — such as geometries — in a module entitled “pending”, for future consideration. GeoAPI 3.0 became an OGC standard in April 2011. This version was the first to be deployed in the Maven central repository. GeoAPI development continues since that time. From 2007 to 2022 they were more than 25 OGC meetings with presentations or motions related to GeoAPI.
The most fervent GeoAPI supporters among GeoTools core developers were the ones who brought Seagis to GeoTools.
They were the ones who attended most frequently to OGC meetings.
After those developers left the GeoTools project in May 2009, the GeoTools PMC decided to
fork GeoAPI 2.3-M1
(followed by a change
of file headers), but kept the org.opengis package name.
The decision to continue to use the OpenGIS® namespace for GeoTools's fork of GeoAPI has
created
conflicts with projects implementing the OGC GeoAPI 3.0 standard.
Some GeoTools users complained about this conflict,
but the GeoTools PMC replied — and
suggests
in their FAQ —
that GeoAPI was a GeoTools outreach project which donated their interfaces to OGC.
To put this claim in perspective, the figure below is a timeline with the events cited in above paragraphs.
Events related to GeoTools are in purple and italic characters.
Events in blue characters occurred at OGC or elsewhere.
Green circles are OGC meetings having some talks about GeoAPI
or GO-1.
If "GeoAPI" is understood as Java interfaces in the org.opengis package namespace,
or more generally as a common API
for independent geospatial projects, then
the GeoTools FAQ claim that GeoAPI started
with GeoTools founder's email is false.
The claim that GO-1 started after GeoAPI ignores the prior
OGC RFT.
The point saying that OGC GeoAPI working group has been dissolved omits to said that
the group has been formally recreated three years later, and that OGC meetings did not stopped.
The point saying that the OGC specification based on GeoAPI 2.0 has been retired
omits to said that it has been replaced by OGC GeoAPI 3.0 standard,
and that OGC has published formal GeoAPI releases on Maven Central.
GeoTools rewrote a more honest FAQ in March 2023 and announced in April (during OGC/OSGeo/ASF code sprint) that work for resolving the package name collision would start in August. Those resolutions happened after the issue has been escalated to the OSGeo board with OGC in copy. GeoTools initially asked to be paid by (among others) the Apache Software Foundation (ASF) for doing this work since Apache projects are impacted, but it has been reminded that OpenGIS® is protected by trademark laws (source: OSGeo board private email archive, 2023/03/16). If OGC decides to ask GeoTools to stop using that name, then this is not optional and the budget question is not OGC or ASF problem. No formal decision was taken by OGC before GeoTools made their announcement, but talks were in progress.
During the 10 years before those events, all demands for conflict resolution were either ignored using the formally biased GeoTools FAQ as a justification, or blocked with requests for payment from a GeoTools member. It took OGC and OSGeo involvement for having progress. The argument that GeoTools should assume the responsibility for this work because they are the ones who forked, has been criticized by a GeoTools member as not being the way that open source collaboration works (source: OSGeo board private email archive, 2023/03/17).
Different strategies with different effort/disruption tradeoffs
were
proposed during the OSGeo/OGC/ASF code sprint.
Disruption for GeoTools users could have been minimized by complying to the
OGC standard for the metadata and referencing parts,
since the changes between GeoTools fork and GeoAPI 3.0
were documented for ten years. But GeoTools decided to cut all links to org.opengis,
followed by an opportunistic refactoring of their API.
GeoTools 30 was released in October 15, 2023.
That release contains a renaming of org.opengis packages to org.geotools.api, which resolves the conflict.
The release announcement
said that although this was setup as an joint-initiative to be addressed with other organizations
(notably OGC responsible for GeoAPI,
and ASF making the request),
only OSGeo was forthcoming with funding
,
without mentioning why OGC and ASF refused to pay:
GeoTools wanted OGC and ASF to pay for GeoTools opportunistic refactoring,
a task much larger than resolving the conflict (see above).
Furthermore, the release announcement contains a link to a call for sponsors titled
OpenGIS Harmonization which is still claiming that
GeoTools, OpenJUMP and deegree setup
.
This is false, as demonstrated above by evidence of prior work.
The page also claims that
org.opengis interfacesthe activity was later abandoned (…snip…),
leaving GeoTools to adopt these interfaces as the
,
which is also false: the GeoAPI 3 Standard Working Group was active
when GeoTools forked GeoAPI (see the timeline figure).
The page also claims that
gt-opengis moduleMany, many years later the OGC GeoAPI Implementation Specification was resumed,
and now requires exclusive use of the
.
This is false again: the GeoAPI 3.0.0 specification was published
6 months after GeoTools forked GeoAPI 2.3-M1 (see the timeline figure),
and OGC never authorized GeoTools to use the OpenGIS® name for work done
outside the OGC working groups.
org.opengis Java package
The GeoTools fork of GeoAPI was an hostile fork. The reasons for this hostility from
some PMC members is a story that could be the topic of another page.
GeoTools communication about GeoAPI in the last 10 years resorted to
omissions of any historical facts at their disadvantage
(in their former FAQ) or to falsehoods (in their call for sponsors)
for giving the impression that their use of the org.opengis package name was legitimate.
Those omissions and falsehoods were not mistakes caused by lack of attention,
as the PMC knew that a GeoAPI 3.0 standard was published.
It was reminded to them in 2015 by the user's complain mentioned above,
and the GeoTools representative confirmed that he has read an earlier version of this page
before the call for sponsors was written
(source: OSGeo board private email archive, March 2023).
GeoAPI 3.0 had two minor releases for following the evolution of Java environment:
As of February 2022, OGC GeoAPI 3.0.2 is implemented by Apache SIS, implemented by OSGeo PROJ-JNI, and used by the Geospatial Integrity of Geoscience Software (GIGS) tests. Work for 3.1 or 4.0 release is in progress. A specification draft is publicly available. GeoAPI is among the most popular repositories of OGC GitHub.
Several packages defined in GeoAPI 2.0 have been temporarily retired from GeoAPI 3.0 releases. The geometry package has been retired because two Ph.D. students tried independently to implement it with limited success, which suggests that the model needs revision (confirmed with new model in ISO 19107 revision). The coverage package has been retired because the model needs clarification (confirmed with new Coverage Implementation Schema part in ISO 19123 revision). The feature, filter and style packages have been retired because they were derived from XML schemas, which led to poor result for a programmatic API. The feature and filter packages are proposed for reintroduction in GeoAPI 3.1 with a new API derived from OGC/ISO abstract models (UML). Other temporarily retired packages will follow later.