Index: trunk/workshop-foss4g/geography.rst
===================================================================
--- trunk/workshop-foss4g/geography.rst	(revision 53)
+++ trunk/workshop-foss4g/geography.rst	(revision 62)
@@ -4,13 +4,13 @@
 =====================================
 
-Il est trÃšs frÃ©quent de manipuler des donnÃ©es Ã  coordonnÃ©es "gÃ©ographiques" ou de "longitude/latitude". 
-
-Au contraire des coordonnÃ©es de type Mercator, UTM ou Stateplane, les coordonnÃ©es gÃ©ographiques ne reprÃ©sentent pas une distance linÃ©aire depuis une origine, tel que dans un plan. Elles dÃ©crivent la distance angulaire entre l'Ã©quateur et les pÃŽles. Dans les sytÃšmes de coordonnÃ©es sphÃ©riques, un point est spÃ©cifiÃ© par son rayon (distance Ã  l'origine), son angle de rotation par rapport au mÃ©ridien plan, et son angle par rapport Ã  l'axe pÃŽlaire. 
+Il est trÃšs frÃ©quent de manipuler des donnÃ©es Ã  coordonnÃ©es "gÃ©ographiques" ou de "longitude/latitude".
+
+Au contraire des coordonnÃ©es de type Mercator, UTM ou Stateplane, les coordonnÃ©es gÃ©ographiques ne reprÃ©sentent pas une distance linÃ©aire depuis une origine, tel que dans un plan. Elles dÃ©crivent la distance angulaire entre l'Ã©quateur et les pÃŽles. Dans les sytÃšmes de coordonnÃ©es sphÃ©riques, un point est spÃ©cifiÃ© par son rayon (distance Ã  l'origine), son angle de rotation par rapport au mÃ©ridien plan, et son angle par rapport Ã  l'axe pÃŽlaire.
 
 .. image:: ./geography/cartesian_spherical.jpg
 
 
-Vous pouvez continuer Ã  utiliser des coordonnÃ©es gÃ©ographiques comme des coordonnÃ©es cartÃ©siennes approximatives pour vos analyses spatiales. Par contre les mesures de distances, d'aires et de longueur seront Ã©ronÃ©es. Etant donnÃ© que les coordonnÃ©es spÃ©riques mesurent des angles, l'unitÃ© est le dÃ©grÃ©. Par exemple, les rÃ©sultats cartÃ©sien approximatifs de tests tels que 'intersects' et 'contains' peuvent s'avÃ©rer terriblement faux. Par ailleurs, plus une zone est situÃ©e prÃšs du pÃŽle ou de la ligne de date internationale, plus la distance entre les points est agrandie.  
- 
+Vous pouvez continuer Ã  utiliser des coordonnÃ©es gÃ©ographiques comme des coordonnÃ©es cartÃ©siennes approximatives pour vos analyses spatiales. Par contre les mesures de distances, d'aires et de longueurs seront erronÃ©es. Etant donnÃ© que les coordonnÃ©es sphÃ©riques mesurent des angles, l'unitÃ© est le degrÃ©. Par exemple, les rÃ©sultats cartÃ©sien approximatifs de tests tels que 'intersects' et 'contains' peuvent s'avÃ©rer terriblement faux. Par ailleurs, plus une zone est situÃ©e prÃšs du pÃŽle ou de la ligne de date internationale, plus la distance entre les points est agrandie.
+
 
 Voici par exemple les coordonnÃ©es des villes de Los Angeles et Paris.
@@ -18,6 +18,6 @@
  * Los Angeles: ``POINT(-118.4079 33.9434)``
  * Paris: ``POINT(2.3490 48.8533)``
- 
-La requÃªte suivante calcule la distance entre Los Angeles et Paris en utilisant le systÃšme cartÃ©sien standard de PostGIS :command:`ST_Distance(geometry, geometry)`.  Notez que le SRID 4326 dÃ©clare un systÃšme de rÃ©fÃ©rences spatiales gÃ©ographiques.
+
+La requÃªte suivante calcule la distance entre Los Angeles et Paris en utilisant le systÃšme cartÃ©sien standard de PostGIS :command:`ST_Distance(geometry, geometry)`.  Notez que le SRID 4326 dÃ©clare un systÃšme de rÃ©fÃ©rence spatiale gÃ©ographique.
 
 .. code-block:: sql
