Index: /trunk/workshop-foss4g/indexing.rst
===================================================================
--- /trunk/workshop-foss4g/indexing.rst	(revision 32)
+++ /trunk/workshop-foss4g/indexing.rst	(revision 33)
@@ -1,16 +1,16 @@
 .. _indexing:
 
-Section 14: Spatial Indexing
-============================
+Partie 14 : les indexes spatiauux
+=================================
 
-Recall that spatial index is one of the three key features of a spatial database. Indexes are what make using a spatial database for large data sets possible. Without indexing, any search for a feature would require a âsequential scanâ of every record in the database. Indexing speeds up searching by organizing the data into a search tree which can be quickly traversed to find a particular record. 
+Rapellez-vous que les indexes spatiaux est l'une des trois fonctionnalitÃ©s clÃ©es d'une base de donnÃ©es spatiales. Les indexes sont ce qui rend possible l'utilisation de grandes quantitÃ©s de donnÃ©es dans une base. Sans indexation, chaque recherche d'une entitÃ© nÃ©cessitera d'accÃ©der sÃ©quentiellement Ã  tout les enregistrement de la base de donnÃ©es. L'indexation rend plus rapide les recherche en organisant les donnÃ©es dans des arbre de recherches qui peuvent Ãªtre parcouru efficacement pour retrouver une entitÃ© particuliÃšre.
 
-Spatial indices are one of the greatest assets of PostGIS.  In the previous example building spatial joins requires comparing whole tables with each other. This can get very costly: joining two tables of 10,000 records each without indexes would require 100,000,000 comparisons; with indexes the cost could be as low as 20,000 comparisons.
+Les indexes spatiauxs ont l'un des plus grands atouts de PostGIS. Dans les exemples prÃ©cÃ©dents, nous construissions nos jointures spatiales en comparant la totalitÃ© des tables. Ceci peut s'averrer trÃšs coÃ»teux : rÃ©aliser la jointure de deux tables de 10000 enrigstrements sans index nÃ©cessitera de comparer 100000000 valeurs, avec les indexes le comparaisons requises seront 20000.
 
-When we loaded the ``nyc_census_blocks`` table, the pgShapeLoader automatically created a spatial index called ``nyc_census_blocks_the_geom_gist``
+Lorsque nous avons chargÃ© la table  ``nyc_census_blocks``, l'outils pgShapeLoader crÃ©e automatiquement un indexe spatial appelÃ© ``nyc_census_blocks_the_geom_gist``.
 
-To demonstrate how important indexes are for performance, let's search ``nyc_census_blocks`` **without** our spatial index. 
+Pour dÃ©montrer combien il est important d'indexer ses donnÃ©es pour la performance des requÃªtes, essayons de requÃªter notre table ``nyc_census_blocks`` **sans** utiliser notre indexe.
 
-Our first step is to remove the index.
+La premiÃšre Ã©tapt consiste a supprimer l'index.
 
 .. code-block:: sql
@@ -20,7 +20,7 @@
 .. note::
 
-   The ``DROP INDEX`` statement drops an existing index from the database system. For more information, see the PostgreSQL `documentation <http://www.postgresql.org/docs/7.4/interactive/sql-dropindex.html>`_.
+   La commande ``DROP INDEX`` supprime un index existant de la base de donnÃ©es. Pour de plus amples informations Ã  ce sujet, consultez la `documentation officielle de PostgreSQL <http://docs.postgresql.fr/9.1/sql-dropindex.html>`_.
    
-Now, watch the "Timing" meter at the lower right-hand corner of the pgAdmin query window and run the following. Our query searches through every single census block in order to identify the Broad Street entry.
+Maintenant, regardons le temps d'exÃ©cution dans le coin en bas Ã  droite  de l'interface de requÃªtage de pgAdmin et lanÃ§ons la commande suivante. Notre requÃªte recherche les bloques de la rue Broad.
 
 .. code-block:: sql
@@ -38,7 +38,7 @@
   360610007003006
   
