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:
Timestamp:
17/03/2012 00:49:40 (13 years ago)
Author:
thomasg
Message:

Fin correction typo et orthographe V2 du document

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/workshop-foss4g/geography.rst

    r53 r62  
    44===================================== 
    55 
    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.  
     6Il est trÚs fréquent de manipuler des données à coordonnées "géographiques" ou de "longitude/latitude". 
     7 
     8Au 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. 
    99 
    1010.. image:: ./geography/cartesian_spherical.jpg 
    1111 
    1212 
    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 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.   
    14   
     13Vous 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 
    1515 
    1616Voici par exemple les coordonnées des villes de Los Angeles et Paris. 
    … …  
    1818 * Los Angeles: ``POINT(-118.4079 33.9434)`` 
    1919 * 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érences spatiales géographiques. 
     20 
     21La 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. 
    2222 
    2323.. code-block:: sql 
    … …  
    3131 
    3232  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 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 ! 
    37  
    38 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. 
     33 
     34Aha! 121! Mais, que veut dire cela ? 
     35 
     36L'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 
     38Pour 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. 
    3939 
    4040Depuis sa version 1.5, PostGIS fournit cette fonctionnalité avec le type ``geography``. 
    … …  
    4343 
    4444  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 lanacant des calculs lorsuqe 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.  
     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. 
    4949  * Comme SQL Server, PostGIS utilise deux types: "geometry" et "geography". 
    50    
    51 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)`. 
     50 
     51En 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)`. 
    5252 
    5353.. code-block:: sql 
    … …  
    6666Les 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. 
    6767 
    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?"  
     68Le 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?" 
    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, 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.  
     72Ré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. 
    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 plu sproche de l'Islande pendant le vol LAX-CDG est de 532 kilomÚtres.S 
    86  
    87 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.   
     84 
     85Donc le point le plus proche de l'Islande pendant le vol LAX-CDG est de 532 kilomÚtres. 
     86 
     87L'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. 
    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 
    … …  
    110110---------------------------- 
    111111 
    112 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. 
     112Afin 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. 
    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 géographie 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 
     123La 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 
    128128  ON nyc_subway_stations_geog USING GIST (geog); 
    129129 
    130 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. 
    131  
    132 Il n'y a qu'un petit nombre de fonctions disponibles pour le type géographie :   
    133   
     130La 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 
     132Il n'y a qu'un petit nombre de fonctions disponibles pour le type ``geography`` : 
     133 
    134134 * :command:`ST_AsText(geography)` retourne la représentation ``textuelle`` 
    135135 * :command:`ST_GeographyFromText(text)` retourne un objet de type ``geography`` 
    … …  
    149149 * :command:`ST_Buffer(geography, float8)` retourne ``geography`` [#Casting_note]_ 
    150150 * :command:`ST_Intersection(geography, geography)` retourne ``geography`` [#Casting_note]_ 
    151   
    152 Création d'une table stockant des géograhpies 
     151 
     152Création d'une table stockant des géographies 
    153153--------------------------------------------- 
    154   
    155 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 : 
     154 
     155Le 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 : 
    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é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``. 
     167 
     168Lors 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``. 
    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.   
     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. 
    184184 
    185185Conversion de type 
    186186------------------- 
    187187 
    188 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. 
    189  
    190 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. 
    191  
    192 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 ? 
     188Bien 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 
     190La 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 
     192La fonction :command:`ST_X(point)` supporte seulement le type géométrique. Comment lire la coordonnée X d'une de nos géographie ? 
    193193 
    194194.. code-block:: sql 
    … …  
    198198:: 
    199199 
    200   code | longitude  
     200  code | longitude 
    201201 ------+----------- 
    202   LAX  | -118.4079  
     202  LAX  | -118.4079 
    203203  CDG  |    2.5559 
    204204  REK  |  -21.8628 
    205205 
    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 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. 
    207   
    208   
     206En 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 
    209209Pourquoi (ne pas) utiliser les géographies 
    210210------------------------------------------ 
    211211 
    212 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 ? 
    213  
    214  * 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. 
    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) 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. 
    216   
    217 Quel conclusion en tirer ?  
    218  
    219 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. 
    220  
    221 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. 
     212Les 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 
     217Quel conclusion en tirer ? 
     218 
     219Si 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 
     221Si, 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. 
    222222 
    223223Liste des fonctions 
    224224------------------- 
    225225 
    226 `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. 
     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. 
    227227 
    228228`ST_GeographyFromText(text) <http://postgis.org/docs/ST_GeographyFromText.html>`_: Retourne la valeur géographique à partir d'une représentation en WKT ou EWKT. 
    229229 
    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 fournit. 
     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. 
    231231 
    232232`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. 
    233233 
    234234 
    235 .. rubric:: Footnotes 
    236  
    237 .. [#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. 
    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 correct ou retourner une one tampon mal formée. 
    240  
     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 
Note: See TracChangeset for help on using the changeset viewer.