@@ -31,10 +31,10 @@
 
   121.898285970107
-  
-Aha! 121! Mais, que veut dire cela ? 
-
-L'unitÃ© pour SRID 4326 est le degrÃ©. Donc la rÃ©ponse signifie 121 degrÃ©s. Sur une sphÃšre, la taille d'un degrÃ© "au carrÃ©" est assez variable. Elle devient plsu petite au fur et Ã  mesure que l'on s'Ã©loigne de l'Ã©quateur. Pensez par exemple aux mÃ©ridiens sur le globe qui se ressÃšrent entre eux au niveau des pÃŽles. Donc une distance de 121 degrÃ©s ne veut rien dire !
-
-Pour calculer une distance ayant du sens, nous devons traiter les coordonnÃ©es gÃ©ographiques non pas come des coordonnÃ©es cartÃ©siennes approximatives, mais plutÃŽt comme de rÃ©elles coordonnÃ©es sphÃ©riques. Nous devons mesurer les distances entre les points comme de vrais chemins par dessus uen sphÃšre, comme une portion d'un grand cercle.
+
+Aha! 121! Mais, que veut dire cela ?
+
+L'unitÃ© pour SRID 4326 est le degrÃ©. Donc la rÃ©ponse signifie 121 degrÃ©s. Sur une sphÃšre, la taille d'un degrÃ© "au carrÃ©" est assez variable. Elle devient plus petite au fur et Ã  mesure que l'on s'Ã©loigne de l'Ã©quateur. Pensez par exemple aux mÃ©ridiens sur le globe qui se resserrent entre eux au niveau des pÃŽles. Donc une distance de 121 degrÃ©s ne veut rien dire !
+
+Pour calculer une distance ayant du sens, nous devons traiter les coordonnÃ©es gÃ©ographiques non pas comme des coordonnÃ©es cartÃ©siennes approximatives, mais plutÃŽt comme de rÃ©elles coordonnÃ©es sphÃ©riques. Nous devons mesurer les distances entre les points comme de vrais chemins par dessus une sphÃšre, comme une portion d'un grand cercle.
 
 Depuis sa version 1.5, PostGIS fournit cette fonctionnalitÃ© avec le type ``geography``.
@@ -43,11 +43,11 @@
 
   DiffÃ©rentes bases de donnÃ©es spatiales dÃ©veloppent diffÃ©rentes approches pour manipuler les coordonnÃ©es gÃ©ographiques.
-  
-  * Oracle essaye de mettre Ã  jour la diffÃ©rence de maniÃšre transparente en lanacant des calculs lorsuqe le SRID est gÃ©ographique.
-  * SQL Server utilise deux types spatiaux, "STGeometry" pour les coordonnÃ©es cartÃ©siens et STGeography" pour les coordonnÃ©es gÃ©ographqiues. 
-  * Informix Spatial est une pure extension cartÃ©sienne d'Informix, alors qu'Informix Geodetic est une pure extension gÃ©ographique. 
+
+  * Oracle essaye de mettre Ã  jour la diffÃ©rence de maniÃšre transparente en lanÃ§ant des calculs lorsque le SRID est gÃ©ographique.
+  * SQL Server utilise deux types spatiaux, "STGeometry" pour les coordonnÃ©es cartÃ©siens et STGeography" pour les coordonnÃ©es gÃ©ographqiues.
+  * Informix Spatial est une pure extension cartÃ©sienne d'Informix, alors qu'Informix Geodetic est une pure extension gÃ©ographique.
   * Comme SQL Server, PostGIS utilise deux types: "geometry" et "geography".
