\section{La direction de GeoTools}
\label{sec:geotools}
\begin{small}Cet article a été rédigé pendant le premier trimestre 2007 
et donne un aperçu du développement de la communauté et des objectifs 
de recherche\end{small}
\newline
\emph{par Jody Garnett, traduit par Sidonie Christophe}

\subsection{Communauté d'utilisateurs}
\label{subsec:users_GN}
GeoTools a de nouveau relancé la production mensuelle de versions 
majeures. La publication de ces versions régulières temporelles aide à la 
visibilité des progrès et à l'accessibilité à la communauté d'utilisateurs. 
Nous n'avons pas fait état de ceci, hormis dans la liste 
d'utilisateurs, car ces versions sont strictement réservées à un "accès anticipé".
\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}
Nous avons aussi mis à jour notre page Web \htmladdnormallink{Module 
Matrix}{http://docs.codehaus.org/display/GEOTOOLS/Module+Matrix} (ainsi 
que celle de nos politiques de développement) afin de mettre en évidence 
les différences de gestion des modules.

\subsection{Développement}
\label{subsec:development_GN}
En ce moment nous travaillons à la fois sur plusieurs projets payés 
(avec des dates limite) et sur la présentation de Martin au groupe de 
travail sur la GeoAPI (rencontre OGC de cet été?).

