Index: trunk/workshop-foss4g/indexing.rst
===================================================================
--- trunk/workshop-foss4g/indexing.rst	(revision 47)
+++ trunk/workshop-foss4g/indexing.rst	(revision 62)
@@ -4,11 +4,11 @@
 =================================
 
-Rapellez-vous que l'indexation spatiale est l'une des trois fonctionnalitÃ©s clÃ©s d'une base de donnÃ©es spatiales. Les indexes permettent l'utilisation de grandes quantitÃ©s de donnÃ©es dans une base. Sans l'indexation, chaque recherche d'entitÃ© nÃ©cessitera d'accÃ©der sÃ©quentiellement Ã  tout les enregistrements de la base de donnÃ©es. L'indexation accÃ©lÃšres les recherche en organisant les donnÃ©es dans des arbres de recherche qui peuvent Ãªtre parcouru efficacement pour retrouver une entitÃ© particuliÃšre.
+Rapellez-vous que l'indexation spatiale est l'une des trois fonctionnalitÃ©s clÃ©s d'une base de donnÃ©es spatiales. Les index permettent l'utilisation de grandes quantitÃ©s de donnÃ©es dans une base. Sans l'indexation, chaque recherche d'entitÃ© nÃ©cessitera d'accÃ©der sÃ©quentiellement Ã  tous les enregistrements de la base de donnÃ©es. L'indexation accÃ©lÃšre les recherches en organisant les donnÃ©es dans des arbres de recherche qui peuvent Ãªtre parcourus efficacement pour retrouver une entitÃ© particuliÃšre.
 
-L'indexation spatiale l'un des plus grands atouts de PostGIS. Dans les exemples prÃ©cÃ©dents, nous avons construit nos jointures spatiales en comparant la totalitÃ© des tables. Ceci peut parfois s'averrer trÃšs coÃ»teux : RÃ©aliser la jointure de deux tables de 10000 enregistrements sans indexation nÃ©cessitera de comparer 100000000 valeurs, les comparaisons requises ne seront plus que 20000 avec l'indexation.
+L'indexation spatiale l'un des plus grands atouts de PostGIS. Dans les exemples prÃ©cÃ©dents, nous avons construit nos jointures spatiales en comparant la totalitÃ© des tables. Ceci peut parfois s'avÃ©rer trÃšs coÃ»teux : rÃ©aliser la jointure de deux tables de 10000 enregistrements sans indexation nÃ©cessitera de comparer 100000000 valeurs, les comparaisons requises ne seront plus que 20000 avec l'indexation.
 
-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``.
+Lorsque nous avons chargÃ© la table  ``nyc_census_blocks``, l'outil pgShapeLoader crÃ©e automatiquement un index spatial appelÃ© ``nyc_census_blocks_the_geom_gist``.
 
-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.
+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 index.
 
 La premiÃšre Ã©tape consiste Ã  supprimer l'index.
@@ -17,9 +17,9 @@
 
   DROP INDEX nyc_census_blocks_the_geom_gist;
