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.

source: trunk/workshop-foss4g/geography.rst @ 48

Revision 48, 13.7 KB checked in by nbozon, 13 years ago (diff)

Half 'Geography' translated

RevLine 
[1]1.. _geography:
2
[48]3Section 17: Coordonnées géographiques
4=====================================
[1]5
[48]6Il est trÚs fréquent de manipuler des données à coordonnées "géographiques" ou de "longitude/latitude".
[1]7
[48]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.
[1]9
10.. image:: ./geography/cartesian_spherical.jpg
11
12
[48]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 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 
[1]15
[48]16Voici par exemple les coordonnées des villes de Los Angeles et Paris.
17
[1]18 * Los Angeles: ``POINT(-118.4079 33.9434)``
19 * Paris: ``POINT(2.3490 48.8533)``
20 
[48]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érences spatiales géographiques.
[1]22
23.. code-block:: sql
24
25  SELECT ST_Distance(
26    ST_GeometryFromText('POINT(-118.4079 33.9434)', 4326), -- Los Angeles (LAX)
27    ST_GeometryFromText('POINT(2.5559 49.0083)', 4326)     -- Paris (CDG)
28    );
29
30::
31
32  121.898285970107
33 
[48]34Aha! 121! Mais, que veut dire cela ?
[1]35
[48]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 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 !
[1]37
[48]38Pour 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.
[1]39
[48]40Depuis sa version 1.5, PostGIS fournit cette fonctionnalité avec le type ``geography``.
[1]41
42.. note::
43
[48]44  Différentes bases de données spatiales développent différentes approches pour manipuler les coordonnées géographiques.
[1]45 
[48]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.
49  * Comme SQL Server, PostGIS utilise deux types: "geometry" et "geography".
[1]50 
[48]51En 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)`.
[1]52
53.. code-block:: sql
54
55  SELECT ST_Distance(
56    ST_GeographyFromText('POINT(-118.4079 33.9434)'), -- Los Angeles (LAX)
57    ST_GeographyFromText('POINT(2.5559 49.0083)')     -- Paris (CDG)
58    );
59
60::
61
62  9124665.26917268
63
[48]64Toutes les valeurs retournées étant en mÚtres, notre réponse est donc 9124 kilomÚtres.
[1]65
[48]66Les 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.
[1]67
[48]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?"
[1]69
70.. image:: ./geography/lax_cdg.jpg
71
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.
73
74.. code-block:: sql
75
76  SELECT ST_Distance(
77    ST_GeographyFromText('LINESTRING(-118.4079 33.9434, 2.5559 49.0083)'), -- LAX-CDG
78    ST_GeographyFromText('POINT(-21.8628 64.1286)')                        -- Iceland 
79  );
80
81::
82
83  531773.757079116
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.
88
89.. image:: ./geography/lax_nrt.png
90
91.. code-block:: sql
92
93   SELECT ST_Distance(
94     ST_GeometryFromText('Point(-118.4079 33.9434)'),  -- LAX
95     ST_GeometryFromText('Point(139.733 35.567)'))     -- NRT (Tokyo/Narita)
96       AS geometry_distance,
97   ST_Distance(
98     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
105  -------------------+--------------------
106    258.146005837336 |   8833954.76996256
107
108
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.
113
114.. code-block:: sql
115
116  CREATE TABLE nyc_subway_stations_geog AS
117  SELECT
118    Geography(ST_Transform(the_geom,4326)) AS geog,
119    name,
120    routes
121  FROM nyc_subway_stations;
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
128  ON nyc_subway_stations_geog USING GIST (geog);
129
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:
156
157.. code-block:: sql
158
159  CREATE TABLE airports (
160    code VARCHAR(3),
161    geog GEOGRAPHY(Point)
162  );
163 
164  INSERT INTO airports VALUES ('LAX', 'POINT(-118.4079 33.9434)');
165  INSERT INTO airports VALUES ('CDG', 'POINT(2.5559 49.0083)');
166  INSERT INTO airports VALUES ('REK', 'POINT(-21.8628 64.1286)');
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.
169
170.. code-block:: sql
171
172  SELECT * FROM geography_columns;
173 
174::
175
176           f_table_name         | f_geography_column | srid |   type   
177 -------------------------------+--------------------+------+----------
178  nyc_subway_stations_geography | geog               |    0 | Geometry
179  airports                      | geog               | 4326 | Point
180 
181.. note::
182
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
187-------------------
188
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?
194
195.. code-block:: sql
196
197  SELECT code, ST_X(geog::geometry) AS longitude FROM airports;
198
199::
200
201  code | longitude
202 ------+-----------
203  LAX  | -118.4079
204  CDG  |    2.5559
205  REK  |  -21.8628
206
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 TracBrowser for help on using the repository browser.