\title{Google Summer of Code}
\subtitle{Participation de l'OSGeo au Google Summer of Code de 2007}
\maketitle

\begin{description}
	\item [P\'eriode couverte par le rapport :] May-Aug 2007 
	\item  [Nom du contact :] Wolf Bergenheim
	\item  [Traducteur :] Yves Jacolin
\end{description}
L'\'et\'e dernier, du 1er mai au 31 ao\^ut 2007, l'OSGeo a particip\'e au Google Summer of Code. Cet article r\'esume cette exp\'erience et donne une courte pr\'esentation de chaque projet du Summer of Code.

\section*{ Qu'est ce que le SoC ? }

\textit{Citation de la \href{http://code.google.com/support/bin/answer.py?answer=60266&topic=10726}{FAQ de Google :}}
\begin{quote}
Google Summer of Code est un programme qui offre aux \'etudiants une bourse pour \'ecrire du code pour divers projets open source. Google travaillera avec plusieurs groupes de logiciels libres, open source, et techniques pour identifier et financer divers projets sur une p\'eriode de trois mois. Historiquement, le programme a r\'euni plus de 1 000 \'etudiants avec plus de 100 projets open source, pour cr\'eer des centaines de milliers de lignes de code. Le programme, qui a d\'emarr\'e en 2005, est maintenant dans sa troisi\`eme ann\'ee, faisant suite au succ\`es de 2006.
\end{quote}

\begin{quote}
Bien que la majorit\'e des \'etudiants participant dans le pass\'e \'etaient inscrits dans des universit\'es d'informatique et de programmation, les GSoCeurs sont issus d'une grande vari\'et\'e de formations, allant de la bio-informatique aux sciences de l'exploitation mini\`ere.  Beaucoup de nos participants pass\'e n'avaient jamais particip\'e \`a un projet open source avant GSoC ; d'autres ont utilis\'e la bourse de GSoC comme une opportunit\'e pour se concentrer enti\`erement sur leur activit\'e de d\'eveloppement open source durant l'\'et\'e. Plusieurs de nos \'etudiants de 2005 sont devenus des parrains en 2006.
\end{quote}

\section*{ Quels projets ont particip\'e ? }
D'abord, je voudrais f\'eliciter les \'etudiants pour le s\'erieux de leur travail. Beaucoup de projets utiles et int\'eressants ont \'et\'e termin\'es lors du SoC 2007. Nous avons perdu un \'etudiant ou deux, qui ont eu d'autres priorit\'es. Mais le succ\`es d'ensemble des projets est quelques chose dont nous devons \^etre fiers. Bon travail ! Esp\'erons que le SoC de 2008 sera au moins aussi bon.

\noindent Maintenant pr\'esentons les projets de l'\'et\'e 2007 :

\subsection*{ GDAL }
\subsubsection{ GDAL2Tiles }


 \textbf{\'Etudiant} : Klokan Petr Pridal\\
  \textbf{Parrain} : Howard Butler 

Ce projet a pour objectif de faciliter la publication de cartes raster sur Internet. Les cartes raster (comme le TIFF / GeoTIFF, MrSID, ECW, JPEG2000, JPEG, PNG) sont converties en une structure de r\'epertoires contenant de petites tuiles PNG (compatible avec TMS), qui peut \^etre copi\'ee sur un serveur Web. Des pages Web simples avec des visualiseurs bas\'es sur Google Maps et OpenLayers sont \'egalement g\'en\'er\'es ainsi. 

Cet outil permet m\^eme la publication de grandes cartes sans avoir \`a installer ou \`a configurer un logiciel sp\'ecial (comme MapServer) et la carte s'affiche tr\`es rapidement dans le navigateur Web. GDAL2Tiles g\'en\`ere \'egalement des m\'etadonn\'ees n\'ecessaires pour Google Earth (KML SuperOverlay), si la carte fournie utilise une projection EPSG:4326. La commande gdalwarp peut \^etre utilis\'ee pour convertir les cartes raster dans une autre projection. Le g\'eor\'ef\'erencement interne ou pr\'esent dans des World files est utilis\'e au cours de la g\'en\'eration des tuiles et des fichiers KML, mais un bon g\'eor\'ef\'erencement n'est pas obligatoire.

La structure des tuiles suit la recommendation des sp\'ecifications du Tile Map Service de l'OSGeo\footnote{Tile Map Service : \url{http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification}}

Le manuel de l'outil fait partie de la solution, ainsi que le document d\'ecrivant plusieurs structures de tuiles existante avec des liens pour de la documentation suppl\'ementaire. L'analyse des KML SuperOverlay avec rotation est r\'ealis\'ee \'egalement.

Pour plus d'information regardez la \href{http://www.klokan.cz/projects/gdal2tiles/}{page du projet}

Ce projet a \'et\'e accept\'e par la communaut\'e GDAL comme ticket \href{http://trac.osgeo.org/gdal/ticket/1763}{\#1763}. Cette commande a \'et\'e distribu\'ee avec la nouvelle version 1.5.0 stable de GDAL.

\subsubsection{ Gestion en lecture du KML pour le pilote existant}

 \textbf{\'Etudiant :} Mateusz Loskot \\ \textbf{Parrain :} Jens Oberender 

Ce projet a ajout\'e la gestion en lecture du KML vecteur.

Pour plus d'information lisez la \href{http://trac.osgeo.org/gdal/wiki/SoCKMLRead}{page wiki}

Ce projet a \'et\'e inclu dans la nouvelle version 1.5.0 d'OGR.

\subsubsection{ Pilote GDAL pour les  Web Map Services }

 \textbf{\'Etudiant :} Adam Nowacki \\ \textbf{Parrain :} Daniel Morissette 

D\'eveloppement d'un pilote GDAL de Service WMS de l'OGC, avec gestion des Web Map service suivant :
\begin{itemize}
	\item  OGC WMS et WMS-C cache 
	\item  WorldWind TileService 
\end{itemize}

Le nouveau pilote a \'et\'e inclu dans le code officiel de GDAL ainsi que dans la version 1.5.0. \href{http://www.gdal.org/frmt_wms.html}{La documentation du pilote est disponible} et la \href{http://trac.osgeo.org/gdal/wiki/SoCWMSDriver}{page wiki} a plus d'information.

Ce projet a \'et\'e inclu dans la nouvelle version 1.5.0 d'OGR.

\subsection*{ GRASS }
\subsubsection{ v.generalize }

 \textbf{\'Etudiant :} Daniel Bundala \\ \textbf{Parrain :} Wolf Bergenheim 

v.generalize est un projet qui r\'ealise une simplification de ligne telle que d\'ecrite par McMaster. L'objectif originel \'etait d'impl\'ementer celle de Douglas-Peucker et quelques algorithmes de simplification. Daniel Bundala (l'\'etudiant) a surpris son parrain par son travail tr\`es efficace et, par cons\'equent, GRASS 6.3 comprend d\'esormais un tout nouveau module de g\'en\'eralisation qui est capable non seulement de simplification, mais aussi de lissage et de d\'eplacement. Il y a aussi une m\'ethode de simplification du r\'eseau dans le module.

Pour plus d'information lisez la \href{http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html}{documentation du module}

v.generalize est inclu dans la nouvelle version 6.3.0 de GRASS (en tant que RC4).

Le module a \'egalement \'et\'e utilis\'e pour acc\'el\'erer d'une mani\`ere substantiel la vitesse et la qualit\'e de l'interpolation des contours de donn\'ees \href{http://skagit.meas.ncsu.edu/~helena/grasswork/interpgen.html}{lors du traitement des mod\`eles de calcul num\'erique}.

\subsubsection{ v.net.visibility }

 \textbf{\'Etudiant :} Maximilian Maldacker \\ \textbf{Parrain :} Wolf Bergenheim 

v.net.visibility construit un r\'eseau de visibilit\'e autour de certains obstacles. Le r\'eseau cr\'e\'e peut ensuite \^etre analys\'e avec les modules v.net.*. Il peut aussi \^etre fusionn\'e avec un r\'eseau existant, comme un r\'eseau routier, et cela permet de tracer les plus courts chemins au-del\`a d'un r\'eseau routier existant, par exemple pour les v\'ehicules d'urgence.

Pour plus d'information lisez la \href{http://grass.osgeo.org/grass63/manuals/html63_user/v.net.visibility.html}{documentation du module}

v.net.visibility est inclu dans la nouvelle version 6.3.0 de GRASS (en tant que RC4).

\subsection*{ uDig }
\subsubsection{ Donn\'ees en cache }


 \textbf{\'Etudiant :} Christophe Rousson \\ \textbf{Parrain :} Ian Turton 

Une fonctionnalit\'e de cache. Un cache en RAM peut utiliser l'algorithme de la LRU et maximiser la configuration de m\'emoire vive allou\'ee. Un cache en disque local peut utiliser un algorithme bas\'e sur la limite de la taille et / ou de l'\^age maximale. Id\'ealement, lorsque les listes d\'epassent la RAM, ils seront \'ecrits sur le disque. \`A la fermeture de la session, la liste restante en RAM sera \'egalement \'ecrite sur le disque (comme Google Earth). Au d\'emarrage, le cache peut \^etre sond\'e pour voir si quelque chose existe d\'ej\`a au sein de l'\'etendue spatiale (si elle n'a pas expir\'e).

Pour plus d'information lisez la \href{http://docs.codehaus.org/display/GEOTOOLS/SoC+2007+Caching}{page wiki des donn\'ees}.

Ce projet est dans la version trunk/d\'eveloppement de uDig.

\subsubsection{ Algorithmes de transformation }

 \textbf{\'Etudiant :} Jan Jezek \\ \textbf{Parrain :}  Jesse Eichar 

Le module de r\'ef\'erencement de GeoTools est devenu l'un des outils les plus puissants pour la transformation de syst\`eme de coordonn\'ees en JAVA dans le monde du SIG au cours des derni\`eres ann\'ees. Le module de r\'ef\'erencement en liaison avec le module de couverture repr\'esente un outil tr\`es puissant pour les op\'erations raster comme la re-projection et la transformation. L'une des op\'erations souvent n\'ecessaire dans les SIG est l'adaptation de raster comme les scans de cartes ou d'images de t\'el\'ed\'etection qui ont un syst\`eme de coordonn\'ees de r\'ef\'erence inconnu dans le syst\`eme de coordonn\'ees de r\'ef\'erence du monde r\'eel. Dans GeoTools il ya d\'ej\`a quelques possibilit\'es de le faire. L'objectif de ce projet est d'ajouter d'autres algorithmes \`a cet effet et ensuite de faire une interface graphique simple pour uDig pour appliquer ces nouvelles fonctions.

Ces nouveaux algorithmes sont :
\begin{itemize}
	\item  Nouvelles m\'ethodes bas\'ees sur des interpolations : pond\'eration par l'inverse de la distance et interpolation bilin\'eaire. 
	\item  M\'ethode de spline de type plaque mince (thin plate spline). 
	\item  Transformation par morceaux plus g\'en\'erale. 
\end{itemize}

Pour plus d'information lisez la \href{http://docs.codehaus.org/display/GEOTOOLS/New+Transformation+Algorithms+for+GeoTools+and+uDig}{page wiki}

Ce projet est dans la version trunk/d\'eveloppement de uDig.

\subsubsection{ Interactive GeoRSS Tool }

 \textbf{\'Etudiant :} Rui Li \\ \textbf{Parrain :} Richard Gould 

Un de buts de uDig est de satisfaire les utilisateurs en leur fournissant suffisamment d'informations pour leurs besoins sp\'ecifiques. Dans bien des cas, par exemple, un voyageur aimerait conna\^itre les lieux d'int\'er\^et proches de son h\^otel ou un \'etudiant voudrait trouver un appartement situ\'e \`a une distance de marche raisonnable de son \'ecole. La m\'ethode traditionnellement utilis\'ee consiste \`a rechercher les lieux dont le type int\'eresse l'utilisateur puis \`a laisser se dernier juger si leurs distances conviennent. Ce projet fusionne ces deux \'etapes. 

Pour plus d'information lisez le \href{http://code.google.com/soc/2007/osgeo/appinfo.html?csaid=CB1B7287EFAF39DA}{r\'esum\'e du Google Summer of Code}.

\subsection*{ Geoserver }
\subsubsection{ JTileCache }


 \textbf{\'Etudiant :} Chris Whitney \\ \textbf{Parrain :} Justin Deoliveira

Impl\'ementation d'un serveur WMS-C (similaire \`a TileCache de MetaCarta) en tant que servlet Java, incluant des biblioth\`eques de gestion de cache existantes afin de g\'erer la m\'emoire, le disque, et le cache distribu\'e. L'Open Planning Project (TOPP) poursuit le d\'eveloppement de ce projet. En particulier, Arne Kepp a contribu\'e \`a d'importantes nouvelles fonctionnalit\'es et corrections de bogues, y compris la publication de la version 0.5 sous un nom plus appropri\'e, GeoWebCache. Le projet est actuellement localis\'e \`a \url{http://geowebcache.org}. Le site de \href{http://sigma.openplans.org/}{d\'emonstration} de GeoServer a d\'esormais recours \`a GeoWebCache pour publier les tuiles issues du service WMS.

\subsubsection{ \'Editeur de style }

 \textbf{\'Etudiant :} Anthony Manfredi \\ \textbf{Parrain :} Andrea Aime

Pour concevoir et mettre en œuvre un \'editeur de fichiers SLD \`a l'aide de JavaScript.
\begin{itemize}
	\item  Standalone - l'\'editeur n'est pas li\'e \`a un programme particulier (uDig, MapBuilder, GeoServer) 
	\item  Visuel - les utilisateurs peuvent pr\'evisualiser les r\'esultats de leur changement.
	\item  Intuitive - facile \`a apprendre mais sans lourdeur ou limitation pour l'utilisateur avanc\'e.
\end{itemize}

Pour plus d'information lisez la \href{http://docs.codehaus.org/display/GEOTOOLS/GeoServer+Style+Editor}{page wiki}

\subsection*{ GeoTools }
\subsubsection{ Sources de donn\'ees raster multi-dimensionelles }

 \textbf{\'Etudiant :} Daniele Romagnolil \\ \textbf{Parrain :} Simone Giannecchini

Il s'agit d'un ensemble de plugins Java Image I/O capable de fournir un point de d\'epart pour la construction de plugins GeoTools pour g\'erer les formats de donn\'ees multidimensionnelles telles que netCDF, HDF, GRIB1.

\begin{itemize}
	\item  NetCDF. Citation de (\url{http://www.unidata.ucar.edu/software/netcdf/}), ``NetCDF (network Common Data Form) est un ensemble de biblioth\`eques logicielles et de format de donn\'ees ind\'ependant de la machine qui g\`ere la cr\'eation, l'acc\`es et le partage de donn\'ees scientifiques matricielles.''.
	\item  HDF (Hierarchical Data Format) est une biblioth\`eque et un format de fichier multi-objets et d\'evelopp\'e par la NCSA (\url{http://www.ncsa.uiuc.edu/}).
	\item  GRIB1 est un format de donn\'ees standardis\'e par la commision de la World Meteorological Organization (\url{http://www.wmo.ch/}) for Basic Systems, qui est commun\'ement utilis\'e en m\'et\'eorologie pour stocker des donn\'ees m\'et\'eorologiques historiques et pr\'evisionnelles.
\end{itemize}

Pour plus d'information lisez la \href{http://docs.codehaus.org/display/GEOTOOLS/Plugins+for+multidimensional+raster+data+sources}{page wiki}

\subsubsection{ 3D Rendering Pipeline }


 \textbf{\'Etudiant :}  Hans Haggstrom \\ \textbf{Parrain :}  Jody Garnett

Le rendu 3D fournit une vue en trois dimensions de donn\'ees g\'eographiques GeoTools. Il emploie le moteur de rendu 2D normale pour rendre la texture de surface. Il met en \oe{}uvre un niveau de d\'etail fond\'e sur le chargement et la mise en cache de donn\'ees g\'eographiques afin d'acc\'el\'erer le rendu, et de permettre les vues en perspective montrant les objets proches et lointains en m\^eme temps. Des am\'eliorations pourront \^etre r\'ealis\'ees sur le rendu des donn\'ees d'altitude bas\'ee sur les donn\'ees de couverture de hauteur. En outre, la gestion de styles 3D \`a appliquer aux objets poncuels, lin\'eaires et surfaciques pourrait \^etre ajout\'ee.

Pour plus d'information lisez la \href{http://docs.codehaus.org/display/GEOTOOLS/3D}{page wiki de GeoTools du Rendering Pipeline}.

\subsection*{ PostGIS }
\subsubsection{ Mod\`ele et op\'erations pour les couvertures }


 \textbf{\'Etudiant :} Xing Lin \\ \textbf{Parrain :} Timothy Keitt

Ce projet comprend un mod\`ele de donn\'ees raster et leur stockage dans PostGIS. Les outils d'importation et d'exportation sont \'egalement disponibles pour les formats d'images usuels. Un article sur ce projet est disponible \`a \url{http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1370128}

Pour plus d'information lisez le \href{http://code.google.com/soc/osgeo/appinfo.html?csaid=2425D23F080CAAFB}{r\'esum\'e du Google Summer of Code}.

\section*{ Sommet des parrains }

Certains projets (qui se sont bien comport\'es, qui ont rendu leurs \'etudes dans les temps etc) ont \'et\'e invit\'es \`a envoyer un parrain au sommet de parrainage du SoC. L'OSGeo m'a envoy\'e (Wolf Bergenheim du projet GRASS). Des parrains de plus de 100 projets ont uni leurs forces au QG de Google \`a Mountainview, CA, et a examin\'e diff\'erents aspects du SoC. Le sommet a \'et\'e organis\'e comme une non-conf\'erence, ce qui signifie que les participants ont produit eux-m\^emes le programme. Un wiki avec les discussions a \'et\'e mis en place \`a \url{http://googlesummerofcode.jot.com/}

\subsection*{ Le\c{c}ons apprises }

De nombreux enseignements ont \'et\'e tir\'es lors du SoC 2007 (au moins par moi), en tant que parrain, mais aussi des points d'ordre g\'en\'eral sur la mani\`ere d'attirer plus de d\'eveloppeurs et sur la fa\c{c}on de ``garder'' les \'etudiants du SoC dans les projets. Tout d'abord, permettez-moi de parler de la mani\`ere d'attirer les \'etudiants.

\subsubsection{ Comment attirer des \'etudiants ? }

Nous avons obtenu environ deux fois plus de propositions de projets que nous n'avions de cr\'eneaux horaires disponibles, mais par rapport \`a d'autres projets, il y en avait assez peu. Je vais maintenant discuter de la fa\c{c}on dont nous pourrions attirer davantage d'\'etudiants cette ann\'ee.

\textbf{ Promettre c\'el\'ebrit\'e et gloire }

Par cela je veux dire qu'il doit \^etre clairement indiqu\'e que l'on donne aux \'etudiants un moment de ``reconnaissance''. Cela signifie une mise en valeur sur le site de l'OSGeo, peut-\^etre m\^eme des communiqu\'es sur leurs progr\`es. Et une exposition similaire au sein du projet dans lequel ils travaillent.

\textbf{ Montrer que vous avez appr\'eci\'e leur travail }

Le code que les \'etudiants produisent doit terminer dans le d\'ep\^ot principale du code, et cela doit \^etre clair d\`es le d\'epart que cela sera le cas. Nous devons \'egalement promettre d'inclure leurs projets dans la prochaine version d\`es qu'il est termin\'e. Si nous promettons que leur code fera partie du projet, cela devrait motiver les \'etudiants encore plus.

\textbf{ Avoir une liste d'id\'ees int\'eressantes mais vagues }

Lorsque nous travaillons sur une liste d'id\'ees, nous devrions laisser la place \`a l'innovation. Laissez les \'etudiants combler les lacunes. De cette fa\c{c}on, nous allons peut-\^etre attirer la meilleure personne.

\textbf{ Travailler avec les \'etudiants d\`es le d\'ebut }

Cela signifie que lorsque vous voyez une application int\'eressante, prenez le temps de mettre en place une page wiki pour r\'ediger les id\'ees avec l'\'etudiant. L'an dernier, il y avait beaucoup de temps pour parler de choses et d'autres avec les \'etudiants. Le chat sur l'IRC est aussi une bonne id\'ee. Lorsque les \'etudiants voient que nous nous sommes engag\'es au SoC, et que nous les \'ecoutons, ils devraient \^etre plus int\'eress\'es.

\textbf{ Int\'egration \`a la communaut\'e }

Une fois que nous avons s\'electionn\'e les meilleurs \'etudiants pour travailler sur les projets les plus cools, nous devrions les int\'egrer dans la communaut\'e pour obtenir de nouveaux d\'eveloppeurs impliqu\'es (du sang frais, comme j'aime \`a le rappeler). Comment pouvons-nous r\'ealiser cela ?

\textbf{ Faire parler l'\'etudiant sur les listes de diffusion et les canaux IRC }

La plupart, sinon toutes les communications des projets devraient \^etre sur la liste principale de d\'eveloppement du projet et la liste de canaux IRC. Si l'\'etudiant est timide, une astuce consiste \`a dire `` Je ne sais pas, essayez les d\'eveloppeurs de la liste''. Une fois qu'il aura envoy\'e un mail (et vu que personne ne le frappe ), il ne devrait avoir aucun probl\`eme \`a s'int\'egrer, il pourrait m\^eme r\'epondre aux probl\`emes des autres membres de la liste.
 
\textbf{ Assurez-vous que l'ensemble du projet conna\^it et est conscient du SoC }

Si l'ensemble du projet conna\^it l'\'etudiant, ils vous aideront \`a l'accueillir.

\textbf{ Aider les \`a terminer par un succ\`es }

Si l'\'etudiant lutte, il y a des chances qu'il ne terminera pas le projet. S'il est aid\'e et que l'ensemble de la communaut\'e des d\'eveloppeurs le soutient, il n'aura pas \`a lutter beaucoup, et il terminera son projet vraisemblablement.

\textbf{ Rendre l'\'etudiant heureux }

Un d\'eveloppeur heureux est un d\'eveloppeur productif. Si l'\'etudiant se sent accueilli et appr\'eci\'e il se plaira probablement \`a faire partie de la communaut\'e, et donc tr\`es probablement restera avec nous.

\textbf{ Coop\'eration crois\'ee et coop\'eration en dehors de l'OSGeo }

Il a \'et\'e \'egalement discut\'e de la collaboration avec d'autres organismes sur le SoC. Pour nous, cela signifie soit que l'on pourrait trouver des projets SoC qui impliquent plus d'un projet OSGeo, ou cela pourrait signifier que nous collaborions avec un projet hors OSGeo comme Drupal. Drupal a manifest\'e son int\'er\^et \`a collaborer avec PostGIS en ce qui concerne la probl\'ematique spatiale. Cela signifie que nous pourrions fournir un parrain pour aider avec les probl\'ematiques spatiales tandis qu'ils nous donnent un parrain pour nous aider sur PHP. Cela pourrait \^etre fait pour un ou deux projets.

\section*{ Wrap-up }

Le Soc de l'an dernier est arriv\'e un peu par surprise pour nous au sein du projet GRASS, de sorte que nous n'\'etions pas vraiment en mesure de nous organiser pour apporter plus d'id\'ees de projets pour le SoC, mais finalement, nous avons pu proposer un projet pour deux \'etudiants. Aussi l'ann\'ee derni\`ere a \'et\'e un peu confuse et peut-\^etre pas aussi organis\'ee qu'elle aurait pu l'\^etre. Des parrains d'autres projets ne semblaient pas parler ensemble et cela a \'et\'e ressenti un peu comme une fragmentation de l'effort. Cette ann\'ee, j'esp\`ere \^etre en mesure d'utiliser les exp\'eriences acquises de l'an dernier pour que le travail des nouveaux parrains soit plus facile et plus clair, et peut-\^etre pour une approche plus coh\'erente du SoC au sein de l'OSGeo.

\subsection*{ Quelques mots de nos \'etudiants }

Deux \'etudiants, Chris and Daniel, ont voulu partager leurs exp\'eriences du SoC avec nous.

\textbf{ Chris Whitney }

J'ai appr\'eci\'e ma participation au Google Summer of Code. Le projet a \'et\'e ma premi\`ere exp\'erience sur un projet de logiciel SIG, et certainement ma premi\`ere exposition \`a des projets SIG open-source. Heureusement, la communaut\'e GeoServer a \'et\'e tr\`es reconnaissante et un environnement favorable pour d\'ebuter mon projet. J'ai \'et\'e parrain\'e par Google pour participer au FOSS4G 2007, qui a \'et\'e une excellente occasion pour moi de pr\'esenter mon projet et d'en apprendre plus sur les technologies li\'es \`a l'OSGEO.

\textbf{ Daniel Bundala }

Je voudrais faire ici quelques commentaires sur mon exp\'erience avec GRASS, le Summer of Code et d'autres choses. Ce n'est pas tr\`es officiel, toutefois, j'esp\`ere que certaines personnes pourront trouver cela tr\`es utile et / ou int\'eressant.

Quand j'ai \'et\'e accept\'e pour le SoC, je n'avais absolument aucune exp\'erience de GRASS ou de toute autre SIG. En fait, ma seule exp\'erience avec les cartes num\'eriques / g\'eographiques / ou quoi que soit de similaire \'etait par l'interm\'ediaire de Google Maps. Je n'avais jamais eu besoin d'utiliser autre chose avant et j'ai donc pens\'e que c'\'etait essentiellement la seule chose dont on avait besoin. Il ne m'a pas fallu longtemps pour r\'ealiser \`a quel point j'ai \'et\'e ...

D'une mani\`ere g\'en\'erale, j'ai \'et\'e tr\`es satisfait de mon travail sur GRASS ; sans aucun doute, cela a \'et\'e beaucoup plus int\'eressant que pr\'evu. J'ai appris beaucoup de nouveaux algorithmes et m\'ethodes que j'ai mis en \oe{}uvre dans GRASS. Aussi, les cours sur l'alg\`ebre lin\'eaire et le calcul que j'ai re\c{c}us m'ont \'et\'e utiles. Enfin, je suis maintenant plus exp\'eriment\'e et un utilisateur plus avanc\'e de GRASS. Je me souviens que pendant les premi\`eres semaines j'ai tout fait avec la souris et ai travaill\'e presque exclusivement avec une interface graphique. Mais \`a la fin de l'\'et\'e, j'ai d\'ecouvert la beaut\'e et l'efficacit\'e de la ligne de commande et maintenant je lance GRASS en mode texte uniquement...

Un \'ev\'enement particulier dont je me souviens encore, c'est que Wolf, mon parrain, une fois m'a envoy\'e un document concernant certaines g\'en\'eralisations de vecteur sur lesquelles j'ai travaill\'e. Cela n'aurait pas \'et\'e un gros probl\`eme si cela n'avait pas \'et\'e en allemand. Je crois vraiment que mon professeur d'allemand serait fier de moi puisque je l'ai lu et j'ai compris de quoi cela parlait. Eh bien, peut-\^etre pas, car apr\`es 4 ans d'`` \'etude intensive'', je n'ai m\^eme pas \'et\'e en mesure de comprendre tous les mots.

Pour r\'esumer, je dois dire que j'ai pass\'e l'\'et\'e dernier d'une mani\`ere tr\`es productive. Je continue de lire la liste de GRASS presque tous les jours. En partie, parce que je veux conna\^itre les \'eventuels bugs de mon module, mais surtout parce que je suis toujours int\'eress\'e par le projet en lui-m\^eme. En outre, cela a \'et\'e une exp\'erience en programmation / linguistique et j'esp\`ere que je serai en mesure de recommencer plus tard.
