Bienvenue sur PostGIS.fr

Bienvenue sur PostGIS.fr , le site de la communauté des utilisateurs francophones de PostGIS.

PostGIS ajoute le support d'objets géographique à la base de données PostgreSQL. En effet, PostGIS "spatialise" le serverur PostgreSQL, ce qui permet de l'utiliser comme une base de données SIG.

Maintenu à jour, en fonction de nos disponibilités et des diverses sorties des outils que nous testons, nous vous proposons l'ensemble de nos travaux publiés en langue française.


Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/workshop-foss4g/geography.rst

    r62 r1  
    11.. _geography: 
    22 
    3 Partie 17 : Coordonnées géographiques 
    4 ===================================== 
    5  
    6 Il est trÚs fréquent de manipuler des données à coordonnées "géographiques" ou de "longitude/latitude". 
    7  
    8 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. 
     3Section 17: Geography 
     4===================== 
     5 
     6It is very common to have data in which the coordinate are "geographics" or "latitude/longitude".  
     7 
     8Unlike 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). 
    99 
    1010.. image:: ./geography/cartesian_spherical.jpg 
    1111 
    12  
    13 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. 
    14  
    15  
    16 Voici par exemple les coordonnées des villes de Los Angeles et Paris. 
     12You 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. 
     13 
     14For example, here are the coordinates of Los Angeles and Paris. 
    1715 
    1816 * Los Angeles: ``POINT(-118.4079 33.9434)`` 
    1917 * Paris: ``POINT(2.3490 48.8533)`` 
    20  
    21 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. 
     18  
     19The 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. 
    2220 
    2321.. code-block:: sql 
    … …  
    3129 
    3230  121.898285970107 
    33  
    34 Aha! 121! Mais, que veut dire cela ? 
    35  
    36 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 ! 
    37  
    38 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. 
    39  
    40 Depuis sa version 1.5, PostGIS fournit cette fonctionnalité avec le type ``geography``. 
     31   
     32Aha! 121! But, what does that mean?  
     33 
     34The units for spatial reference 4326 are degrees. So our answer is 121 degrees. But (again), what does that mean?  
     35 
     36On 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. 
     37 
     38In 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.  
     39 
     40Starting with version 1.5, PostGIS provides this functionality through the ``geography`` type. 
    4141 
    4242.. note:: 
    4343 
    44   Différentes bases de données spatiales développent différentes approches pour manipuler les coordonnées géographiques. 
    45  
    46   * Oracle essaye de mettre à jour la différence de maniÚre transparente en lançant des calculs lorsque le SRID est géographique. 
    47   * SQL Server utilise deux types spatiaux, "STGeometry" pour les coordonnées cartésiens et STGeography" pour les coordonnées géographqiues. 
    48   * Informix Spatial est une pure extension cartésienne d'Informix, alors qu'Informix Geodetic est une pure extension géographique. 
    49   * Comme SQL Server, PostGIS utilise deux types: "geometry" et "geography". 
    50  
    51 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)`. 
     44  Different spatial databases have different approaches for "handling geographics"  
     45   
     46  * Oracle attempts to paper over the differences by transparently doing geographic calculations when the SRID is geographic.  
     47  * SQL Server uses two spatial types, "STGeometry" for cartesian data and "STGeography" for geographics.  
     48  * Informix Spatial is a pure cartesian extension to Informix, while Informix Geodetic is a pure geographic extension.  
     49  * Similar to SQL Server, PostGIS uses two types, "geometry" and "geography". 
     50   
     51Using 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)`. 
    5252 
    5353.. code-block:: sql 
    … …  
    6262  9124665.26917268 
    6363 
    64 Toutes les valeurs retournées étant en mÚtres, notre réponse est donc 9124 kilomÚtres. 
    65  
    66 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. 
    67  
    68 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?" 
     64A big number! All return values from ``geography`` calculations are in meters, so our answer is 9124km.  
     65 
     66Older 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. 
     67 
     68The 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?"  
    6969 
    7070.. image:: ./geography/lax_cdg.jpg 
    7171 
    72 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. 
     72Working 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. 
    7373 
    7474.. code-block:: sql 
    … …  
    7676  SELECT ST_Distance( 
    7777    ST_GeographyFromText('LINESTRING(-118.4079 33.9434, 2.5559 49.0083)'), -- LAX-CDG 
    78     ST_GeographyFromText('POINT(-21.8628 64.1286)')                        -- Iceland 
     78    ST_GeographyFromText('POINT(-21.8628 64.1286)')                        -- Iceland   
    7979  ); 
    8080 
    … …  
    8282 
    8383  531773.757079116 
    84  
    85 Donc le point le plus proche de l'Islande pendant le vol LAX-CDG est de 532 kilomÚtres. 
    86  
    87 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. 
     84   
     85So the closest approach to Iceland on the LAX-CDG route is a relatively small 532km. 
     86   
     87The 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. 
    8888 
    8989.. image:: ./geography/lax_nrt.png 
    … …  
    9494     ST_GeometryFromText('Point(-118.4079 33.9434)'),  -- LAX 
    9595     ST_GeometryFromText('Point(139.733 35.567)'))     -- NRT (Tokyo/Narita) 
    96        AS geometry_distance, 
     96       AS geometry_distance,  
    9797   ST_Distance( 
    9898     ST_GeographyFromText('Point(-118.4079 33.9434)'), -- LAX 
    99      ST_GeographyFromText('Point(139.733 35.567)'))    -- NRT (Tokyo/Narita) 
    100        AS geography_distance; 
    101  
    102 :: 
    103  
    104    geometry_distance | geography_distance 
     99     ST_GeographyFromText('Point(139.733 35.567)'))    -- NRT (Tokyo/Narita)  
     100       AS geography_distance;  
     101     
     102:: 
     103 
     104   geometry_distance | geography_distance  
    105105  -------------------+-------------------- 
    106106    258.146005837336 |   8833954.76996256 
    107107 
    108108 
    109 Utiliser le type 'Geography' 
    110 ---------------------------- 
    111  
    112 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. 
     109Using Geography 
     110--------------- 
     111 
     112In 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. 
    113113 
    114114.. code-block:: sql 
    115115 
    116116  CREATE TABLE nyc_subway_stations_geog AS 
    117   SELECT 
    118     Geography(ST_Transform(the_geom,4326)) AS geog, 
    119     name, 
     117  SELECT  
     118    Geography(ST_Transform(the_geom,4326)) AS geog,  
     119    name,  
    120120    routes 
    121121  FROM nyc_subway_stations; 
    122  
    123 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 : 
    124  
    125 .. code-block:: sql 
    126  
    127   CREATE INDEX nyc_subway_stations_geog_gix 
     122    
     123Building a spatial index on a geography table is exactly the same as for geometry: 
     124 
     125.. code-block:: sql 
     126 
     127  CREATE INDEX nyc_subway_stations_geog_gix  
    128128  ON nyc_subway_stations_geog USING GIST (geog); 
    129129 
    130 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. 
    131  
    132 Il n'y a qu'un petit nombre de fonctions disponibles pour le type ``geography`` : 
    133  
    134  * :command:`ST_AsText(geography)` retourne la représentation ``textuelle`` 
    135  * :command:`ST_GeographyFromText(text)` retourne un objet de type ``geography`` 
    136  * :command:`ST_AsBinary(geography)` retourne la représentation binaire ``bytea`` 
    137  * :command:`ST_GeogFromWKB(bytea)` retourne un objet de type ``geography`` 
    138  * :command:`ST_AsSVG(geography)` retourne ``text`` 
    139  * :command:`ST_AsGML(geography)` retourne ``text`` 
    140  * :command:`ST_AsKML(geography)` retourne ``text`` 
    141  * :command:`ST_AsGeoJson(geography)` retourne ``text`` 
    142  * :command:`ST_Distance(geography, geography)` retourne ``double`` 
    143  * :command:`ST_DWithin(geography, geography, float8)` retourne ``boolean`` 
    144  * :command:`ST_Area(geography)` retourne ``double`` 
    145  * :command:`ST_Length(geography)` retourne ``double`` 
    146  * :command:`ST_Covers(geography, geography)` retourne ``boolean`` 
    147  * :command:`ST_CoveredBy(geography, geography)` retourne ``boolean`` 
    148  * :command:`ST_Intersects(geography, geography)` retourne ``boolean`` 
    149  * :command:`ST_Buffer(geography, float8)` retourne ``geography`` [#Casting_note]_ 
    150  * :command:`ST_Intersection(geography, geography)` retourne ``geography`` [#Casting_note]_ 
    151  
    152 Création d'une table stockant des géographies 
    153 --------------------------------------------- 
    154  
    155 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 : 
     130The 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. 
     131 
     132There are only a small number of native functions for the geography type: 
     133  
     134 * :command:`ST_AsText(geography)` returns ``text`` 
     135 * :command:`ST_GeographyFromText(text)` returns ``geography`` 
     136 * :command:`ST_AsBinary(geography)` returns ``bytea`` 
     137 * :command:`ST_GeogFromWKB(bytea)` returns ``geography`` 
     138 * :command:`ST_AsSVG(geography)` returns ``text`` 
     139 * :command:`ST_AsGML(geography)` returns ``text`` 
     140 * :command:`ST_AsKML(geography)` returns ``text`` 
     141 * :command:`ST_AsGeoJson(geography)` returns ``text`` 
     142 * :command:`ST_Distance(geography, geography)` returns ``double`` 
     143 * :command:`ST_DWithin(geography, geography, float8)` returns ``boolean`` 
     144 * :command:`ST_Area(geography)` returns ``double`` 
     145 * :command:`ST_Length(geography)` returns ``double`` 
     146 * :command:`ST_Covers(geography, geography)` returns ``boolean`` 
     147 * :command:`ST_CoveredBy(geography, geography)` returns ``boolean`` 
     148 * :command:`ST_Intersects(geography, geography)` returns ``boolean`` 
     149 * :command:`ST_Buffer(geography, float8)` returns ``geography`` [#Casting_note]_ 
     150 * :command:`ST_Intersection(geography, geography)` returns ``geography`` [#Casting_note]_ 
     151  
     152Creating a Geography Table 
     153-------------------------- 
     154  
     155The 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: 
    156156 
    157157.. code-block:: sql 
    … …  
    161161    geog GEOGRAPHY(Point) 
    162162  ); 
    163  
     163   
    164164  INSERT INTO airports VALUES ('LAX', 'POINT(-118.4079 33.9434)'); 
    165165  INSERT INTO airports VALUES ('CDG', 'POINT(2.5559 49.0083)'); 
    166166  INSERT INTO airports VALUES ('REK', 'POINT(-21.8628 64.1286)'); 
    167  
    168 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``. 
     167   
     168In 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. 
    169169 
    170170.. code-block:: sql 
    171171 
    172172  SELECT * FROM geography_columns; 
    173  
    174 :: 
    175  
    176            f_table_name         | f_geography_column | srid |   type 
     173   
     174:: 
     175 
     176           f_table_name         | f_geography_column | srid |   type    
    177177 -------------------------------+--------------------+------+---------- 
    178178  nyc_subway_stations_geography | geog               |    0 | Geometry 
    179179  airports                      | geog               | 4326 | Point 
    180  
     180   
    181181.. note:: 
    182182 
    183   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. 
    184  
    185 Conversion de type 
     183  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. 
     184   
     185 
     186Casting to Geometry 
    186187------------------- 
    187188 
    188 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. 
    189  
    190 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. 
    191  
    192 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 ? 
     189While 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. 
     190 
     191The 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. 
     192 
     193The :command:`ST_X(point)` function only supports the geometry type. How can we read the X coordinate from our geographies? 
    193194 
    194195.. code-block:: sql 
    … …  
    198199:: 
    199200 
    200   code | longitude 
     201  code | longitude  
    201202 ------+----------- 
    202   LAX  | -118.4079 
     203  LAX  | -118.4079  
    203204  CDG  |    2.5559 
    204205  REK  |  -21.8628 
    205206 
    206 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. 
    207  
    208  
    209 Pourquoi (ne pas) utiliser les géographies 
    210 ------------------------------------------ 
    211  
    212 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 ? 
    213  
    214  * 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. 
    215  * 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. 
    216  
    217 Quel conclusion en tirer ? 
    218  
    219 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. 
    220  
    221 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. 
    222  
    223 Liste des fonctions 
    224 ------------------- 
    225  
    226 `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. 
    227  
    228 `ST_GeographyFromText(text) <http://postgis.org/docs/ST_GeographyFromText.html>`_: Retourne la valeur géographique à partir d'une représentation en WKT ou EWKT. 
    229  
    230 `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. 
    231  
    232 `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. 
    233  
    234  
    235 .. rubric:: Notes de bas de page 
    236  
    237 .. [#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. 
    238  
    239    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é. 
    240  
     207By 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. 
     208  
     209  
     210Why (Not) Use Geography 
     211----------------------- 
     212 
     213Geographics 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? 
     214 
     215 * 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. 
     216 * 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. 
     217  
     218The conclusion?  
     219 
     220If 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. 
     221 
     222If, 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. 
     223 
     224Function List 
     225------------- 
     226 
     227`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. 
     228 
     229`ST_GeographyFromText(text) <http://postgis.org/docs/ST_GeographyFromText.html>`_: Returns a specified geography value from Well-Known Text representation or extended (WKT). 
     230 
     231`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. 
     232 
     233`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. 
     234 
     235 
     236.. rubric:: Footnotes 
     237 
     238.. [#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. 
     239  
     240   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. 
     241 
Note: See TracChangeset for help on using the changeset viewer.