
\section{GeoTools Steering}
\label{sec:geotools}
\begin{small}This report is written in the first quarter of 2007, and outlines community development and research goals\end{small}
\newline
\emph{by Jody Garnett}

\subsection{Users Community}
\label{subsec:users_GN}
GeoTools has started up production of monthly milestone releases again. The publication of milestone releases makes progress visible and accessible to the user community. We have not been sending announcements out beyond the user list, as milestone releases are strictly for "early access".
\begin{itemize}
 \item \htmladdnormallink{2.4-M0}{http://docs.codehaus.org/display/GEOTOOLS/2.4-M0}
 \item \htmladdnormallink{2.4-M1}{http://docs.codehaus.org/display/GEOTOOLS/2.4-M1}
\end{itemize}
We have also updated our \htmladdnormallink{Module Matrix}{http://docs.codehaus.org/display/GEOTOOLS/Module+Matrix} page (and development policies) to reflect how well different modules are supported.


\subsection{Development}
\label{subsec:development_GN}
This time around we are balancing between several paid projects (with deadlines) and Martin's presentation to the GeoAPI working group (summer OGC meeting?).


%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.95]{dev_announce/geotools/tracks.png}
   %caption of the figure
   \caption{The above diagram is color coded based on project and developer activity (the amount of colour indicates the rate of change).}
   %label of the figure, which has to correspond to \ref{}:
   %\label{fig:label_of_your_image}
\end{figure}


\subsection{Development Policies}
\label{subsec:policies_GN}
Since 2006 Q4 the GeoTools project and GeoServer projects have made development policy changes:
\begin{itemize}
 \item \htmladdnormallink{GEOT:GeoTools change proposal}{http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal} - Changing an existing API
 \item \htmladdnormallink{GEOT:Supporting your module}{http://docs.codehaus.org/display/GEOT/Supporting+your+module} - Adding a new module to GeoTools
 \item \htmladdnormallink{GEOS:GSIP 6}{http://docs.codehaus.org/display/GEOS/GSIP+6+-+Track+GeoTools+Trunk} - Track GeoTools Trunk
\end{itemize}
The above policies aim to have a uDig and GeoServer branch available based on GeoTools trunk, without this support we are left with a development community scattered across different versions (all trying to be active).

There is one planned development policy change:
\begin{itemize}
\item When a contributor agreement is available (after negotiations with OSGeo) we will require each developer to sign something.
\end{itemize}

\subsection{Research Goals}
\label{subsec:research_GN}
There are several tracks of ongoing research, and a few unresolved design problems:

\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.95]{dev_announce/geotools/research.png}
\end{figure}

\subsection{Research Policies}
\label{subsec:policies_GN}
The GeoTools project and geoserver project made policy changes with respect to new research.
\begin{itemize}
\item \htmladdnormallink{GEOT:Creating your own Module}{http://docs.codehaus.org/display/GEOT/Creating+your+own+Module}
\end{itemize}
The establishment of an "unsupported" module space in GeoTools has succeeded in making visible research that was previously "out of sight out of mind". The uDig and GeoServer projects already and community sections meeting this need.

\subsection{Known Deadlines}
\label{deadlines_GN}
In the above diagram the following known deadlines are underlined.

Here are the dates as near as have been made public:
\begin{itemize}
\item GeoAPI Report for June 11th (May 11th code freeze)
    \begin{itemize}
    \item Report to be reviewed during \htmladdnormallink{July 9th Meeting}{http://www.opengeospatial.org/event/0707tc} working group meeting
    \item The report must be submitted for June 11th (ie one month before)
    \item Last time this report took a month to prepair so assume a code freeze on May 11th   \end{itemize}
\item GeoTools ISO Geometry implementation for Mid March
    \begin{itemize}
    \item Either jtsWrapper or geometry to be brought up to supported status
    \item Module may not be included in download until Java 5 is available                    \end{itemize}
\end{itemize}

The following are research goals only (no formal release required):
\begin{itemize}
\item GeoTools Feature / GeoServer Community schema for Mid March
    \begin{itemize}
    \item the implementation is being made available as an unsupported module, actual intergration happens later                                                                \end{itemize}
\end{itemize}

\subsection{Outstanding Problems}
\label{subsec:problems_GN}
The following problems are listed as design problems that should be addressed. Often these problems are holding up existing paid work, but due to the amount of collaboration involved lack specific funding.
\begin{itemize}
\item \textbf{GeoAPI TypeName} - We are caught between the ISO definition of GenericName (in which the Schema in which the name needs to be known prior to construction) and the need to have a quick "id" when looking up feature content. This is an example of a usibility tradeoff .. hard to resolve. The Java class QName is an example of a good compromise (based on the same ISO specification).
        \begin{itemize}
	\item GeoAPI TypeName interface has been defined in a manner similar to QName, this is in conflict with the interface for GenericName
	\end{itemize}
\item \textbf{GeoTools ConnectionPool} - GeoTools is starting to be used in more serious J2EE applications, as such we need to use a JNDI look up for our DataSource (Use of an oracle ConnectionPool is most often requested on the user list).
        \begin{itemize}
	\item We need to define an approach, document it, and roll it out into the database epsg authorty plugins and datastores.                                                 \end{itemize}

\item \textbf{GeoTools FilterCapabilities} - We have switch over to use GeoAPI Filter interfaces. The interface "Function" does not list the number of required parameters; instead that information is captured as part of the FilterCapabilities information (which we currently do not use).
        \begin{itemize}
	\item We need to split out the description of avaialble functions from the data structure used to define an expression.                                               \end{itemize}
\item \textbf{GeoServer Persistence} - The ability to persist GeoServers state (currently to an XML file) is hard to maintain, and not extensible.
        \begin{itemize}
	\item We have several sources of inspiration (using an XML to bean technology), some restrictions (allowing for programatic configuration) and some acceptence tests (ability to add additional configuration elements without changing the object model). \end{itemize}
\item \textbf{GeoServer Catalog} - A catalog is used to manage your resource connections, and allow for additional kinds of resources over time. The existing approach (cut \verb|&| paste) is not scaling well for GeoServer.
        \begin{itemize}
	\item We need to bring the GeoTools interfaces up to the level in which they are used by GeoServer and uDig. There are lots of negative examples (on what we don't want to do) and a few good ideas. GeoTools should strive for the minimum common ground.       \end{itemize}
\item \textbf{GeoServer J2EE} - GeoServer needs to become a better J2EE application
        \begin{itemize}
	\item Pay attention to DataSources retrived via JNDI lookup
        \item support external configuration and clustering                                   \end{itemize}

\item \textbf{uDig Rendering} - The uDig rendering system has seen enough real world use that we can start to simplify based on experience. Depending on where the line is drawn in the sand we may be able to add OpenGL to our list of targets (currently SWT and AWT are supported).
        \begin{itemize}
	\item While the work can be backported to GeoTools we need to ensure that there is a good reason (measured in developers) to make the effort worthwhile.                   \end{itemize}

\item \textbf{uDig Catalog} - The uDig catalog system has seen enough real world use that we can start to simplify based on experience.
        \begin{itemize}
	\item While the work can be backported to GeoTools we need to ensure that there is a good reason (measured in developers) to make the effort worthwhile.                   \end{itemize}

\end{itemize}


