Index: trunk/workshop-foss4g/geography.rst
===================================================================
--- trunk/workshop-foss4g/geography.rst	(revision 81)
+++ trunk/workshop-foss4g/geography.rst	(revision 1)
@@ -1,23 +1,21 @@
 .. _geography:
 
-Partie 17 : CoordonnÃ©es gÃ©ographiques
-=====================================
-
-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.
+Section 17: Geography
+=====================
+
+It is very common to have data in which the coordinate are "geographics" or "latitude/longitude". 
+
+Unlike coordinates in Mercator, UTM, or Stateplane, geographic coordinates are **not cartesian coordinates**. Geographic coordinates do not represent a linear distance from an origin as plotted on a plane. Rather, these **spherical coordinates** describe the angular distance between the equator and the poles. In spherical coordinates a point is specified by the distance from the origin (the radius), the angle of rotation from the initial meridian plane, and the angle from the polar axis (analogous to a vector from the origin through the North Pole).
 
 .. 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 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.
+You can treat geographic coordinates as approximate cartesian coordinates and continue to do spatial calculations. However, measurements of distance, length and area will be nonsensical. Since spherical coordinates measure **angular** distance, the units are in "degrees." Further, the approximate results from indexes and true/false tests like intersects and contains can become terribly wrong. The distance between points get larger as problem areas like the poles or the international dateline are approached.
+
+For example, here are the coordinates of Los Angeles and Paris.
 
  * 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Ã©rence spatiale gÃ©ographique.
+ 
+The following calculates the distance between Los Angeles and Paris using the standard PostGIS cartesian :command:`ST_Distance(geometry, geometry)`.  Note that the SRID of 4326 declares a geographic spatial reference system.
 
 .. code-block:: sql
@@ -31,23 +29,25 @@
 
   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 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``.
+  
+Aha! 121! But, what does that mean? 
+
+The units for spatial reference 4326 are degrees. So our answer is 121 degrees. But (again), what does that mean? 
+
+On a sphere, the size of one "degree square" is quite variable, becoming smaller as you move away from the equator. Think of the meridians (vertical lines) on the globe getting closer to each other as you go towards the poles. So, a distance of 121 degrees doesn't *mean* anything. It is a nonsense number.
+
+In order to calculate a meaningful distance, we must treat geographic coordinates not as approximate cartesian coordinates but rather as true spherical coordinates.  We must measure the distances between points as true paths over a sphere -- a portion of a great circle. 
+
+Starting with version 1.5, PostGIS provides this functionality through the ``geography`` type.
 
 .. note::
 
-  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 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``, 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)`.
+  Different spatial databases have different approaches for "handling geographics" 
+  
+  * Oracle attempts to paper over the differences by transparently doing geographic calculations when the SRID is geographic. 
+  * SQL Server uses two spatial types, "STGeometry" for cartesian data and "STGeography" for geographics. 
+  * Informix Spatial is a pure cartesian extension to Informix, while Informix Geodetic is a pure geographic extension. 
+  * Similar to SQL Server, PostGIS uses two types, "geometry" and "geography".
+  
+Using the ``geography`` instead of ``geometry`` type, let's try again to measure the distance between Los Angeles and Paris. Instead of :command:`ST_GeometryFromText(text)`, we will use :command:`ST_GeographyFromText(text)`.
 
 .. code-block:: sql
@@ -62,13 +62,13 @@
   9124665.26917268
 
-Toutes les valeurs retournÃ©es Ã©tant en mÃštres, notre rÃ©ponse est donc 9124 kilomÃštres.
-
-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?"
+A big number! All return values from ``geography`` calculations are in meters, so our answer is 9124km. 
+
+Older versions of PostGIS supported very basic calculations over the sphere using the :command:`ST_Distance_Spheroid(point, point, measurement)` function. However, :command:`ST_Distance_Spheroid` is substantially limited. The function only works on points and provides no support for indexing across the poles or international dateline.
+
+The need to support non-point geometries becomes very clear when posing a question like "How close will a flight from Los Angeles to Paris come to Iceland?" 
 
 .. 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, 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.
+Working with geographic coordinates on a cartesian plane (the purple line) yields a *very* wrong answer indeed! Using great circle routes (the red lines) gives the right answer. If we convert our LAX-CDG flight into a line string and calculate the distance to a point in Iceland using ``geography`` we'll get the right answer (recall) in meters.
 
 .. 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 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.
+  
+So the closest approach to Iceland on the LAX-CDG route is a relatively small 532km.
+  
+The cartesian approach to handling geographic coordinates breaks down entirely for features that cross the international dateline. The shortest great-circle route from Los Angeles to Tokyo crosses the Pacific Ocean. The shortest cartesian route crosses the Atlantic and Indian Oceans.
 
 .. image:: ./geography/lax_nrt.png
@@ -94,64 +94,64 @@
      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
 
 
-Utiliser le type 'Geography'
-----------------------------
-
-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.
+Using 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.
 
 .. 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 ``geography`` est exactement identique Ã  la mÃ©thode employÃ©e pour les gÃ©omÃ©tries :
-
-.. code-block:: sql
-
-  CREATE INDEX nyc_subway_stations_geog_gix
+   
+Building a spatial index on a geography table is exactly the same as for geometry:
+
+.. code-block:: sql
+
+  CREATE INDEX nyc_subway_stations_geog_gix 
   ON nyc_subway_stations_geog USING GIST (geog);
 
-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``
- * :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Ã©ographies
----------------------------------------------
-
-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 :
+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:
 
 .. code-block:: sql
@@ -161,34 +161,35 @@
     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Ã©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``.
+  
+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.
 
 .. 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.
-
-Conversion de type
+  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
 -------------------
 
-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 ?
+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?
 
 .. code-block:: sql
@@ -198,43 +199,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 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 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, 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 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:: 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Ã©.
-
+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.
+
+Function List
+-------------
+
+`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.
+
+
+.. 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.
+