-The ``nyc_census_blocks`` table is very small (only a few thousand records) so even without an index, the query only takes **55 ms** on my test computer.
+La table ``nyc_census_blocks`` est trÃšs petite (seulement quelque millier d'enregistrements) donc mÃªme sans l'index, la requÃªte prends **55 ms** sur mon ordinateur de test.
 
-Now add the spatial index back in and run the query again. 
+Maintenant remettons en place l'indexe et lanÃ§ons de nouveau la requÃªte.
 
 .. code-block:: sql
@@ -46,33 +46,33 @@
   CREATE INDEX nyc_census_blocks_the_geom_gist ON nyc_census_blocks USING GIST (the_geom);
 
-.. note:: The ``USING GIST`` clause tells PostgreSQL to use the generic index structure (GIST) when building the index.  If you receive an error that looks like ``ERROR: index row requires 11340 bytes, maximum size is 8191`` when creating your index, you have likely neglected to add the ``USING GIST`` clause.
+.. note:: l'utilisation de la clause ``USING GIST`` spÃ©cifie Ã  PostgreSQL de crÃ©er une structure (GIST) pour cet indexe. Si vous recevez un mesage d'erreur ressemblant Ã  ``ERROR: index row requires 11340 bytes, maximum size is 8191`` lors de la crÃ©ation, cela signifie sans doute que vous avez omis la clause ``USING GIST``.
 
-On my test computer the time drops to **9 ms**. The larger your table, the larger the relative speed improvement of an indexed query will be.
+Sur mon ordinateur de test le temps d'exÃ©cution se rÃ©duit Ã  **9 ms**. Plus votre table est grande, plus la diffÃ©rence de temps d'exÃ©cution pour une requÃªte utilisant les indexes sera augmentÃ©.
 
-How Spatial Indexes Work
-------------------------
+Comment les indexes spatiaux fonctionnent
+-----------------------------------------
 
-Standard database indexes create a hierarchical tree based on the values of the column being indexed. Spatial indexes are a little different -- they are unable to index the geometric features themselves  and instead index the bounding boxes of the features.
+Les indexes des base de donnÃ©es standards crÃ©e un arbre hierarchique basÃ© sur les valeurs de la colonne Ã  indexer. Les indexes spatiaux sont un peu diffÃ©rents - ils ne sont pas capable d'indexer des entitÃ© gÃ©mÃ©triques elles-mÃªme mais indexe leur Ã©tendues.
 
 .. image:: ./indexing/bbox.png
 
-In the figure above, the number of lines that intersect the yellow star is **one**, the red line. But the bounding boxes of features that intersect the yellow box is **two**, the red and blue ones. 
+Dans la figure ci-dessus, le nombre de lignes qui intersectent l'Ã©toile jaune est *unique*, la ligne rouge. Mais l'Ã©tendue des entitÃ©s qui intersectent la boÃ®te jaune sont *deux*, la boÃ®te rouge et la bleu.
 
-The way the database efficiently answers the question "what lines intersect the yellow star" is to first answer the question "what boxes intersect the yellow box" using the index (which is very fast) and then do an exact calculation of "what lines intersect the yellow star" **only for those features returned by the first test**. 
+La maniÃšre dont les bases de donnÃ©es rÃ©pondent de maniÃšre efficaces Ã  la questions "quelle ligne intersectent l'Ã©toile jaune ?" correspond Ã  d'abort rÃ©pondre Ã  question ; "quelle Ã©tendue intersecte l'Ã©tendue jaune" en utilisant les indexes (ce qui est trÃšs rapide) puis rÃ©alise le calcul exacte de "quelles lignes intersectent l'Ã©toile jaune" **seulement en utilisant les entitÃ©s retournÃ© par le premier test**.
 
-For a large table, this "two pass" system of evaluating the approximate index first, then carrying out an exact test can radically reduce the amount of calculations necessary to answer a query.
+Pour de grandes tables, il y a un systÃšme en "deux Ã©tape" d'Ã©valuation en utilisant dans un premier temps l'approximation Ã  l'aide d'indexes, puis en rÃ©alisant le test exact sur un quantitÃ© bien moins importantes de donnÃ©es ce qui rÃ©duit drastiquement le temps de calcul nÃ©cessaire Ã  cette deuxiÃšme Ã©tape.
 
-Both PostGIS and Oracle Spatial share the same "R-Tree" [#RTree]_ spatial index structure. R-Trees break up data into rectangles, and sub-rectangles, and sub-sub rectangles, etc.  It is a self-tuning index structure that automatically handles variable data density and object size.
+Ã la fois PotGIS et Oracle Spatial partage la mÃªme notion d'index structurÃ© sous la forme "d'arbres R" [#RTree]_. Les arbres R classent les donnÃ©es sous forme de rectangles, de sous-rectangles etc. Cette structure d'index gÃšre automatiquement la densitÃ© et la taille des objets.
 
 .. image:: ./indexing/index-01.png
 
-Index-Only Queries
-------------------
+RequÃªte avec seulement des index
+--------------------------------
 
-Most of the commonly used functions in PostGIS (:command:`ST_Contains`, :command:`ST_Intersects`, :command:`ST_DWithin`, etc) include an index filter automatically. But some functions (e.g., :command:`ST_Relate`) do not include and index filter.
+La plupart des fonctions utilisÃ©es par PostGIS (:command:`ST_Contains`, :command:`ST_Intersects`, :command:`ST_DWithin`, etc) prennent en compte les index automatiquement. Mais certaines fonctions (comme par exemple : :command:`ST_Relate`) ne les utilisent pas.
 
-To do a bounding-box search using the index (and no filtering), make use of the :command:`&&` operator. For geometries, the :command:`&&` operator means "bounding boxes overlap or touch" in the same way that for number the :command:`=` operator means "values are the same".
+Pour utiliser une recherche par Ã©tendue utilisant les indexes (et pas de filtres), vous pouvez utiliser l'opÃ©rateur :command:`&&`. Pour les gÃ©omÃ©tries, l'opÃ©rateur :command:`&&` signifie "l'Ã©tendue recouvre ou touche" de la mÃªme maniÃšre que l'opÃ©rateur :command:`=` sur des entiers signifi que les valeurs sont Ã©gales.
 
-Let's compare an index-only query for the population of the 'West Village' to a more exact query. Using :command:`&&` our index-only query looks like the following:
+Essayons de comparer une requÃªte avec seulement un indexe pour la population du quartier 'West Village'. En utilisant la commande :command:`&&` notre requÃªte ressemble Ã  ce qui suit :
 
 .. code-block:: sql
@@ -88,5 +88,5 @@
   50325
   
-Now let's do the same query using the more exact :command:`ST_Intersects` function.
+Maintenant essayons la mÃªme requÃªte en utilisant la fonction plus prÃ©cise :command:`ST_Intersects`.
 
 .. code-block:: sql
@@ -102,16 +102,16 @@
   27141
 
-A much lower answer! The first query summed up every block that intersected the neighborhood's bounding box; the second query only summed up those blocks that intersected the neighborhood itself.
+Un plus faible nombre de rÃ©sultat ! La premiÃšre requÃªte nous renvoit tout les bloques qui intersectent l'Ã©tendue du quartier, la seconde nous renvoit seulement les bloques qui intersectent le quartier lui-mÃªme.
 
-Analyzing
+Analyse
 ---------
 
-The PostgreSQL query planner intelligently chooses when to use or not to use indexes to evaluate a query. Counter-intuitively, it is not always faster to do an index search: if the search is going to return every record in the table, traversing the index tree to get each record will actually be slower than just linearly reading the whole table from the start.
+Le plannificateur de requÃªte de PostgreSQL choisit intelligemment d'utiliser ou non les indexes pour rÃ©aliser une requÃªte. Il n'est pas toujours plus rapide d'utiliser un index pour rÃ©aliser une recherche : si la recherche doit renvoyer l'ensemble des enregistrements d'une table, parcourir l'index pour rÃ©cupÃ©rer chaque valeur sera plus lent que de parcourir linÃ©airement l'ensemble de la table.
 
-In order to figure out what situation it is dealing with (reading a small part of the table versus reading a large portion of the table), PostgreSQL keeps statistics about the distribution of data in each indexed table column.  By default, PostgreSQL gathers statistics on a regular basis. However, if you dramatically change the make-up of your table within a short period of time, the statistics will not be up-to-date.
+Afin de savoir dans quelle situation il est nÃ©cessaire d'utiliser les idexes (lire une petite partie de la table plutÃŽt qu'une grande partie), PostgreSQL conserve des statistiques relatives Ã  la distribution des donnÃ©es dans chaque colonne indexÃ©e. Par dÃ©faut, PostgreSQL rassemble les statistiques sur une base rÃ©guliÃšre. NÃ©namoins, si vous changez dramatiquement les contenu de vos tables dans une pÃ©riode courte, les statisuqes ne seront alors plus Ã  jour.
 
-To ensure your statistics match your table contents, it is wise the to run the ``ANALYZE`` command after bulk data loads and deletes in your tables. This force the statistics system to gather data for all your indexed columns.
+Pour vous assurez que les statistiques correspondent bien au contenu de la table actuelle, il est courrant d'utiliser la commande ``ANALYZE`` aprÃšs un grand nombre de modifications ou de suppression de vos donnÃ©e. Cela force le systÃšme de gestion des statistiques Ã  rÃ©cupÃ©rer l'ensemble des donnÃ©es des colonnes indexÃ©es.
 
-The ``ANALYZE`` command asks PostgreSQL to traverse the table and update its internal statistics used for query plan estimation (query plan analysis will be discussed later). 
+La commande ``ANALYZE`` demande Ã  PostgreSQL de parcourir la table et de mettre Ã  jour les statistiques utilisÃ©es par le plannificateur de requÃªtes (la plannification des requÃªtes sera traitÃ© utiltÃ©rieurement).
 
 .. code-block:: sql
@@ -119,14 +119,14 @@
    ANALYZE nyc_census_blocks;
    
-Vacuuming
+NÃ©ttoyage
 ---------
 
-It's worth stressing that just creating an index is not enough to allow PostgreSQL to use it effectively.  VACUUMing must be performed whenever a new index is created or after a large number of UPDATEs, INSERTs or DELETEs are issued against a table.  The ``VACUUM`` command asks PostgreSQL to reclaim any unused space in the table pages left by updates or deletes to records. 
+Il est souvent stressant de constater que la simple crÃ©ation d'un indexe n'est pas suffisant pour que PostgreSQL l'utilise efficacement. Le nettoyage doit Ãªtre rÃ©alisÃ© aprÃšs qu'un indexe soit crÃ©Ã© ou aprÃšs un grand nombre de requÃªtes UDATE, INSERT ou DELETE est Ã©tÃ© rÃ©alisÃ© sur une table. La commande ``VACUUM`` demande Ã  PostgreSQL de rÃ©cupÃ©rer chaque espace non utilisÃ© dans les pages de la table qui sont laissÃ© en l'Ã©tat lors des requÃªtes UPDATE ou DELETE Ã  cause du modÃšle d'estapillage multi-versions.
 
-Vacuuming is so critical for the efficient running of the database that PostgreSQL provides an "autovacuum" option.
+Le nettoyage des donnÃ©es est tellement important pour une utilisation efficace du serveur de base de donnÃ©es PostgreSQL qu'il existe maintenant une option "autovacuum".
 
-Enabled by default, autovacuum both vacuums (recovers space) and analyzes (updates statistics) on your tables at sensible intervals determined by the level of activity.  While this is essential for highly transactional databases, it is not advisable to wait for an autovacuum run after adding indices or bulk-loading data.  If a large batch update is performed, you should manually run ``VACUUM``.
+ActivÃ©e par dÃ©faut, le processus autovacuum Ã  la fois nÃ©ttoit (rÃ©cupÃšre l'espace libre) et analyse (met Ã  jour les statistiques) de vos tables suivant un interval donnÃ©e dÃ©terminÃ© par l'activitÃ© des bases de donnÃ©es. Bien que cela soit pour les bases de donnÃ©es hautement transactionnelles, il n'est pas supportable de devoir attendre que le processus autovacuum se lance lors de la mise Ã  jour ou la suppression massive de donnÃ©es. Dans ce cas, il faut lancer la commande ``VACUUM`` manuellement.
 
-Vacuuming and analyzing the database can be performed separately as needed.  Issuing ``VACUUM`` command will not update the database statistics; likewise issuing an ``ANALYZE`` command will not recover unused table rows.  Both commands can be run against the entire database, a single table, or a single column.
+Le nettoyage et l'analyse de la base de donnÃ©es peut Ãªtre rÃ©alisÃ©e sÃ©parÃ©ment si nÃ©cessaire. Utiliser la commande ``VACUUM`` ne mettra pas Ã  jour les statistiques alors que lancer la commande ``ANALYZE`` ne rÃ©cupÃšrera pas l'espace libre des lignes d'une table. Chacune de ces commandes peut Ãªtre lancÃ© sur l'intÃ©gralitÃ© de la base de donnÃ©es, sur une table ou sur une seule colonne.
 
 .. code-block:: sql
@@ -134,12 +134,12 @@
    VACUUM ANALYZE nyc_census_blocks;
 
-Function List
--------------
+Liste des fonctions
+-------------------
 
-`geometry_a && geometry_b <http://postgis.org/docs/ST_Geometry_Overlap.html>`_: Returns TRUE if A's bounding box overlaps B's.
+`geometry_a && geometry_b <http://postgis.org/docs/ST_Geometry_Overlap.html>`_: retourne TRUE si l'Ã©tendue de A cheuvauche celle de B.
 
-`geometry_a = geometry_b <http://postgis.org/docs/ST_Geometry_EQ.html>`_: Returns TRUE if A's bounding box is the same as B's.
+`geometry_a = geometry_b <http://postgis.org/docs/ST_Geometry_EQ.html>`_: retourne TRUE si l'Ã©tendue de A est la mÃªme que celle de B.
 
-`ST_Intersects(geometry_a, geometry_b) <http://postgis.org/docs/ST_Intersects.html>`_: Returns TRUE if the Geometries/Geography "spatially intersect" - (share any portion of space) and FALSE if they don't (they are Disjoint). 
+`ST_Intersects(geometry_a, geometry_b) <http://postgis.org/docs/ST_Intersects.html>`_: retourne TRUE si l'objet Geometrie/Geography "intersecte spatiallement" - (ont une partie en commun) et FALSE sinon (elles sont dijointes). 
 
 .. rubric:: Footnotes