-  
-En utilisant le type ``geography`` plutot que ``geometry``, essayon sÃ  nouveau de mesurer la distance entre Los Angeles et Paris. Au lieu de la commande :command:`ST_GeometryFromText(text)`, nous utiliserons cette fois :command:`ST_GeographyFromText(text)`.
+
+En utilisant le type ``geography`` plutot que ``geometry``, essayons sÃ  nouveau de mesurer la distance entre Los Angeles et Paris. Au lieu de la commande :command:`ST_GeometryFromText(text)`, nous utiliserons cette fois :command:`ST_GeographyFromText(text)`.
 
 .. code-block:: sql
@@ -66,9 +66,9 @@
 Les versions plus anciennes de PostGIS supportaient uniquement des calculs sur sphÃšre trÃšs basiques comme la fonction :command:`ST_Distance_Spheroid(point, point, measurement)`. Celle-ci est trÃšs limitÃ©e et ne fonctionne uniquement sur des  points. Elle ne supporte pas non plus l'indexation au niveau des pÃŽles ou de la ligne de date internationale.
 
-Le besoin du support des autres types de gÃ©omÃ©tries se fit ressentir lorsqu'il s'agissait de rÃ©pondre Ã  des questions du type  "A quelle distance la ligne de vol d'un avion Los Angeles/Paris passe-t-elle de l'Islande?" 
+Le besoin du support des autres types de gÃ©omÃ©tries se fit ressentir lorsqu'il s'agissait de rÃ©pondre Ã  des questions du type  "A quelle distance la ligne de vol d'un avion Los Angeles/Paris passe-t-elle de l'Islande?"
 
 .. image:: ./geography/lax_cdg.jpg
 
-RÃ©pondre Ã  cette question en travaillant avec un plan cartÃ©sien fournit une trÃšs mauvaise rÃ©ponse en effet ! En utilisant la ligne rouge, nou sobtenon sune bien meilleure rÃ©ponse. Si nous convertissons notre vol LAX-CDG en une ligne et que nous calculons la distance Ã  un point en Islande, nous obtiendrons la rÃ©ponse exacte, en mÃštres. 
+RÃ©pondre Ã  cette question en travaillant avec un plan cartÃ©sien fournit une trÃšs mauvaise rÃ©ponse en effet ! En utilisant la ligne rouge, nous obtenons une bien meilleure rÃ©ponse. Si nous convertissons notre vol LAX-CDG en une ligne et que nous calculons la distance Ã  un point en Islande, nous obtiendrons la rÃ©ponse exacte, en mÃštres.
 
 .. code-block:: sql
@@ -76,5 +76,5 @@
   SELECT ST_Distance(
     ST_GeographyFromText('LINESTRING(-118.4079 33.9434, 2.5559 49.0083)'), -- LAX-CDG
-    ST_GeographyFromText('POINT(-21.8628 64.1286)')                        -- Iceland  
+    ST_GeographyFromText('POINT(-21.8628 64.1286)')                        -- Iceland
   );
 
@@ -82,8 +82,8 @@
 
   531773.757079116
-  
-Donc le point le plu sproche de l'Islande pendant le vol LAX-CDG est de 532 kilomÃštres.S
-
-L'approche cartÃ©sienne pour manipuler les coordonnÃ©es gÃ©ographiques pert tout son sens pour les objets situÃ©es au dessus de la ligne de date internationale. La route "sphÃ©rique" la plus courte entre Los-Angeles et Tokyo traverse l'ocÃ©an Pacifique. La route "cartÃ©sienne" la plus courte traverse quant Ã  elle les ocÃ©ans Atlantique et Indien.  
+
+Donc le point le plus proche de l'Islande pendant le vol LAX-CDG est de 532 kilomÃštres.
+
+L'approche cartÃ©sienne pour manipuler les coordonnÃ©es gÃ©ographiques perd tout son sens pour les objets situÃ©s au dessus de la ligne de date internationale. La route "sphÃ©rique" la plus courte entre Los-Angeles et Tokyo traverse l'ocÃ©an Pacifique. La route "cartÃ©sienne" la plus courte traverse quant Ã  elle les ocÃ©ans Atlantique et Indien.
 
 .. image:: ./geography/lax_nrt.png
