Geotk originates from several projects going back to 1995. Along the way, the GeoTools and Seagis projects joined forces to develop a Java library for geospatial applications. In 2009, Geotk has emerged as an independent fork of GeoTools.
GeoTools started in 1996 as a masters project at the University of Leeds. The main developers were James Macgill and Ian Turton. GeoTools 1 development was driven by the need to display on the web the results produced by the Geographical Analysis Machine. Later, the project undertook the creation of an online map of the village of Slaithwaite in an experiment on Public Participation GIS by the Geography department of the University of Leeds.
GeoTools was initially designed for use in Java applets. The library therefore restricted itself to the Java platform version 1.1 which ensured compatibility with the widely used (at that time) Microsoft JVM. Later, that version of GeoTools became known as "GeoTools 1" or "GeoTools-lite". The project was build as an application and was not built with OGC, ISO or other standards in mind.
Around the same time, in 1997, a similar effort started at Pêches et Océans Canada (MPO). The main developer was Martin Desruisseaux. This work continued in Java work which had originally started in 1995 using the C and C++ languages inspired by the code of André Gosselin at the MPO. The effort aimed to provide an online map of oceanographic data - consequently it had a scientific focus from the start. Like GeoTools 1, this work was built on the Java platform version 1.1 for use in applets, was built as an application, and was not built with any standards in mind.
On July 20, 2001 the Seagis project was created on SourceForge. A portion of the completed code just mentioned was pushed to the public sourceforge source code repository. That code included implementations of georeferencing services and grid coverage services as well as a stateful renderer. The Seagis development continued as a side-effect of Martin's Ph.D thesis at the Institut de Recherche pour le Développement (IRD). This work included a second refactoring of the Referencing module (the first refactoring haven taken place during the port from C/C++ to Java in 1997). This second refactoring aimed explicitly to comply with the newly published OpenGIS Coordinate Transformation Service Implementation Specification (OGC 01-009).
The Deegree project adopted Seagis as a library for their coordinate transformations. When Seagis development stopped in favour of GeoTools (see next section), Deegree choose to stay with the Seagis code rather than migrating to GeoTools then eventually, in 2008, the Deegree project started work on its own referencing module.
In 2002 the GeoTools team started a new generation of their code base. The new project, named GeoTools 2, followed a new design both to take advantage of the power of more recent Java platforms and to become compliant with the new suite of standards from the Open Geospatial Consortium (OGC). Early in the discussion phase of this project, Martin from the Seagis project joined in the planning for GeoTools 2. As a result of that discussion, the two projects decided to join forces on the GeoTools 2 effort by integrating the core of the Seagis code including the referencing and coverage services into the base of the new GeoTools library. The Seagis renderer was also initially ported but was abandoned soon due to lack of time and perceived complexity.
In the process of merging Seagis to GeoTools, the referencing module underwent its third refactoring bringing it into compliance with the ISO 19111 standard, which had superseded the earlier OGC 01-009 standard. Since that time (2003), the core referencing API has remained stable although the library internals have continued to change.
During this period, discussions also took place with the developers of OpenJUMP. That project eventually decided not to join in and work on the GeoTools library but did agree to help create a common API. Consequently James Macgill created the GeoAPI project on December 23, 2002. GeoAPI aims to define a common set of Java interfaces for geospatial applications which are as neutral as possible with regards to implementation, similar to the JDBC interfaces for SQL database access. The GeoAPI project attracted the interest of the Open Geospatial Consortium during the development of their GO-1 specification.
GeoTools 2 grew rapidly and attracted many developers, both individuals and organisations like Refractions Research and The Open Planning Project (TOPP). As time went on, the original GeoTools 1 developers became less active but the new developers grew more involved. The GeoServer team (from TOPP) became a major source of contributors, since GeoServer had chosen GeoTools as its base library.
To manage the rapidly growing project, GeoTools formed a Project Management Committee (PMC). As initially conceived, this PMC aimed mostly to organize human aspects of the project and thereby develop consensus on overall project direction and help resolve the inevitable issues which arise in such a project. The PMC explicitly left technical decisions to the maintainer of each module as was eventually documented in the GeoTools developer's guide.
Under the influence of its many contributors, GeoTools grew rapidly in size and functionality. The code repository changed from using the CVS versioning system to use the Subversion system, the build tool changed from Maven version 1 to Maven version 2. GeoAPI expanded to cover a greater number of ISO and OGC specifications and GeoTools implemented an increasing amount of that API. In several efforts, GeoTools attempted to move beyond its original Simple Feature model to allow for a more complex set of uses. A few attempts were made at building beyond the two dimensional Cartesian geometry library JTS and implement the ISO 19107 model. Support for many new data formats steadily emerged.
Meanwhile the free software community was giving rise to the Open Source Geospatial Foundation (OSGeo) which offered to provide an umbrella to open source code projects. The yearly conference Free and Open Source Software for Geography (FOSS4G) was also becoming increasingly popular and provided a venue where many developers could meet and interact. Eventually, GeoTools decided to join OSGeo.
Part of the growth of GeoTools raised new issues. The Subversion repository grew to be very large subsequent to various refactoring attempts and other changes. Because some developers needed to have their own workspace to attempt new experiments, the spike/ directory was created. Modules were created when a developer expressed interest and then subsequently abandonned. New participants were welcomed to the project and quickly given rights to commit to the code repository. This development let to a large code base of heterogeneous quality, with duplicate functionality, and with many unmaintained modules. In an effort to tackle these changes, a new category of modules was even created, the unsupported modules. It became difficult to build the full project, generate the javadocs and compile on more recent versions of the Java language.
The governance of GeoTools also evolved. The PMC expanded the Change Proposal process, which was initially started to ensure that changes to the maintainerless main module were well considered, to assert their right to control the evolution of all modules in the core library. Meanwhile the PMC also came to be dominated by developers working primarily on the GeoServer project so that decisions related to the GeoTools library were subsumed to the needs of the GeoServer project: GeoTools has not been transitioning to newer versions of the Java language as originally intended and GeoTools releases were being made when needed for a new version of GeoServer.
In response to the deteriorating quality of some GeoTools code base, Martin Desruisseaux embarked on a major cleanup effort. In July 2008, Martin created a new, initially empty, source code repository and proceeded to copy the GeoTools classes to this new repository one-by-one, cleaning and harmonizing them in the process. The project was codenamed "Geotidy" and intended to be offered as a new direction for the GeoTools project, probably starting the 3.x series of GeoTools. Martin intended to clean the whole base of the library for which he was maintainer and then start the discussion of how best to re-integrate his work with the main project. During this work, the referencing module underwent its fourth refactoring, improving the structure of the projection code and thereby the efficiency of certain transformation.
Geotidy was regularly discussed and always positioned as "what may become GeoTools 3 if accepted by the community". The main changes compared to GeoTools 2.5 were documented, and a migration tool has been created for automatizing the application of most common changes. Because Geotidy initiators were aware that not anyone will agree with every technical decision, the Geotidy code was hosted on a Distributed Versioning System (Mercurial) from the beginning, as opposed to the Central Versioning System (Subversion) used by GeoTools. By the end of March 2009, Martin had finished his cleanup work and began the discussion on the merge.
During this discussion, it immediately became clear that the PMC was going to require a formal proposal and demand a vote over each change in this cleanup effort. The proposal to experiment various clones of the code repository (a Distributed Versioning System paradigm) did not get momentum. Consequently Geotidy developers decided to go their own way.
On March 27, 2009, the Geotoolkit.org project was started as a formal fork of the GeoTools 2 project on the basis of the newly cleaned and homogenized code from the Geotidy effort. All the org.geotools packages in the Geotidy code base were renamed org.geotoolkit and the Geotoolkit.org web site and source code repository were created. The original Seagis stateful renderer was revived and built on the ported code, as was a new styling engine.
Geotk has adopted new tools. The newer version of the Java language, Java 6, was used as the base platform and the project aims to follow the evolution of the language according to the rules documented in the GeoTools developer's guide: "Our policy is waiting for a dot release before migrating to new version of the Java language." The Mercurial distributed source code versioning system was adopted to ensure that all programmers could experiment and develop new code unhampered by a centralized versioning system. It is expected that the system will mean that work is merged into the centralized repository only when it is ready since experiments can be developed and shared in peripheral code repositories. The system is also expected to allow greater independence for users of the library since they can maintain repositories with their own modifications. For example, it would be very easy to maintain a version of the library which runs on the older Java 5 runtime and base library.
It is expected that contributions will be heavily reviewed before being integrated into the library and that new contributors will need to spend time working with the library before being given leading roles in the project.