This is the current development branch with an initial focus on documentation.
This release made a number of improvements to usability; with the introduction of SimpleFeatureCollection to avoid the large
number of Java generics used in the new feature model. This release also folds the org.opengis interfaces back into the project marking the end of our formal involvement with GeoAPI.
Work started initially to work on style interfaces (in collaboration with GeoAPI). This work stalled out due to developers working with distributed version control; and losing their mandate to work with the community.
The change away from an research and development project continues; with the unsupported module and change proposal procedure taking complete responsibility for project communication. This removed the need for weekely IRC meetings (a real cultural shift) and lead to some staffing changes as one of the founders from the SEAGIS project dropped away returning to a research and development agenda.
The GeoTools 2.5.x release was a very long time in coming - featuring a new feature model produced in collaboration with the GeoAPI project. This introduced the concept of a rich feature model; finally offering the ability to represent more interesting content the simple flat features. While none of the datastores in this initial release make use of the full power of this model; it represents the first chance for the "complex features" branch started in GeoTools 2.2.x four years previously) to start to come home.
The release was branched just prior to work on style interfaces in order to stay focused on a single change at a time.
During this time period GeoTools graduated as an OSGeo project! As part of meeting the requirements for this process the GeoTools User Guide was created.
During this time period we introduced the concept of an "unsupported" module in a bid to both attract new developers with an easy way to get involved that promoted the feeling of belonging to a larger library and responsibility for a section of code. This also offered a way to hold onto work that did not have a module maintainer and would otherwise be dropped.
This represents the last gasp of the original GeoTools Feature model (research started on this one back in GeoTools 2.2.x). This is one of the best releases of GeoTools ever; benefiting from performance tuning and years of effort.
This release marks the integration point of imageio-ext offering access to OGR geometry formats.
In the interest of maintaining traceability of API changes we started introducing the change request procedure; this marks an important turning point of the project acting like a stable library rather than just a research and development curiosity.
The GeoTools team was able to meet in person for the first time at FOSS4G 2006 (See Birthday Coders) marking the 10 year anniversary of the project).
The GeoTools 2.3 project was the first attempt to transition to a new GeoAPI interface. The geoapi filter interfaces were produced with a couple key differences from the GeoTools one. They were not mutable. This transition was smooth from a user perspective; they could now produce expressions using a much easier to use filter factory resulting in easier to understand code. Many of the intended benifits were not realized as the mutable implementations were still used under the covers; which did not force the internal implementation of the datastores to make the transition.
The production of GeoAPI Geometry implementations was completed under contract by Refractions Research during this time period; this work was an implementation only and was not intergrated into the rest of the library. It offers a fork of JTS 1.7 onto GeoAPI Geometry abstractions (ie ISO 19107); this code is easier to follow then the jts-wrapper implementation which was also donated to the library during the 2.3.x timeframe.
GeoTools joined the OSGeo foundation during this time period as one of the initial projects in incubation. Graduation from this process took a long time as we needed to hunt down and assign copywrite to the foundation for each of the files. Our practice of marking each file as (c) GeoTools PMC did not quite work as the PMC was not a legal entity! This work was completed for GeoTools 2.5.x some three years later.
This is the oldest version of GeoTools still in use; it is used by the uDig 1.1.x stable series and still has a release scheduled! This is a very successful version of GeoTools; and the first produced with an interactive application in mind.
On a research and development front the aim of Geotools 2.2 was to support the GeoAPI Geometry model and the idea of a GeoAPI Feature Model was being considered. These ideas did not land until much later in the GeoTools 2.5 stream; showing that good development takes time and dedication.
For more information please see the Road Map to 2.1 and Nightly Builds
This release of GeoTools marks the start of an out reach project in the form of GeoAPI . The GeoTools community has had a long standing commitment to cooperation with other projects involved in Java GIS Development. The GeoAPI project marks an oppertunity to collaborate with the broader Java GIS community, and the OGC standards body. The idea is to create java interfaces capturing the information contained in the standards so they can be implemented by multiple projects to facilitate collaboration.
This release provided some new Directions in development:
Some Research and Development ideas that were experimented that did not pan out:
The original GeoTools 1.0 codebase was the work of only two main developers - James Macgill and Ian Turton of Leeds University. As the project grew in complexity and in popularity it became clear that further development was becoming unsustainable: partly because so few people were involved in the design process and partly because the code had evolved rather randomly. It was time for a clean start with a better design and a larger development community.
The second generation of GeoTools has been fundamentally redesigned to take advantage of the full power of the Java platform. GeoTools is contributed to by an international group of developers and is run in as decentralized a manner as possible. Because of this, GeoTools strives to cooperate with other efforts, to modularize the decision making process, and to foster an open community.
In 2002, code from the SEAGIS project was merged into the geotools 2.0 project, providing coordinate transformation services, grid coverage and rendering implementations.
The overall maintenance and future directions of GeoTools 2 is managed by the GeoTools 2 Project Management Committee (PMC). Currently this comprises 8 active developers who take joint responsibility for design and implementation decisions. The team welcomes and encourages others to become contributors and ultimately become part of the GeoTools 2 development team.
It is a long term goal of the GeoTools 2 project to refine its core API and promote its use so that it can become a recognized and standard API for Java GeoSpatial development.
no source code
Work began on the GeoTools library in 1996 at the University of Leeds as part of a masters project to viusalize the results produced by the Geographical Analysis Machine (GAM) over the web. Not long after the first simple map display was up and running a seperate project within the Geography department at Leeds, which was looking at ways to develop and research Public Paricipation GIS (PPGIS), used the library to create an online map of the village of slaithwaite to allow the locals to discuss their thoughts about various planning issues.
The library was developed rapidly in response to the needs of this second project and the resulting toolkit, which was targeted at the Java Applet API, still exists as GeoTools-Lite . GeoTools 1 was not built with OpenGIS standards in mind (or any standards for that matter).
GeoTools 1 aimed to provide a toolkit of resources to enable the creation of interactive geographic visualization clients. GeoTools 1 was built using the Java 1.1 environment so as to enable the execution of applets on as wide a range of clients as possible without the need for a plug in. It was developed in a rather ad-hoc manner, with new features being added as and when needed.
GeoTools 1 is not being actively extended by its original development team though it would be excelent if users want to help move it from its current state (version 0.8) to a stable 1.0 release.