@@ -94,13 +94,13 @@
      ST_GeometryFromText('Point(-118.4079 33.9434)'),  -- LAX
      ST_GeometryFromText('Point(139.733 35.567)'))     -- NRT (Tokyo/Narita)
-       AS geometry_distance, 
+       AS geometry_distance,
    ST_Distance(
      ST_GeographyFromText('Point(-118.4079 33.9434)'), -- LAX
-     ST_GeographyFromText('Point(139.733 35.567)'))    -- NRT (Tokyo/Narita) 
-       AS geography_distance; 
-    
-::
-
-   geometry_distance | geography_distance 
+     ST_GeographyFromText('Point(139.733 35.567)'))    -- NRT (Tokyo/Narita)
+       AS geography_distance;
+
+::
+
+   geometry_distance | geography_distance
   -------------------+--------------------
     258.146005837336 |   8833954.76996256
@@ -110,26 +110,26 @@
 ----------------------------
 
-Afin d'importer des donnÃ©es dans une table de type geography, les objets gÃ©ographiques doivent d'avord Ãªtre projetÃ©es dans le systÃšme EPSG:4326 (longitude/latitude), ensuite elles doivent Ãªtre converties en objets de type gÃ©ographies. La fonction :command:`ST_Transform(geometry,srid)` convertie les coordonnÃ©es en gÃ©ographies et la fonction :command:`Geography(geometry)` change le type ("cast") de gÃ©omÃ©trie Ã  gÃ©ographie.
+Afin d'importer des donnÃ©es dans une table de type ``geography``, les objets gÃ©ographiques doivent d'abord Ãªtre projetÃ©s dans le systÃšme EPSG:4326 (longitude/latitude), ensuite ils doivent Ãªtre convertis en objets de type ``geography``. La fonction :command:`ST_Transform(geometry,srid)` convertit les coordonnÃ©es en ``geography`` et la fonction :command:`Geography(geometry)` change le type ("cast") de gÃ©omÃ©trie Ã  gÃ©ographie.
 
 .. code-block:: sql
 
   CREATE TABLE nyc_subway_stations_geog AS
-  SELECT 
-    Geography(ST_Transform(the_geom,4326)) AS geog, 
-    name, 
+  SELECT
+    Geography(ST_Transform(the_geom,4326)) AS geog,
+    name,
     routes
   FROM nyc_subway_stations;
-   
-La construction d'une indexation spatiale sur une table stockant des objets de type gÃ©ographie est exactement identique Ã  la mÃ©thode employÃ©e pour les gÃ©omÃ©tries :   
-
-.. code-block:: sql
-
-  CREATE INDEX nyc_subway_stations_geog_gix 
+
+La construction d'une indexation spatiale sur une table stockant des objets de type ``geography`` est exactement identique Ã  la mÃ©thode employÃ©e pour les gÃ©omÃ©tries :
+
+.. code-block:: sql
+
+  CREATE INDEX nyc_subway_stations_geog_gix
   ON nyc_subway_stations_geog USING GIST (geog);
 
-La diffÃ©rence est camouflÃ© : l'indexation des objets de type gÃ©ographie gÃ©re correctement les requÃªtes qui recouvrent les pÃŽles ou traverses les fuseaux horraires, alors que les gÃ©omÃ©tries ne le supporteront pas.
-
-Il n'y a qu'un petit nombre de fonctions disponibles pour le type gÃ©ographie :  
- 
+La diffÃ©rence est camouflÃ©e : l'indexation des objets de type ``geography`` gÃšre correctement les requÃªtes qui recouvrent les pÃŽles ou traversent les fuseaux horaires, alors que les gÃ©omÃ©tries ne le supporteront pas.
+
+Il n'y a qu'un petit nombre de fonctions disponibles pour le type ``geography`` :
+
  * :command:`ST_AsText(geography)` retourne la reprÃ©sentation ``textuelle``
  * :command:`ST_GeographyFromText(text)` retourne un objet de type ``geography``