-  
+
 .. note::
 
    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>`_.
-   
+
 Maintenant, regardons le temps d'exÃ©cution dans le coin en bas Ã  droite de l'interface de requÃªtage de pgAdmin, puis lanÃ§ons la commande suivante. Notre requÃªte recherche les blocs de la rue Broad.
 
@@ -31,12 +31,12 @@
   ON ST_Contains(blocks.the_geom, subways.the_geom)
   WHERE subways.name = 'Broad St';
-  
+
 ::
 
-       blkid      
+       blkid
  -----------------
   360610007003006
-  
-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 l'ordinateur de test.
+
+La table ``nyc_census_blocks`` est trÃšs petite (seulement quelque milliers d'enregistrements) donc mÃªme sans l'index, la requÃªte prends **55 ms** sur l'ordinateur de test.
 
 Maintenant remettons en place l'index et lanÃ§ons de nouveau la requÃªte.
@@ -48,10 +48,10 @@
 .. note:: l'utilisation de la clause ``USING GIST`` spÃ©cifie Ã  PostgreSQL de crÃ©er une structure (GIST) pour cet index. Si vous recevez un message 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``.
 
-Sur l'rdinateur 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 augmentera.
+Sur l'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 index augmentera.
 
-Comment les indexes spatiaux fonctionnent
------------------------------------------
+Comment les index spatiaux fonctionnent
+---------------------------------------
 
-Les indexes des base de donnÃ©es standards crÃ©ent des arbres hierarchiques basÃ©s sur les valeurs des colonnes Ã  indexer. Les indexes spatiaux sont un peu diffÃ©rents - ils ne sont pas capables d'indexer des entitÃ©s gÃ©omÃ©triques elles-mÃªme mais indexe leur Ã©tendues.
+Les index des bases de donnÃ©es standards crÃ©ent des arbres hiÃ©rarchiques basÃ©s sur les valeurs des colonnes Ã  indexer. Les index spatiaux sont un peu diffÃ©rents - ils ne sont pas capables d'indexer des entitÃ©s gÃ©omÃ©triques elles-mÃªme mais ils indexent leur Ã©tendues.
 
 .. image:: ./indexing/bbox.png
@@ -59,7 +59,7 @@
 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 boÃ®te bleue.
 
-La maniÃšre dont les bases de donnÃ©es rÃ©pondent de maniÃšre efficace Ã  la question "Quelles lignes intersectent l'Ã©toile jaune ?" correspond premiÃšrement Ã  rÃ©pondre Ã  la question "Quelle Ã©tendue intersecte l'Ã©tendue jaune" en utilisant les indexes (ce qui est trÃšs rapide) puis Ã  calculer le rÃ©sultat exact de la question "Quelles lignes intersectent l'Ã©toile jaune ?" **seulement en utilisant les entitÃ©s retournÃ© par le premier test**.
+La maniÃšre dont les bases de donnÃ©es rÃ©pondent de maniÃšre efficace Ã  la question "Quelles lignes intersectent l'Ã©toile jaune ?" correspond premiÃšrement Ã  rÃ©pondre Ã  la question "Quelle Ã©tendue intersecte l'Ã©tendue jaune" en utilisant les index (ce qui est trÃšs rapide) puis Ã  calculer le rÃ©sultat exact de la question "Quelles lignes intersectent l'Ã©toile jaune ?" **seulement en utilisant les entitÃ©s retournÃ©es par le premier test**.
 
-Pour de grandes tables, il y a un systÃšme en "deux Ã©tapes" d'Ã©valuation en utilisant dans un premier temps l'approximation Ã  l'aide d'indexes, puis en rÃ©alisant le test exact sur une quantitÃ© bien moins importante de donnÃ©es ce qui rÃ©duit drastiquement le temps de calcul nÃ©cessaire Ã  cette deuxiÃšme Ã©tape.
+Pour de grandes tables, il y a un systÃšme en "deux Ã©tapes" d'Ã©valuation en utilisant dans un premier temps l'approximation Ã  l'aide d'index, puis en rÃ©alisant le test exact sur une quantitÃ© bien moins importante de donnÃ©es ce qui rÃ©duit drastiquement le temps de calcul nÃ©cessaire Ã  cette deuxiÃšme Ã©tape.
 
 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.
@@ -67,66 +67,66 @@
 .. image:: ./indexing/index-01.png
 
-RequÃªte avec seulement des indexes
-----------------------------------
+RequÃªte avec seulement des index
+--------------------------------
 
-La plupart des fonctions utilisÃ©es par PostGIS (:command:`ST_Contains`, :command:`ST_Intersects`, :command:`ST_DWithin`, etc) prennent en compte les indexes automatiquement. Mais certaines fonctions (comme par exemple : :command:`ST_Relate`) ne les utilisent pas.
+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.
 
-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 signifie que les valeurs sont Ã©gales.
+Pour utiliser une recherche par Ã©tendue utilisant les index (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 signifie que les valeurs sont Ã©gales.
 
-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 Ã  cela :
+Essayons de comparer une requÃªte avec seulement un index pour la population du quartier 'West Village'. En utilisant la commande :command:`&&` notre requÃªte ressemble Ã  cela :
 
 .. code-block:: sql
 
-  SELECT Sum(popn_total) 
+  SELECT Sum(popn_total)
   FROM nyc_neighborhoods neighborhoods
   JOIN nyc_census_blocks blocks
   ON neighborhoods.the_geom && blocks.the_geom
   WHERE neighborhoods.name = 'West Village';
-  
+
 ::
 
   50325
-  
+
 Maintenant essayons la mÃªme requÃªte en utilisant la fonction plus prÃ©cise :command:`ST_Intersects`.
 
 .. code-block:: sql
 
-  SELECT Sum(popn_total) 
+  SELECT Sum(popn_total)
   FROM nyc_neighborhoods neighborhoods
   JOIN nyc_census_blocks blocks
   ON ST_Intersects(neighborhoods.the_geom, blocks.the_geom)
   WHERE neighborhoods.name = 'West Village';
-  
+
 ::
 
   27141
 
-Un plus faible nombre de rÃ©sultats ! La premiÃšre requÃªte nous renvoit tout les blocs qui intersectent l'Ã©tendue du quartier, la seconde nous renvoit seulement les blocs qui intersectent le quartier lui-mÃªme.
+Un plus faible nombre de rÃ©sultats ! La premiÃšre requÃªte nous renvoie tous les blocs qui intersectent l'Ã©tendue du quartier, la seconde nous renvoie seulement les blocs qui intersectent le quartier lui-mÃªme.
 
 Analyse
 ---------
 
-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.
+Le planificateur de requÃªte de PostgreSQL choisit intelligemment d'utiliser ou non les index 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.
 
-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 le contenu de vos tables dans une pÃ©riode courte, les statisuqes ne seront alors plus Ã  jour.
+Afin de savoir dans quelle situation il est nÃ©cessaire d'utiliser les index (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Ã©anmoins, si vous changez dramatiquement le contenu de vos tables dans une pÃ©riode courte, les statistiques ne seront alors plus Ã  jour.
 
-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Ã©es. Cela force le systÃšme de gestion des statistiques Ã  rÃ©cupÃ©rer l'ensemble des donnÃ©es des colonnes indexÃ©es.
+Pour vous assurez que les statistiques correspondent bien au contenu de la table actuelle, il est courant d'utiliser la commande ``ANALYZE`` aprÃšs un grand nombre de modifications ou de suppression de vos donnÃ©es. Cela force le systÃšme de gestion des statistiques Ã  rÃ©cupÃ©rer l'ensemble des donnÃ©es des colonnes indexÃ©es.
 
-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).
+La commande ``ANALYZE`` demande Ã  PostgreSQL de parcourir la table et de mettre Ã  jour les statistiques utilisÃ©es par le planificateur de requÃªtes (la planification des requÃªtes sera traitÃ© ultÃ©rieurement).
 
 .. code-block:: sql
 
    ANALYZE nyc_census_blocks;
-   
+
 NÃ©ttoyage
 ---------
 
-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.
+Il est souvent stressant de constater que la simple crÃ©ation d'un index n'est pas suffisant pour que PostgreSQL l'utilise efficacement. Le nettoyage doit Ãªtre rÃ©alisÃ© aprÃšs qu'un index soit crÃ©Ã© ou aprÃšs un grand nombre de requÃªtes UDATE, INSERT ou DELETE ait Ã©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Ã©es en l'Ã©tat lors des requÃªtes UPDATE ou DELETE Ã  cause du modÃšle d'estampillage multi-versions.
 
 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".
 
-ActivÃ©e par dÃ©faut, le processus autovacuum nettoie (rÃ©cupÃšre l'espace libre) et analyse (met Ã  jour les statistiques) vos tables suivant un interval donnÃ© dÃ©terminÃ© par l'activitÃ© des bases de donnÃ©es. Bien que cela fonctionne avec 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.
+ActivÃ©e par dÃ©faut, le processus autovacuum nettoie (rÃ©cupÃšre l'espace libre) et analyse (met Ã  jour les statistiques) vos tables suivant un intervalle donnÃ© dÃ©terminÃ© par l'activitÃ© des bases de donnÃ©es. Bien que cela fonctionne avec 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.
 
-Le nettoyage et l'analyse de la base de donnÃ©es peut Ãªtre rÃ©alisÃ© 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Ã©e sur l'intÃ©gralitÃ© de la base de donnÃ©es, sur une table ou sur une seule colonne.
+Le nettoyage et l'analyse de la base de donnÃ©es peuvent Ãªtre rÃ©alisÃ©s 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Ã©e sur l'intÃ©gralitÃ© de la base de donnÃ©es, sur une table ou sur une seule colonne.
 
 .. code-block:: sql
@@ -137,11 +137,11 @@
 -------------------
 
-`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_Overlap.html>`_: retourne TRUE si l'Ã©tendue de A chevauche celle de B.
 
 `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>`_: retourne TRUE si l'objet Geometrie/Geography "intersecte spatiallement" - (ont une partie en commun) et FALSE sinon (elles sont dijointes). 
+`ST_Intersects(geometry_a, geometry_b) <http://postgis.org/docs/ST_Intersects.html>`_: retourne TRUE si la gÃ©omÃ©trie *a* "intersecte spatialement" la gÃ©omÃ©trie '*b*- (si elles ont une partie en commun) et FALSE sinon (elles sont disjointes).
 
-.. rubric:: Footnotes
+.. rubric:: Notes de bas de page
 
 .. [#RTree] http://postgis.org/support/rtree.pdf