%\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{Le code couleur du diagramme ci-dessus est basé à la fois 
sur le projet concerné et l'activité de développement (l'intensité de la 
couleur indique le taux d'activité).}
   %label of the figure, which has to correspond to \ref{}:
   %\label{fig:label_of_your_image}
\end{figure}


\subsection{Axes de développement}
\label{subsec:policies_GN}
Depuis le dernier trimestre 2006, les axes de développement des projets 
GeoTools et GeoServer ont été modifiés:
\begin{itemize}
 \item \htmladdnormallink{GEOT:Proposition de modification 
GeoTools}{http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal} - 
Modifier l'API existante
 \item \htmladdnormallink{GEOT:Gérer votre 
module}{http://docs.codehaus.org/display/GEOT/Supporting+your+module} - Ajouter 
un nouveau module à GeoTools
 \item \htmladdnormallink{GEOS:GSIP 
6}{http://docs.codehaus.org/display/GEOS/GSIP+6+-+Track+GeoTools+Trunk} - 
Suivez le tronc commun GeoTools
\end{itemize}
L'objectif des axes ci-dessus est d'obtenir une ramification uDig et 
GeoServer disponible, basée sur la version tronc commun GeoTools, sans 
laquelle nous ne sommes qu'une communauté de développement dispersée sur 
différentes versions (tendant certes toutes à être actives)..

La modification d'un axe de développement a été planifiée:
\begin{itemize}
\item Quand l'accord d'un contributeur est disponible (après 
négociations avec l'Osgeo), nous demanderons à chaque développeur de signer 
quelque chose.
\end{itemize}

\subsection{Objectifs de recherche}
\label{subsec:research_GN}
Il y a plusieurs pistes pour la recherche en cours, et quelques 
problèmes de conception non résolus.

\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{Etapes de recherche}
\label{subsec:policies_GN}
Les projets GeoTools et GeoServer apportent quelques modifications de 
principe, en accord avec la recherche en cours.
\begin{itemize}
\item \htmladdnormallink{GEOT:Créer votre propre 
module}{http://docs.codehaus.org/display/GEOT/Creating+your+own+Module}
\end{itemize}
L'introduction d'un espace pour modules "non supporté" dans GeoTools 
est parvenu à rendre visible des recherches qui étaient jusque là "hors 
de vue, hors de pensée". Les projets  uDig et GeoServer ont déjà des 
sections communautaires remplissant ces besoins.

\subsection{Dates limite connues}
\label{deadlines_GN}
Dans le diagramme ci-dessus, les dates limite connues sont soulignées.

Voici les dates qui ont tentativement été rendues publiques:
\begin{itemize}
\item Article GeoAPI pour le 11 Juin (code bloqué le 11 Mai)
    \begin{itemize}
    \item Relecture de l'article pendant les 
\htmladdnormallink{Rencontres du 9 Juillet}{http://www.opengeospatial.org/event/0707tc} du groupe 
de travail
    \item L'article doit être soumis le 11 Juin, dernier délai (cad un 
mois avant).
    \item La dernière fois cet article a mis un mois à être finalisé, 
donc le code est bloqué le 11 Mai pour les besoins de l'article.  
\end{itemize}
    \item Implémentation de GeoTools ISO Geometry pour mi-Mars.
    \begin{itemize}
    \item Soit jtsWrapper ou Geometry doivent être amenés en finition 
où le soutien peut être pourvut.
    \item Le module ne sera peut-être pas inclus dans le téléchargement 
tant que Java 5 n'est pas disponible.\end{itemize}

\end{itemize}

Le paragraphe suivant présente les objectifs de recherche uniquement 
(pas de version officielle requise):
\begin{itemize}
\item GeoTools Feature / schéma de la communauté GeoServer pour mi-Mars
    \begin{itemize}
    \item l'implémentation sera disponible en tant que module non 
supporté, l'intégration se fera plus tard.                                                                
\end{itemize}
\end{itemize}

\subsection{Problèmes restants}
\label{subsec:problems_GN}
Les problèmes suivants sont listés comme des problèmes de conception 
auxquels il faut s'attaquer. Ces problèmes arrêtent souvent les travaux 
payés, mais par l'importance de la collaboration nécessaire se 
retrouvent sans financement spécifiques.

\begin{itemize}
\item \textbf{GeoAPI TypeName} - Nous sommes coincés entre la 
définition ISO de GenericName (entre autres le Schéma dont les noms doivent être 
connus 
avant construction) et la nécessité d'avoir un "identifiant" rapide quand 
on recherche le contenu d'une entité. C'est un exemple de combinations 
de choix pour la facilité d'utilisation .. difficile à résoudre. La 
classe Java QName est un exemple d'un bon compromis (basé sur la même 
spécification ISO).
        \begin{itemize}
	\item L'interface GeoAPI TypeName a été définie en suivant le format 
QName, entrant en conflit avec l'interface pour GenericName
	\end{itemize}
\item \textbf{GeoTools ConnectionPool} - GeoTools commence à être 
utilisé dans des applications J2EE plus importantes, et ainsi, nous devons 
utiliser une recherche type JNDI pour nos DataSource (l'utilisation 
d'une ConnectionPool Oracle est la plus souvent demandée sur la liste 
utilisateur).
        \begin{itemize}
	\item Nous avons besoin de définir une approche, de la documenter et 
de l'étendre aux datastores et aux plugins d'autorité des bases de données 
epsg.\end{itemize}
\item \textbf{GeoTools FilterCapabilities} - Nous utilisons maintenant 
les interfaces filtres GeoAPI. L'interface "Function" ne fournit pas le 
nombre de paramètres requis; l'information est récupérée comme une 
partie de l'information FilterCapabilities (que nous n'utilisons pas 
couramment).
        \begin{itemize}
	\item Nous devons séparer la description des fonctions disponibles de 
la structure des données utilisée pour définir une expression. 
\end{itemize}
\item \textbf{GeoServer Persistence} - La capacité de persistance de 
l'état de GeoServer (dans un fichier XML) est difficile à maintenir et 
non extensible.
	\begin{itemize}
	\item Nous avons plusieurs sources d'inspiration (utilisation de XML 
pour les technologies bean), quelques restrictions (permettant de la 
configuration programmatique) et quelques tests d'acceptation (aptitude à 
ajouter des éléments de configuration additionnels sans changer le 
modèle objet). \end{itemize}
\item \textbf{GeoServer Catalog} - Un catalogue est utilisé pour gérer 
les connexions aux ressources, et permet des ajouts d'autres types de 
ressources dans le temps. L'approche existante (couper \verb|&| coller) 
n'est pas bien adaptée à l'échelle de travail de GeoServer.
        \begin{itemize}
	\item Nous devons ramener les interfaces GeoTools au même niveau que 
celles utilisées dans GeoServer et uDig. Il existe beaucoup d'exemples 
négatifs (sur ce que nous ne voulons pas faire) et quelques bonnes 
idées. GeoTools doit s'évertuer à construire un terrain minimum 
commun.\end{itemize}
\item \textbf{GeoServer J2EE} - GeoServer doit devenir une meilleure 
aplication J2EE.
        \begin{itemize}
	\item Faites attention aux DataSources renvoyées via une recherche 
JNDI
	\item Configuration du support externe et clustering                        
\end{itemize}
\item \textbf{uDig Rendering} - Le système de rendu de uDig ayant été 
suffisamment utilisé en conditions réelles, nous pouvons commencer à le 
simplifier de façon expérimentale. Selon les limites que l'on se pose, 
nous sommes capables d'ajouter de l'OpenGL à notre liste de cibles (SWT 
et AWT sont supportés à présent).
        \begin{itemize}
	\item Même si le travail pourrait être rétribué dans GeoTools, nous 
devons nous assurer qu'il y a une bonne raison (mesurée en développeurs) 
de rendre cet effort valable.   \end{itemize}
\item \textbf{uDig Catalog} - Le système de catalogue de uDig ayant été 
suffisamment utilisé en condition réelles, nous pouvons commencer à le 
simplifier de façon expérimentale.
        \begin{itemize}
	\item Même si le travail pourrait être rétribué dans GeoTools, nous 
devons nous assurer qu'il y a une bonne raison (mesurée en développeurs) 
de rendre cet effort valable. \end{itemize}

\end{itemize}