@@ -149,9 +149,9 @@
  * :command:`ST_Buffer(geography, float8)` retourne ``geography`` [#Casting_note]_
  * :command:`ST_Intersection(geography, geography)` retourne ``geography`` [#Casting_note]_
- 
-CrÃ©ation d'une table stockant des gÃ©ograhpies
+
+CrÃ©ation d'une table stockant des gÃ©ographies
 ---------------------------------------------
- 
-Le code SQL permettant la crÃ©ation d'une nouvelle table avec une colonne de type gÃ©ographie ressemble Ã  la crÃ©ation d'une table stockant des gÃ©omÃ©tries. Cependant, les objets de type gÃ©ographie permettent de spÃ©cifier directement le type d'objet gÃ©ographique Ã  la crÃ©ation de la table. Par exemple :
+
+Le code SQL permettant la crÃ©ation d'une nouvelle table avec une colonne de type ``geography`` ressemble Ã  la crÃ©ation d'une table stockant des gÃ©omÃ©tries. Cependant, les objets de type ``geography`` permettent de spÃ©cifier directement le type d'objet gÃ©ographique Ã  la crÃ©ation de la table. Par exemple :
 
 .. code-block:: sql
@@ -161,34 +161,34 @@
     geog GEOGRAPHY(Point)
   );
-  
+
   INSERT INTO airports VALUES ('LAX', 'POINT(-118.4079 33.9434)');
   INSERT INTO airports VALUES ('CDG', 'POINT(2.5559 49.0083)');
   INSERT INTO airports VALUES ('REK', 'POINT(-21.8628 64.1286)');
-  
-Lors de la dÃ©finitionn le type ``GEOGRAPHY(Point)`` spÃ©cifie que nos airoports sont des points. Les nouveau champs gÃ©ographie n'est pas rÃ©fÃ©rencÃ© dans la table ``geometry_columns``. Le stockage des mÃ©tadonnÃ©es relatives aux donnÃ©es de type gÃ©ograhpie sont stockÃ©es dans une vue appellÃ©e ``geography_columns`` qui est maintenue Ã  jour automatiquement sans avoir besoin d'utiliser des fonctions comme ``geography_columns``.
+
+Lors de la dÃ©finition le type ``GEOGRAPHY(Point)`` spÃ©cifie que nos aÃ©roports sont des points. Le nouveau champ gÃ©ographie n'est pas rÃ©fÃ©rencÃ© dans la table ``geometry_columns``. Le stockage des mÃ©tadonnÃ©es relatives aux donnÃ©es de type ``geography`` s'effectue dans une vue appelÃ©e ``geography_columns`` qui est maintenue Ã  jour automatiquement sans avoir besoin d'utiliser des fonctions comme ``geography_columns``.
 
 .. code-block:: sql
 
   SELECT * FROM geography_columns;
-  
-::
-
-           f_table_name         | f_geography_column | srid |   type   
+
+::
+
+           f_table_name         | f_geography_column | srid |   type
  -------------------------------+--------------------+------+----------
   nyc_subway_stations_geography | geog               |    0 | Geometry
   airports                      | geog               | 4326 | Point
-  
+
 .. note::
 
-  La possibilitÃ© de dÃ©finir les types et le SRID lors de la crÃ©ation de la table (requÃªte ``CREATE``), et la mise Ã  jour automatique des mÃ©tadonnÃ©es ``geometry_columns`` sont des fonctionalitÃ©s qui seront adaptÃ©es pour le type gÃ©omÃ©trie pour la version 2.0 de PostGIS.  
+  La possibilitÃ© de dÃ©finir les types et le SRID lors de la crÃ©ation de la table (requÃªte ``CREATE``), et la mise Ã  jour automatique des mÃ©tadonnÃ©es ``geometry_columns`` sont des fonctionalitÃ©s qui seront adaptÃ©es pour le type gÃ©omÃ©trie pour la version 2.0 de PostGIS.
 
 Conversion de type
 -------------------
 
-Bien que les fonctions de bases qui s'appliquent au type gÃ©ographie peuvent Ãªtre utilisÃ©es dans un grand nombre de cas d'utilisation, il est parfois nÃ©cessaire d'accÃ©der aux autres fonctions qui ne supportent que le type gÃ©omÃ©trie. Heureusement, il est possible de convertir des objets de type gÃ©omÃ©tries en des objets de types gÃ©ographies et inversement.
-
-La syntaxe habituelle de PostgreSQL pour les conversion de type  consiste Ã  ajouter Ã  la valeur la chaÃ®ne suivante ``::typename``. Donc, ``2::text`` convertie la valeur numÃ©rique deux en une chaÃ®ne de caractÃšres '2'. La commande : ``'POINT(0 0)'::geometry`` convertira la reprÃ©sentation textuelle d'un point en une point gÃ©omÃ©trique.
-
-La fonction :command:`ST_X(point)` supporte seulement le type gÃ©omÃ©trique. Comment lire la coordonÃ©e X d'une de nos gÃ©ographie ?
+Bien que les fonctions de base qui s'appliquent au type ``geography`` puissent Ãªtre utilisÃ©es dans un grand nombre de cas d'utilisation, il est parfois nÃ©cessaire d'accÃ©der aux autres fonctions qui ne supportent que le type gÃ©omÃ©trie. Heureusement, il est possible de convertir des objets de type gÃ©omÃ©trie en des objets de types gÃ©ographie et inversement.
+
+La syntaxe habituelle de PostgreSQL pour les conversion de type  consiste Ã  ajouter Ã  la valeur la chaÃ®ne suivante ``::typename``. Donc, ``2::text`` convertit la valeur numÃ©rique deux en une chaÃ®ne de caractÃšres '2'. La commande : ``'POINT(0 0)'::geometry`` convertira la reprÃ©sentation textuelle d'un point en une point gÃ©omÃ©trique.
+
+La fonction :command:`ST_X(point)` supporte seulement le type gÃ©omÃ©trique. Comment lire la coordonnÃ©e X d'une de nos gÃ©ographie ?
 
 .. code-block:: sql
@@ -198,43 +198,43 @@
 ::
 
-  code | longitude 
+  code | longitude
  ------+-----------
-  LAX  | -118.4079 
+  LAX  | -118.4079
   CDG  |    2.5559
   REK  |  -21.8628
 
-En ajoutant la chaÃ®ne ``::geometry`` Ã  notre valeur gÃ©ographique, nous la convertissons en une gÃ©ographie ayant le SRID : 4326. Ã partir de maintenant, nous pouvons utiliser autemps de fonctions s'appliquant au gÃ©omÃ©tries que nous le souhaitons. Mais, souvenez-vous - maintenant que nos objets sont des gÃ©omÃ©tries, leur coordonnÃ©es seront interprÃ©tÃ©es comme des coordonnÃ©es cartÃ©siennes, non pas sphÃ©riques.
- 
- 
+En ajoutant la chaÃ®ne ``::geometry`` Ã  notre valeur gÃ©ographique, nous la convertissons en une gÃ©ographie ayant le SRID : 4326. Ã partir de maintenant, nous pouvons utiliser autant de fonctions s'appliquant aux gÃ©omÃ©tries que nous le souhaitons. Mais, souvenez-vous - maintenant que nos objets sont des gÃ©omÃ©tries, leur coordonnÃ©es seront interprÃ©tÃ©es comme des coordonnÃ©es cartÃ©siennes, non pas sphÃ©riques.
+
+
 Pourquoi (ne pas) utiliser les gÃ©ographies
 ------------------------------------------
 
-Les gÃ©ographies ont des coordonnÃ©es universellement acceptÃ©es - chacun peut comprendre que reprÃ©sente la latitue et la longitude, mais peut de personne comprennent ce que les coordonnÃ©es UTM signifient. Pourquoi ne pas tout le temps utiliser  des gÃ©ographies ?
-
- * PremiÃšrement, comme indiquÃ© prÃ©cÃ©demment, il n'y a que quelques fonctions qui supportent ce type de donnÃ©es. Vous risquer de perdre beaucoup de temps Ã  contourner les problÃšmes liÃ©s Ã  la non-disponibilitÃ© de certaines fonctions.
- * DeuxiÃšmement, les calculs sur une sphÃšre sont plus consomateurs en ressource que les mÃªmes calculs dans un systÃšme cartÃ©sien. Par exemple, la formule de calcul de distance (Pythagore) entraine un seul appÃšle Ã  la fonction racine carrÃ© (sqrt()). La formule de calcul de distance sphÃ©rique (Haversine) utilise deux appÃšle Ã  la fonction racine carrÃ©, et un appÃšle Ã  arctan(), quatre appÃšle Ã  sin() et deux Ã  cos(). Les fonctions trigonomÃ©triques sont trÃšs couteuses, et les calculs sphÃ©riques les utilisent massivement.
- 
-Quel conclusion en tirer ? 
-
-Si vos donnÃ©es sont gÃ©ograhpiquement compact (contenu Ã  l'intÃ©rieur d'un Ã©tat, d'un pays ou d'une ville), utilisez le type ``geometry`` avec une projection cartÃ©sienne qui est pertinent pour votre localisation. Consultez le site http://spatialreference.org et tapez le nom de votre rÃ©gion pour visualiser la liste des systÃšme de projection applicables dans votre cas.
-
-Si, d'un autre cotÃ©, vous avez besoin de calculer des distances qui est gÃ©ographiquement Ã©parse (recouvrant la plupart du monde), utiliser le type ``geography``. La complÃ©xitÃ© de l'application que vous Ã©viterait en travaillant avec des objets de type ``geography`` dÃ©passera les problÃšmes de performances. La conversion de type  en gÃ©omÃ©trie permettra de dÃ©passer les limites des fonctionnalitÃ©s proposÃ© pour ce type.
+Les gÃ©ographies ont des coordonnÃ©es universellement acceptÃ©es - chacun peut comprendre que reprÃ©sente la latitude et la longitude, mais peu de personne comprennent ce que les coordonnÃ©es UTM signifient. Pourquoi ne pas tout le temps utiliser des gÃ©ographies ?
+
+ * PremiÃšrement, comme indiquÃ© prÃ©cÃ©demment, il n'y a que quelques fonctions qui supportent ce type de donnÃ©es. Vous risquez de perdre beaucoup de temps Ã  contourner les problÃšmes liÃ©s Ã  la non-disponibilitÃ© de certaines fonctions.
+ * DeuxiÃšmement, les calculs sur une sphÃšre sont plus consomateurs en ressource que les mÃªmes calculs dans un systÃšme cartÃ©sien. Par exemple, la formule de calcul de distance (Pythagore) entraÃ®ne un seul appel Ã  la fonction racine carrÃ© (sqrt()). La formule de calcul de distance sphÃ©rique (Haversine) utilise deux appels Ã  la fonction racine carrÃ©, et un appel Ã  arctan(), quatre appels Ã  sin() et deux Ã  cos(). Les fonctions trigonomÃ©triques sont trÃšs coÃ»teuses, et les calculs sphÃ©riques les utilisent massivement.
+
+Quel conclusion en tirer ?
+
+Si vos donnÃ©es sont gÃ©ographiquement compactes (contenu Ã  l'intÃ©rieur d'un Ã©tat, d'un pays ou d'une ville), utilisez le type ``geometry`` avec une projection cartÃ©sienne qui est pertinente pour votre localisation. Consultez le site http://spatialreference.org et tapez le nom de votre rÃ©gion pour visualiser la liste des systÃšmes de projection applicables dans votre cas.
+
+Si, d'un autre cotÃ©, vous avez besoin de calculer des distances qui sont gÃ©ographiquement Ã©parses (recouvrant la plupart du monde), utilisez le type ``geography``. La complexitÃ© de l'application Ã©vitÃ©e en travaillant avec des objets de type ``geography`` dÃ©passera les problÃšmes de performances. La conversion de type en gÃ©omÃ©trie permettra de dÃ©passer les limites des fonctionnalitÃ©s proposÃ©es pour ce type.
 
 Liste des fonctions
 -------------------
 
-`ST_Distance(geometry, geometry) <http://postgis.org/docs/ST_Distance.html>`_: Pour le type gÃ©omÃ©trie, renvoit la distance cartÃ©sienne, pour les gÃ©ographies la distance sphÃ©rique en mÃ©tres.
+`ST_Distance(geometry, geometry) <http://postgis.org/docs/ST_Distance.html>`_: Pour le type gÃ©omÃ©trie, renvoie la distance cartÃ©sienne, pour les gÃ©ographies la distance sphÃ©rique en mÃštres.
 
 `ST_GeographyFromText(text) <http://postgis.org/docs/ST_GeographyFromText.html>`_: Retourne la valeur gÃ©ographique Ã  partir d'une reprÃ©sentation en WKT ou EWKT.
 
-`ST_Transform(geometry, srid) <http://postgis.org/docs/ST_Transform.html>`_: Retourne une nouvelle gÃ©omÃ©trie avec ses coordonnÃ©es reprojetÃ©es dans le systÃšme de rÃ©fÃ©rence spatial rÃ©fÃ©rencÃ© par le SRID fournit.
+`ST_Transform(geometry, srid) <http://postgis.org/docs/ST_Transform.html>`_: Retourne une nouvelle gÃ©omÃ©trie avec ses coordonnÃ©es reprojetÃ©es dans le systÃšme de rÃ©fÃ©rence spatial rÃ©fÃ©rencÃ© par le SRID fourni.
 
 `ST_X(point) <http://postgis.org/docs/ST_X.html>`_: Retourne la coordonnÃ©e X d'un point, ou NULL si non disponible. La valeur passÃ©e doit Ãªtre un point.
 
 
-.. rubric:: Footnotes
-
-.. [#Casting_note] Les fonctions buffer et intersection sont actuellement construite sur le principe de conversion de type en gÃ©omÃ©tries, et ne sont pas actuellement capable de gÃ©rer des coordonnÃ©es sphariques. Il en rÃ©sulte qu'elles peuvent ne pas parvenir Ã  retourner un rÃ©sultat correcte pour des objets ayant une grande Ã©tendue qui ne peut Ãªtre reprÃ©sentÃ© correctement avec une reprÃ©sentation planaire.
- 
-   Par exemple, la fonction :command:`ST_Buffer(geography,distance)`  transforme les objets gÃ©ographiques dans la "meilleure" projection, crÃ©e la zone tampon, puis les transforme Ã  nouveau en des gÃ©ographies. S'il n'y a pas de "meilleure" projection (l'objet est trop vaste), l'opÃ©ration peut ne pas rÃ©ussir Ã  retourner une valeur correct ou retourner une one tampon mal formÃ©e.
-
+.. rubric:: Notes de bas de page
+
+.. [#Casting_note] Les fonctions buffer et intersection sont actuellement construites sur le principe de conversion de type en gÃ©omÃ©tries, et ne sont pas actuellement capable de gÃ©rer des coordonnÃ©es sphÃ©riques. Il en rÃ©sulte qu'elles peuvent ne pas parvenir Ã  retourner un rÃ©sultat correcte pour des objets ayant une grande Ã©tendue qui ne peut Ãªtre reprÃ©sentÃ© correctement avec une reprÃ©sentation planaire.
+
+   Par exemple, la fonction :command:`ST_Buffer(geography,distance)`  transforme les objets gÃ©ographiques dans la "meilleure" projection, crÃ©e la zone tampon, puis les transforme Ã  nouveau en des gÃ©ographies. S'il n'y a pas de "meilleure" projection (l'objet est trop vaste), l'opÃ©ration peut ne pas rÃ©ussir Ã  retourner une valeur correcte ou retourner un tampon mal formÃ©.
+
