Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


The following work has been started:

  • User Manual generated from docbook and stored in our svn repository
  • User Guide simple reference pages gathering up code examples from geotools-user email list

The proposal is presented at the top. Below is the stream of discussion during development of the proposal.


The idea of this documentation project is to make a minimum amount of work for maintenance while giving users a solid start into the codebase. 

This proposal does demand of the project that it make a commitment to keeping the tutorials in functioning order by updating the tutorials when the Geotools library changes.


Okay so this page gathers together some ideas towards fixing the docs, it will not cover why they are broken. This is part of the geotools "growing up" process, and something we want to nail before graduation from the OSGEO inccubation process.



This section typically contains broad overview information. The Workbench User Guide provides two tutorials in this section, namely, Basic Tutorial and Team Tutorial. They mainly present high-level information to introduce the information in the rest of the guide.

  • Quickstart with Maven 2 Project
  • Quickstart with Eclipse


Just the facts, these serve to keep us for explaining what a Feature is badly on many different pages. This gives us
a single page to explain what a Feature is badly (smile) This is also where we would link to external resources like OGC
and ISO specifications.


Include a code example at the end. The
code example must be upto date, even if all it ends up being is a link to a file in the demo directory. If we can
inline the code example from svn we will do it.


  • We should target the top two uses for each "package"
  • so Construction and Reprojection for referencing.

  • inline the svn example
  • aim to document the 80% benifit, or just to cut down on email


This is mostly covered by javadocs - go team! This is where many of the articles will go to die, anything
worthwhile should be placed in the codebase in doc-files directories.