Index: trunk/workshop-foss4g/introduction.rst
===================================================================
--- trunk/workshop-foss4g/introduction.rst	(revision 8)
+++ trunk/workshop-foss4g/introduction.rst	(revision 9)
@@ -74,75 +74,77 @@
 Les index spatiaux actuellement utilisÃ©s par les diffÃ©rents systÃšme de gestion de bases de donnÃ©es varient considÃ©rablement. L'implÃ©mentation la plus commune est l'`arbre R <http://en.wikipedia.org/wiki/R-tree>`_ (utilisÃ© dans PostGIS), mais il existe aussi des implÃ©mentations de type `Quadtrees <http://en.wikipedia.org/wiki/Quadtree>`_, et des `indexes basÃ©s sur une grille <http://en.wikipedia.org/wiki/Grid_(spatial_index)>`_.
 
-Fonctions spatiales
+Les Fonctions spatiales
 -------------------
 
-For manipulating data during a query, an ordinary database provides **functions** such as concatenating strings, performing hash operations on strings, doing mathematics on numbers, and extracting information from dates.  A spatial database provides a complete set of functions for analyzing geometric components, determining spatial relationships, and manipulating geometries.  These spatial functions serve as the building block for any spatial project.
-
-The majority of all spatial functions can be grouped into one of the following five categories:
-
-#. **Conversion**: Functions that *convert* between geometries and external data formats. 
-#. **Management**: Functions that *manage* information about spatial tables and PostGIS administration.
-#. **Retrieval**: Functions that *retrieve* properties and measurements of a Geometry. 
-#. **Comparison**: Functions that *compare* two geometries with respect to their spatial relation. 
-#. **Generation**: Functions that *generate* new geometries from others.
-
-The list of possible functions is very large, but a common set of functions is defined by the :term:`OGC` :term:`SFSQL` and implemented (along with additional useful functions) by PostGIS.
-
-What is PostGIS?
-================
-
-PostGIS turns the `PostgreSQL <http://www.postgresql.org/>`_ Database Management System into a spatial database by adding adding support for the three features: spatial types, indexes, and functions.  Because it is built on PostgreSQL, PostGIS automatically inherits important "enterprise" features as well as open standards for implementation 
-
-But what is PostgreSQL?
------------------------
-
-PostgreSQL is a powerful, object-relational database management system (ORDBMS). It is released under a BSD-style license and is thus free and open source software. As with many other open source programs, PostgreSQL is not controlled by any single company, but has a global community of developers and companies to develop it.
-
-PostgreSQL was designed from the very start with type extension in mind -- the ability to add new data types, functions and access methods at run-time. Because of this, the PostGIS extension can be developed by a separate development team, yet still integrate very tightly into the core PostgreSQL database.
-
-Why choose PostgreSQL?
-~~~~~~~~~~~~~~~~~~~~~~
-
-A common question from people familiar with open source databases is, "Why wasn't PostGIS built on MySQL?".
-
-PostgreSQL has:
-
-  * Proven reliability and transactional integrity by default (ACID)
-  * Careful support for SQL standards (full SQL92)
-  * Pluggable type extension and function extension
-  * Community-oriented development model
-  * No limit on column sizes ("TOAST"able tuples) to support big GIS objects
-  * Generic index structure (GiST) to allow R-Tree index
-  * Easy to add custom functions
-
-Combined, PostgreSQL provides a very easy development path to add new spatial types. In the proprietary world, only Illustra (now Informix Universal Server) allows such easy extension. This is no coincidence; Illustra is a proprietary re-working of the original PostgreSQL code base from the 1980's. 
-
-Because the development path for adding types to PostgreSQL was so straightforward, it made sense to start there. When MySQL released basic spatial types in version 4.1, the PostGIS team took a look at their code, and the exercise reinforced the original decision to use PostgreSQL. Because MySQL spatial objects had to be hacked on top of the string type as a special case, the MySQL code was spread over the entire code base. Development of PostGIS 0.1 took under a month. Doing a "MyGIS" 0.1 would have taken a lot longer, and as such, might never have seen the light of day.
-
-Why not Shapefiles?
--------------------
-
-The `shapefile <http://en.wikipedia.org/wiki/Shapefile>`_ (and other file formats) have been the standard way of storing and interacting with spatial data since GIS software was first written. However, these "flat" files have the following disadvantages:
-
-* **Files require special software to read and write.**  SQL is an abstraction for random data access and analysis. Without that abstraction, you will need to write all the access and analysis code yourself.
-* **Concurrent users can cause corruption.** While it's possible to write extra code to ensure that multiple writes to the same file do not corrupt the data, by the time you have solved the problem and also solved the associated performance problem, you will have written the better part of a database system. Why not just use a standard database?
-* **Complicated questions require complicated software to answer.** Complicated and interesting questions (spatial joins, aggregations, etc) that are expressible in one line of SQL in the database take hundreds of lines of specialized code to answer when programming against files.
-
-Most users of PostGIS are setting up systems where multiple applications will be expected to access the data, so having a standard SQL access method simplifies deployment and development. Some users are working with large data sets; with files, they might be segmented into multiple files, but in a database they can be stored as a single large table.
-
-In summation, the combination of support for multiple users, complex ad hoc queries, and performance on large data sets are what sets spatial databases apart from file-based systems.
-
-A brief history of PostGIS
---------------------------
-
-In the May of 2001, `Refractions Research <http://www.refractions.net/>`_  released the first version of PostGIS. PostGIS 0.1 had objects, indexes and a handful of functions. The result was a database suitable for storage and retrieval, but not analysis.
-
-As the number of functions increased, the need for an organizing principle became clear.  The "Simple Features for SQL" (:term:`SFSQL`) specification from the Open Geospatial Consortium provided such structure with guidelines for function naming and requirements.
-
-With PostGIS support for simple analysis and spatial joins, `Mapserver <http://mapserver.org/>`_ became the first external application to provide visualization of data in the database. 
-
-Over the next several years the number of PostGIS functions grew, but its power remained limited. Many of the most interesting functions (e.g., ST_Intersects(), ST_Buffer(), ST_Union()) were very difficult to code.  Writing them from scratch promised years of work.
-
-Fortunately a second project, the "Geometry Engine, Open Source" or `GEOS <http://trac.osgeo.org/geos>`_, came along. The GEOS library provides the necessary algorithms for implementing the :term:`SFSQL` specification. By linking in GEOS, PostGIS provided complete support for :term:`SFSQL` by version 0.8.
+Pour manipuler les donnÃ©es lors d'une requÃªte, une base de donnÃ©es classique fournit des **fonctions** comme la concatÃ©nation de chaÃ®nes de caractÃšres, le cacul de la clef md5 d'une chaÃ®ne, la rÃ©alisation d'opÃ©rations mathÃ©matiques sur les nombres ou l'extraction d'informations spÃ©cifiques sur une date. Une base de donnÃ©es spatiales fournit un ensemble complet de fonctions pour analyser les composants gÃ©ographiques, dÃ©terminer les relations spatiales et manipuler les objets gÃ©ographiques. Ces fonctions spatiales servent de piÃšce de lÃ©go pour de noombreux projet SIG.
+
+La majoritÃ© des fonctions spatiales peuvent Ãªtre regroupÃ©es dans l'une des cinq catÃ©gories suivantes :
+
+#. **Conversion**: fonctions qui *convertissent* les donnÃ©es gÃ©ographiques dans un format externe.. 
+#. **Gestion**: fonctions qui permettre de *gÃ©rer* les informations relatives  aux tables spatiales et l'administration de PostGIS.
+#. **RÃ©cupÃ©ration**: fonctions qui permettent de *rÃ©cupÃ©rer* les propriÃ©tÃ© et les mesures d'une gÃ©omÃ©trie. 
+#. **Comparaison**: fonctions qui permettent de *comprer* deux gÃ©omÃ©tries en respectant leur relations spatiales. 
+#. **Contruction**: fonctions qui permettent de *construire* de nouvelles gÃ©omÃ©trie Ã  partir d'autre.
+
+La liste des fonctions possibles est trÃšs vaste, mais un ensemble communs Ã  l'ensemble des implÃ©mentation est dÃ©fini par la spÃ©cification term:`OGC` :term:`SFSQL` et sont implÃ©mentÃ©es (ainsi que certaines supplÃ©mentaires) dans PostGIS.
+
+
+Quest-ce que PostGIS ?
+======================
+
+PostGIS confÃšre au `systÃšme de gestion de base de donnÃ©es PostgreSQL <http://www.postgresql.org/>`_ le status de base de donnÃ©es spatiales en ajoutant les trois supports suivants : les types de donnÃ©es spatiales, les indexes et les fonctions. Ãtant donnÃ© que cela est basÃ© sur PostgreSQL, PostGIS bÃ©nÃ©ficie automatiquement des capacitÃ©s orientÃ© "entreprise" ainsi que le respect des standards de cette implÃ©mentation.
+
+Mais qu'est-ce que PostgreSQL ?
+-------------------------------
+
+PostgreSQL est une puissant systÃšme de gestion de donnÃ©es relationel Ã  objets (SGBDRO). Il a Ã©tÃ© publiÃ© sous la licence de style BSD et est donc un logiciel libre. Comme avec beaucoup de logiciels libres, PostgreSQL n'est pas controlÃ© par une sociÃ©tÃ© unique mais par une communautÃ© de dÃ©veloppeurs et de sociÃ©tÃ©s qui le dÃ©velopper.
+
+PostgreSQL a Ã©tÃ© conÃ§u depuis le dÃ©but en conservant Ã  l'esprit qu'il serait potentiellement nÃ©cessaire de l'Ã©tendre Ã  l'aide d'extensions particuliÃšres -- la possibilitÃ© d'ajouter de nouveau types, des nouvelles fonctions et des mÃ©thodes d'accÃšs Ã  chaud. GrÃ¢ce Ã  cela, une extension de PostgreSQL peut Ãªtre dÃ©veloppÃ© par une Ã©quipe de dÃ©veloppement sÃ©parÃ©, bien que le lien soit encore trÃšs fortement liÃ© au coeur de la base de donnÃ©es PostgreSQL.
+
+Pourquoi choisir PostgreSQL ?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Une question que se pose souvent les gens familliÃ©s avec les bases de donnÃ©es libres est : "Pourquoi PostGIS n'a pas Ã©tÃ© basÃ© sur MySQL ?"
+
+PostgreSQL a:
+
+  * prouvÃ© sa fiabilitÃ© et respect l'intÃ©gritÃ© des donnÃ©es ( propriÃ©tÃ©s ACID)
+  * un support soigneux des standard SQL (respecte la norme SQL92)
+  * un support pour le dÃ©veloppement d'extensions et de nouvelles fonctions
+  * un modÃšle de dÃ©veloppement orientÃ© communautÃ© 
+  * pas de limite sur la taille des colonne (les tuples peuvent Ãªtre "TOAST"Ã©s) pour supporter des objets gÃ©ographiques
+  * un structure d'index gÃ©nÃ©rique (GiST) permettant l'indÃ©xation Ã  l'aide d'abres R
+  * facile ajout de fonctions personalisÃ©es
+
+Tout ceci combinÃ©, PostgreSQL permet un cheminement simple du dÃ©veloppement nÃ©cessaire Ã  l'ajout des types spatiaux. Dans le monde propriÃ©taires, seul Illustra (maintenant Informix Universal Server) permet une extension aussi simple. Ceci n'est pas une cohincidence, Illustra estune version propriÃ©taire modifiÃ©es du code original de PostgreSQL publiÃ© dans les annÃ©es 1980. 
+
+Puisque le cheminement  du dÃ©veloppement nÃ©cessaire Ã  l'ajout de types Ã  PostgreSQL est direct, il semblÃ© naturel de commencer par lÃ . Lorsque MySQL a publiÃ© des types de donnÃ©es spatiales de base dans sa version 4.1, l'Ã©quipe de PostGIS a jeutÃ© un coup d'oueil dans leur code et cela a confirmÃ© le choix initial d'utiliser PostgreSQL. Puisque les objets gÃ©ographiques de MySQL doivent Ãªtre considÃ©rÃ©s comme un cas particulier de chaÃ®nes de caractÃšres, le code de MySQL a Ã©tÃ© diffus dans l'intÃ©gralitÃ© du code de base. Le dÃ©veloppement de PostGIS version 0.1 a prit un mois. RÃ©aliser un projet "MyGIS" 0.1 aurait prit beaucoup plus de temps, c'est sans doute pourquoi il n'a jamais vu le jour.
+
+Pourquoi pas des fichier Shapefile ?
+------------------------------------
+
+Les fichiers `shapefile <http://en.wikipedia.org/wiki/Shapefile>`_ (et les autres formats) ont Ã©tÃ© la maniÃšre standard de stoquer et d'interragir avec les donnÃ©es spatiales depuis l'origine des SIG. NÃ©anmoins, ces fichiers "plats" ont les inconvÃ©nients suivants :
+
+* **Les fichier au formats SIG requiÃšrent un logiciel spÃ©cifique pour les lire et les Ã©crire.**  Le langage SQL est une abstraction de l'accÃšs allÃ©atoire au donnÃ©es et Ã  leur analyse. Sans cette bastraction, vous devrez dÃ©velopper l'accÃšs et l'anayse par cos propre moyens.
+* **L'accÃšs concurent au donnÃ©es peut entraine foier un stoquage de donnÃ©es corrompues.** Alors qu'il est possible d'Ã©crire du code supplÃ©mentaire afin de garantir la cohÃ©rence des donnÃ©es, une fois ce problÃšme solutionnÃ© et celui de la performance associÃ©e, vous aurez re-Ã©crit la partie la plus important d'un systÃšme de base de donnÃ©es. Pourquoi ne pas simplement utilisÃ© une base de donnÃ©es standard dans ce cas ?
+* **Les questions compliquÃ©es nÃ©cessitent des logiciels compliquÃ©s pour y rÃ©pondre.** Les question intÃ©ressantes et compliquÃ©es (jointures spatiales, aggrÃ©gations, etc) qui sont exprimables en une ligne de SQL grÃ¢ce Ã  la base de donnÃ©es, nÃ©cessitent une centaines de lignes de code spÃ©cifiques pour y rÃ©pondre dans le cas de fichiers.
+
+La plupart des utilisateurs de PostGIS ont mis en place des systÃšmes oÃ¹ diverses applications sont succeptible d'accÃ©der aux donnÃ©es, donc avoir les mÃ©thodes d'accÃšs SQL standard simplifit le dÃ©ploiement et le dÃ©veloppement. Certains utilisateurs travaille avec de grand jeux de donnÃ©es, avec des fichiers, qui peuvent Ãªtre segmentÃ© en plusieurs fichiers, mais dans une base de donnÃ©es ces donnÃ©es peuvent Ãªtre stoquÃ© dans une seule grande table.
+
+En rÃ©sumÃ©, la combinaison du support de l'accÃšs cocurent, des requÃªtes complexes spÃ©cifiques et de la performance sur de grand jeux de donnÃ©es sont ce qui diffÃ©rencies les base de donnÃ©es spatiales des systÃšmes utilisant des fichiers.
+
+Un bref histoirique de PostGIS
+------------------------------
+
+En mai 2001, la sociÃ©tÃ© `Refractions Research <http://www.refractions.net/>`_  publie la permiÃšre version de PostGIS. PostGIS 0.1 fournissait les objets, les indexes et des fonctions utilies. Le rÃ©sultat Ã©tait une base de donnÃ©es permettant le stockage et l'accÃšs mais pas encore l'analyse.
+
+Comme le nombre de fonctions augmentÃ©, le besoin d'un principe d'organisation devint clair. La spÃ©cification "Simple Features for SQL" (:term:`SFSQL`) publiÃ©e par l'Open Geospatial Consortium fournit une telle structure avec des indications pour le nommage des fonctions et les prÃ©-requis.
+
+Avec le support dans PostGIS de simples fonctions d'analises et de jointures spatiales, 
+`Mapserver <http://mapserver.org/>`_ devint la premiÃšre application externe permettant de visualiser les donnÃ©es de la base de donnÃ©es.
+
+Au cours de ces derniÃšres annÃ©es le nombre de focntions fournies par PostGIS grandit, mais sa puissance restait limitÃ©. La plupart des fonctions interressantes (ex : ST_Intersects(), ST_Buffer(), ST_Union()) Ã©taient difficile Ã  implÃ©menter. Les Ã©crire en repartant du dÃ©but promettait des annÃ©es de travail.
+
+Heureusement un second projet, la librarie "Geometry Engine, Open Source" or `GEOS <http://trac.osgeo.org/geos>`_ arriva. Cette librairie fournit l'ensemble des algorythmes nÃ©cessaire Ã  l'implÃ©mentation de la spÃ©cification :term:`SFSQL` . En se liant Ã  GEOS, PostGIS fournit alors le support complet de la :term:`SFSQL` depuis la version 0.8.
 
 As PostGIS data capacity grew, another issue surfaced: the representation used to store geometry proved relatively inefficient. For small objects like points and short lines, the metadata in the representation had as much as a 300% overhead. For performance reasons, it was necessary to put the representation on a diet.  By shrinking the metadata header and required dimensions, overhead greatly reduced. In PostGIS 1.0, this new, faster, lightweight representation became the default.
