Index: /trunk/workshop-foss4g/geography.rst
===================================================================
--- /trunk/workshop-foss4g/geography.rst	(revision 50)
+++ /trunk/workshop-foss4g/geography.rst	(revision 51)
@@ -107,8 +107,8 @@
 
 
-Utiliser 'Geography'
--------------------
-
-In order to load geometry data into a geography table, the geometry first needs to be projected into EPSG:4326 (longitude/latitude), then it needs to be changed into geography.  The :command:`ST_Transform(geometry,srid)` function converts coordinates to geographics and the :command:`Geography(geometry)` function "casts" them from geometry to geography.
+Utiliser le type 'Geography'
+----------------------------
+
+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.
 
 .. code-block:: sql
@@ -121,5 +121,5 @@
   FROM nyc_subway_stations;
    
-Building a spatial index on a geography table is exactly the same as for geometry:
+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
@@ -128,30 +128,30 @@
   ON nyc_subway_stations_geog USING GIST (geog);
 
-The difference is under the covers: the geography index will correctly handle queries that cover the poles or the international date-line, while the geometry one will not.
-
-There are only a small number of native functions for the geography type:
- 
- * :command:`ST_AsText(geography)` returns ``text``
- * :command:`ST_GeographyFromText(text)` returns ``geography``
- * :command:`ST_AsBinary(geography)` returns ``bytea``
- * :command:`ST_GeogFromWKB(bytea)` returns ``geography``
- * :command:`ST_AsSVG(geography)` returns ``text``
- * :command:`ST_AsGML(geography)` returns ``text``
- * :command:`ST_AsKML(geography)` returns ``text``
- * :command:`ST_AsGeoJson(geography)` returns ``text``
- * :command:`ST_Distance(geography, geography)` returns ``double``
- * :command:`ST_DWithin(geography, geography, float8)` returns ``boolean``
- * :command:`ST_Area(geography)` returns ``double``
- * :command:`ST_Length(geography)` returns ``double``
- * :command:`ST_Covers(geography, geography)` returns ``boolean``
- * :command:`ST_CoveredBy(geography, geography)` returns ``boolean``
- * :command:`ST_Intersects(geography, geography)` returns ``boolean``
- * :command:`ST_Buffer(geography, float8)` returns ``geography`` [#Casting_note]_
- * :command:`ST_Intersection(geography, geography)` returns ``geography`` [#Casting_note]_
- 
-Creating a Geography Table
---------------------------
- 
-The SQL for creating a new table with a geography column is much like that for creating a geometry table. However, geography includes the ability to specify the object type directly at the time of table creation. For example:
+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 :  
+ 
+ * :command:`ST_AsText(geography)` retourne la reprÃ©sentation ``textuelle``
+ * :command:`ST_GeographyFromText(text)` retourne un objet de type ``geography``
+ * :command:`ST_AsBinary(geography)` retourne la reprÃ©sentation binaire ``bytea``
+ * :command:`ST_GeogFromWKB(bytea)` retourne un objet de type ``geography``
+ * :command:`ST_AsSVG(geography)` retourne ``text``
+ * :command:`ST_AsGML(geography)` retourne ``text``
+ * :command:`ST_AsKML(geography)` retourne ``text``
+ * :command:`ST_AsGeoJson(geography)` retourne ``text``
+ * :command:`ST_Distance(geography, geography)` retourne ``double``
+ * :command:`ST_DWithin(geography, geography, float8)` retourne ``boolean``
+ * :command:`ST_Area(geography)` retourne ``double``
+ * :command:`ST_Length(geography)` retourne ``double``
+ * :command:`ST_Covers(geography, geography)` retourne ``boolean``
+ * :command:`ST_CoveredBy(geography, geography)` retourne ``boolean``
+ * :command:`ST_Intersects(geography, geography)` retourne ``boolean``
+ * :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
+---------------------------------------------
+ 
+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 :
 
 .. code-block:: sql
@@ -166,5 +166,5 @@
   INSERT INTO airports VALUES ('REK', 'POINT(-21.8628 64.1286)');
   
-In the table definition, the ``GEOGRAPHY(Point)`` specifies our airport data type as points. The new geography fields don't get registered in the ``geometry_columns``. Instead, they are registered in a new view called ``geography_columns`` that is automatically kept up to date without need for an :command:`AddGeom...` like functions.
+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``.
 
 .. code-block:: sql
@@ -181,15 +181,14 @@
 .. note::
 
-  The ability to define geometry types and SRIDs inside the table ``CREATE`` statement, and the automatic update of the ``geometry_columns`` metadata are features that have been prototyped with ``geography`` and will be added to the ``geometry`` type for PostGIS 2.0.
-  
-
-Casting to Geometry
+  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
 -------------------
 
-While the basic functions for geography types can handle many use cases, there are times when you might need access to other functions only supported by the geometry type. Fortunately, you can convert objects back and forth from geography to geometry.
-
-The PostgreSQL syntax convention for casting is to append ``::typename`` to the end of the value you wish to cast. So, ``2::text`` with convert a numeric two to a text string '2'. And ``'POINT(0 0)'::geometry`` will convert the text representation of point into a geometry point.
-
-The :command:`ST_X(point)` function only supports the geometry type. How can we read the X coordinate from our geographies?
+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 ?
 
 .. code-block:: sql
@@ -205,37 +204,37 @@
   REK  |  -21.8628
 
-By appending ``::geometry`` to our geography value, we convert the object to a geometry with an SRID of 4326. From there we can use as many geometry functions as strike our fancy. But, remember -- now that our object is a geometry, the coordinates will be interpretted as cartesian coordinates, not spherical ones.
- 
- 
-Why (Not) Use Geography
------------------------
-
-Geographics are universally accepted coordinates -- everyone understands what latitude/longitude mean, but very few people understand what UTM coordinates mean. Why not use geography all the time?
-
- * First, as noted earlier, there are far fewer functions available (right now) that directly support the geography type. You may spend a lot of time working around geography type limitations.
- * Second, the calculations on a sphere are computationally far more expensive than cartesian calculations. For example, the cartesian formula for distance (Pythagoras) involves one call to sqrt(). The spherical formula for distance (Haversine) involves two sqrt() calls, an arctan() call, four sin() calls and two cos() calls. Trigonometric functions are very costly, and spherical calculations involve a lot of them.
- 
-The conclusion? 
-
-If your data is geographically compact (contained within a state, county or city), use the ``geometry`` type with a cartesian projection that makes sense with your data. See the http://spatialreference.org site and type in the name of your region for a selection of possible reference systems.
-
-If, on the other hand, you need to measure distance with a dataset that is geographically dispersed (covering much of the world), use the ``geography`` type. The application complexity you save by working in ``geography`` will offset any performance issues. And, casting to ``geometry`` can offset most functionality limitations.
+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.
+ 
+ 
+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.
 
 Liste des fonctions
 -------------------
 
-`ST_Distance(geometry, geometry) <http://postgis.org/docs/ST_Distance.html>`_: For geometry type Returns the 2-dimensional cartesian minimum distance (based on spatial ref) between two geometries in projected units. For geography type defaults to return spheroidal minimum distance between two geographies in meters.
-
-`ST_GeographyFromText(text) <http://postgis.org/docs/ST_GeographyFromText.html>`_: Returns a specified geography value from Well-Known Text representation or extended (WKT).
-
-`ST_Transform(geometry, srid) <http://postgis.org/docs/ST_Transform.html>`_: Returns a new geometry with its coordinates transformed to the SRID referenced by the integer parameter.
-
-`ST_X(point) <http://postgis.org/docs/ST_X.html>`_: Returns the X coordinate of the point, or NULL if not available. Input must be a point.
+`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_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_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] The buffer and intersection functions are actually wrappers on top of a cast to geometry, and are not carried out natively in spherical coordinates. As a result, they may fail to return correct results for objects with very large extents that cannot be cleanly converted to a planar representation.
- 
-   For example, the :command:`ST_Buffer(geography,distance)` function transforms the geography object into a "best" projection, buffers it, and then transforms it back to geographics. If there is no "best" projection (the object is too large), the operation can fail or return a malformed buffer.
-
+.. [#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.
+
