content/fr/developer-guide/referencing/ComponentsOfCRS.html

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html>  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <title>ComponentsOfCRS</title> <meta charset="UTF-8"/> <link rel="stylesheet" type="text/css" href="../book.css"/> </head> <body>  <section> <header> <h2 id="ComponentsOfCRS">Composantes d’un système de références par coordonnées</h2> </header> <p> Les systèmes de références spatiales par coordonnées fournissent les informations nécessaires pour faire correspondre des coordonnées numériques à des positions dans le monde réel. Dans Apache <abbr>SIS</abbr>, ils sont pratiquement tous représentés par des classes dont le nom se termine en <abbr>CRS</abbr> (l’abréviation de <i>Coordinate Reference System</i> en anglais). Ces objets contiennent: </p> <ul> <li>Un référentiel (<i>datum</i> en anglais), qui indique entre autres quel ellipsoïde utiliser comme approximation de la forme de la terre.</li> <li>Une description de chaque axe (nom, direction, unité de mesure, limites).</li> <li>Parfois une liste de paramètres permettant de convertir les coordonnées d’un autre système. C’est le cas notamment lorsqu’on utilise des projections cartographiques.</li> </ul> <p> Ces systèmes sont décrits par la norme <abbr>ISO</abbr> 19111 (<i>Referencing by Coordinates</i>), qui remplace en grande partie une norme plus ancienne mais encore utilisée pour certains aspects, <abbr>OGC 01-009</abbr> (<i>Coordinate Transformation Services</i>). Ces normes sont complétées par deux autres standards définissant des formats d’échanges: <abbr>ISO</abbr> 19136 et 19162 pour respectivement le <cite>Geographic Markup Language</cite> (<abbr>GML</abbr>) — un format <abbr>XML</abbr> précis mais verbeux — et le <cite>Well-Known Text</cite> (<abbr>WKT</abbr>) — un format texte plus facile à lire par les humains. </p> <h3 id="Ellipsoid">Géoïde et ellipsoïde</h3> <p> La surface topographique réelle étant difficile à représenter mathématiquement, elle n’est pas utilisée directement en cartographie. Une autre surface un peu plus facilement utilisable est le géoïde, une surface sur laquelle la force gravitationnelle a partout la même valeur (surface équipotentielle du champ de gravité terrestre). Cette surface est en tout point perpendiculaire à la direction indiquée par un fil à plomb (verticale du lieu). Le géoïde coïnciderait avec le niveau moyen des mers s’il n’y avait ni vent ni courants marins permanents comme le Gulf Stream. </p><p> Tout en étant nettement plus lisse que la surface topographique, le géoïde présente des creux et des bosses liés à l’inégale distribution des masses de la Terre. Pour une utilisation mathématiquement plus aisée, le géoïde est donc approximé par un ellipsoïde. Cette « figure de la Terre » est représentée dans GeoAPI par l’interface <code>Ellipsoid</code>, qui constitue un élément fondamental des systèmes de références de type <code>GeographicCRS</code> et <code>ProjectedCRS</code>. Plusieurs dizaines d’ellipsoïdes sont couramment employés pour la définition de référentiels. Certains offrent une excellente approximation pour une région précise au détriment des régions pour lesquelles le référentiel n’a pas été conçu, et d’autres offrant un compromis pour l’ensemble de la planète. </p> <div class="example"><p><b>Exemple:</b> la base de données géodétiques <abbr>EPSG</abbr> définit entre autres les ellipsoïdes « <abbr>WGS</abbr> 84 », « Clarke 1866 », « Clarke 1880 », « <abbr>GRS</abbr> 1980 » and « <abbr>GRS</abbr> 1980 Authalic Sphere » (une sphère de même surface que l’ellipsoïde <abbr>GRS</abbr> 1980). Un ellipsoïde peut être utilisé en divers endroits de la planète ou peut être très spécifique à une région précise. Par exemple au début du XX<sup>e</sup> siècle aux États-Unis, l’état du Michigan utilisait pour ses cartes un ellipsoïde basé sur l’ellipsoïde « Clarke 1866 » mais auquel la longueur des axes a été allongée de 800 pieds. Cette modification visait à tenir compte du niveau moyen de l’état au dessus du niveau de la mer.</p> </div> <p> Les principales propriétés que l’on peut obtenir d’un ellipsoïde sont montrées ci-dessous. La longueur de l’axe semi-majeur est parfois appelée <cite>rayon équatorial</cite> et la longueur de l’axe semi-mineur <cite>rayon polaire</cite>. Le facteur d’aplatissement inverse (<cite>inverse flattening factor</cite> en anglais) peut sembler superflu puisqu’il se calcule à partir des autres propriétés, mais plusieurs définitions d’ellipsoïdes fournissent ce facteur plutôt que la longueur de l’axe semi-mineur. </p> <pre><code>Unit<Length> units = ellipsoid.<code class="GeoAPI">getAxisUnit()</code>; double semiMajor = ellipsoid.<code class="GeoAPI">getSemiMajorAxis()</code>; // Avec les unités de mesures ci-haut. double semiMinor = ellipsoid.<code class="GeoAPI">getSemiMinorAxis()</code>; // Avec les unités de mesures ci-haut. double ivf = ellipsoid.<code class="GeoAPI">getInverseFlattening()</code>; // = semiMajor / (semiMajor - semiMinor). </code></pre> <h3 id="GeodeticDatum">Référentiel géodésique</h3> <p> Pour définir un système géodésique dans un pays, l’état met en place un ellipsoïde de référence qui épouse au mieux sur l’ensemble du pays la forme locale du géoïde. L’écart entre cet ellipsoïde de référence et les creux et les bosses du géoïde reste généralement inférieur à 100 mètres. Les paramètres qui permettent de lier un <code>Ellipsoid</code> à la surface de la Terre (par exemple la position de son centre) sont représentées par un objet de type <code>GeodeticDatum</code>, que l’on traduit en français par « référentiel géodésique ». Plusieurs <code>GeodeticDatum</code> peuvent utiliser le même <code>Ellipsoid</code>, mais centré ou orienté différemment. </p><p> Avant l’avènement des satellites, les mesures géodésiques se déroulaient exclusivement à la surface de la terre. En conséquence, deux îles ou continents qui ne sont pas à portée visuelle l’un de l’autre n’étaient pas rattachés géodésiquement entre eux. Ainsi les référentiels <cite>North American Datum 1983</cite> (<abbr>NAD83</abbr>) et <cite>European Datum 1950</cite> (<abbr>ED50</abbr>) sont indépendants l’un de l’autre: leurs ellipsoïdes de référence ont des centres distincts et des dimensions différentes. Une même coordonnée géographique correspondra à des positions différentes dans le monde réel selon que la coordonnée se réfère à l’un ou l’autre de ces référentiels. </p><p> L’invention du <abbr title="Global Positioning System">GPS</abbr> a précipité la création d’un système géodésique mondial, nommé <abbr title="World Geodetic System 1984">WGS84</abbr>. L’ellipsoïde de référence est alors unique et centré au centre de gravité de la terre. Les <abbr>GPS</abbr> donnent à tout moment la position absolue du récepteur rapportée à ce système géodésique. Mais <abbr>WGS84</abbr> étant un système mondial, il peut diverger significativement des systèmes locaux. Par exemple l’écart entre <abbr>WGS84</abbr> et le système européen <abbr>ED50</abbr> est de l’ordre de 150 mètres, et l’écart moyen par rapport au système de l’île de la Réunion 1947 est de 1,5 kilomètres. Il ne faut donc pas rapporter aveuglement des positions <abbr>GPS</abbr> sur une carte. Des correspondances avec les systèmes régionaux peuvent être nécessaires et sont représentées dans GeoAPI sous forme d’objets de type <code>Transformation</code>. </p><p> Les généralisation de l’usage du système <abbr>WGS84</abbr> tend à réduire le besoin d’utiliser les objets <code>Transformation</code> pour les données récentes, mais ne l’élimine pas complètement. La Terre bouge sous l’effet de la tectonique des plaques et de nouveaux systèmes sont définis chaque année pour en tenir compte. Par exemple bien que le référentiel <abbr>NAD83</abbr> a été défini à l’origine comme pratiquement équivalent à <abbr>WGS84</abbr>, il existe maintenant (en 2016) un écart d’environ 1.5 mètres entre ces deux systèmes. Le référentiel <cite>Japanese Geodetic Datum 2000</cite> était aussi défini comme pratiquement équivalent à <abbr>WGS84</abbr>, mais le nouveau référentiel <cite>Japanese Geodetic Datum 2011</cite> s’en écarte. Le référentiel <abbr>WGS84</abbr> lui-même, sensé correspondre à une définition à un instant donné, a subit des révisions dues notamment à l’amélioration de la précision des instruments. Ainsi il existe aujourd’hui au moins six versions de <abbr>WGS84</abbr>. En outre beaucoups de bordures ont été définies légalement dans des référentiels plus anciens, par exemple <abbr>NAD27</abbr> aux États-Unis. Mettre à jour dans un nouveau référentiel peut obliger à transformer des lignes droites ou des formes géométriques simples en des formes plus irrégulières si on ne veut pas que des parcelles de terrain changent de propriétaire. </p><p> Contrairement aux autres types d’objets introduits dans cette section, il n’y a pas beaucoup d’information utile que l’on peut extraire d’une instance de <code>Datum</code> à part son nom. Traduire en langage de programmation comment un référentiel est lié à la Terre est difficile. On se contente en général de considérer que si deux référentiels ont des noms différents, alors la même position sur la Terre aura des coordonnées différentes selon ces deux référentiels (même si l’ellipsoïde est identique) et la transformation des coordonnées d’un référentiel à l’autre nécessitera l’utilisation d’une base de données. </p> <h3 id="CoordinateSystem">Systèmes de coordonnées</h3> <p> Un système de coordonnées (<abbr title="Coordinate System">CS</abbr>) définit l’ensemble des axes couvrant un espace de coordonnées. Chaque axe définit sa direction approximative (nord, sud, est, ouest, haut, bas, bâbord, tribord, passé, futur, <i>etc.</i>), ses unités de mesures, les valeurs minimales et maximales permises et ce qui se passe lorsqu’on atteint ces extremums. Par exemple dans le cas de la longitude, après +180° on revient à −180°. Mais de telles boucles peuvent aussi exister dans l’axe du temps. Par exemple dans des données climatologiques de la température normale, après le mois de décembre on revient au mois de janvier. Ces mois ne sont associés à aucune année en particulier. Les axes ayant ce genre de comportement sont reconnaissables à la propriété <code>RangeMeaning.WRAPAROUND</code>. </p><p> Les principales propriétés que l’on peut obtenir d’un système de coordonnées sont montrées ci-dessous. Les axes sont numérotés de 0 à <code>cs.getDimension()-1</code> inclusivement: </p> <pre><code>CoordinateSystem cs = crs.getCoordinateSystem(); CoordinateSystemAxis secondAxe = cs.getAxis(1); // Pour un système géographique, c’est habituellement la longitude géodétique. String abréviation = secondAxe.getAbbreviation(); // Pour l’axe des longitudes, c’est habituellement "λ", "L" ou "lon". AxisDirection direction = secondAxe.getDirection(); // Pour l’axe des longitudes, c’est habituellement EAST ou parfois WEST. Unit<?> unités = secondAxe.getUnit(); // Pour l’axe des longitudes, c’est habituellement Units.DEGREE. double minimum = secondAxe.getMinimumValue(); // Pour l’axe des longitudes, c’est habituellement −180° ou parfois 0°. double maximum = secondAxe.getMaximumValue(); // Pour l’axe des longitudes, c’est habituellement +180° ou parfois 360°. RangeMeaning auxBouts = secondAxe.getRangeMeaning(); // Pour l’axe des longitudes, c’est WRAPAROUND. </code></pre> <p> En plus de la définition des axes, une autre caractéristique importante des systèmes de coordonnées est leur type (<code>CartesianCS</code>, <code>SphericalCS</code>, <i>etc.</i>). Ce type implique un ensemble de règles mathématiques pour calculer des quantités géométriques telles que les angles, distances et surfaces. Les divers sous-types de <abbr>CS</abbr> ne définissent habituellement pas de nouvelle méthodes Java comparativement au type parent, mais sont néanmoins importants. Par exemple plusieurs calculs ou associations ne sont valides qu’avec des axes perpendiculaires entre eux. Dans ce cas, le système de coordonnées sera restreint au type <code>CartesianCS</code> dans la signature des méthodes. </p><p> Les systèmes de coordonnées sont des concepts mathématiques; ils ne contiennent aucune information indiquant où sur la Terre se trouve leur origine. En conséquence, les systèmes de coordonnées seuls ne permettent pas de décrire une position terrestre; ils doivent être combinés avec un <cite>référentiel</cite>. Ces combinaisons forment les <cite>systèmes de références des coordonnées</cite> décrits dans les sections suivantes. </p> <h4 id="AxisOrder">Ordre des axes</h4> <p> L’ordre des axes est spécifié par l’autorité (typiquement une agence nationale) qui définit le <cite>système de référence des coordonnées</cite> (<abbr>CRS</abbr>). L’ordre dépend du type de <abbr>CRS</abbr> ainsi que du pays qui l’a définit. Dans le cas des <abbr>CRS</abbr> de type géographique, l’ordre (<var>latitude</var>, <var>longitude</var>) est utilisé par les géographes et les pilotes depuis des siècles. Toutefois des développeurs de logiciels tendent à préférer l’ordre (<var>x</var>, <var>y</var>) pour tous systèmes de coordonnées. Ces différentes pratiques entraînent des définitions contradictoires de l’ordre des axes pour pratiquement tous les <abbr>CRS</abbr> de type <code>GeographicCRS</code>, pour certains <code>ProjectedCRS</code> dans l’hémisphère sud (Afrique du Sud, Australie, <i>etc.</i>) et pour certaines projections polaires entre autres. </p><p> Les standards <abbr>OGC</abbr> récents demandent d’ordonner les axes tel que spécifié par l’autorité qui a définit le <abbr>CRS</abbr>. Mais des standards <abbr>OGC</abbr> plus anciens utilisaient l’ordre (<var>x</var>, <var>y</var>) inconditionnellement, en ignorant les spécifications des autorités sur ce point. Beaucoup de logiciels continuent d’utiliser cet ordre (<var>x</var>, <var>y</var>), peut-être parce qu’une telle uniformisation rend l’implémentation et l’utilisation des <abbr>CRS</abbr> <em>en apparence</em> plus simple. Apache <abbr>SIS</abbr> supporte les deux conventions avec l’approche suivante: par défaut, <abbr>SIS</abbr> construit les <abbr>CRS</abbr> avec les axes <em>dans l’ordre définit par l’autorité</em>. Ces <abbr>CRS</abbr> sont construits par des appels à la méthode <code>CRS.forCode(String)</code>, et l’ordre des axes effectif peut être vérifié après la création du <abbr>CRS</abbr> par un appel à <code>System.out.println(crs)</code>. Mais si l’ordre (<var>x</var>, <var>y</var>) est désiré pour des raisons de compatibilité avec d’anciens standards <abbr>OGC</abbr> ou avec d’autres logiciels, alors les <abbr>CRS</abbr> peuvent être modifiés de manière à avoir la longitude en premier avec un appel à la méthode suivante: </p> <pre><code>CoordinateReferenceSystem crs = …; // CRS obtenu de n’importe quelle façon. crs = AbstractCRS.castOrCopy(crs).forConvention(AxesConvention.RIGHT_HANDED)</code></pre> <p> Parmi les anciens standards de l’<abbr>OGC</abbr> qui utilisaient un ordre des axes non-conforme, un standard influent était la version 1 du format <cite>Well Known Text</cite> (<abbr>WKT</abbr>). D’après ce format largement utilisé, les définitions <abbr>WKT</abbr> 1 sans éléments <code>AXIS[…]</code> explicites doivent être interprétés comme ayant ses axes dans l’ordre (<var>longitude</var>, <var>latitude</var>) ou (<var>x</var>, <var>y</var>). Dans la version 2 du format <abbr>WKT</abbr>, les éléments <code>AXIS[…]</code> ne sont plus optionnel et devrait contenir explicitement un sous-élément <code>ORDER[…]</code> pour rendre l’ordre voulu encore plus évident. Mais si les éléments <code>AXIS[…]</code> sont malgré tout omis dans une définition <abbr>WKT</abbr> 2, alors Apache <abbr>SIS</abbr> utilise l’ordre (<var>latitude</var>, <var>longitude</var>) par défaut. Pour résumer: </p> <ul> <li>L’ordre par défaut d’un <abbr>CRS</abbr> géographique en <abbr>WKT</abbr> 1 est (<var>longitude</var>, <var>latitude</var>) tel que spécifié par le standard <abbr>OGC</abbr> 01-009.</li> <li>L’ordre par défaut d’un <abbr>CRS</abbr> géographique en <abbr>WKT</abbr> 2 est (<var>latitude</var>, <var>longitude</var>), mais c’est une interprétation spécifique de <abbr>SIS</abbr> vu que la norme <abbr>ISO</abbr> 19162 ne mentionne pas de comportement par défaut.</li> </ul> <p> Pour éviter des ambiguïtés, les utilisateurs sont encouragés à toujours fournir explicitement les éléments <code>AXIS[…]</code> dans leurs <abbr>WKT</abbr>. Le format <abbr>WKT</abbr> sera présenté plus en détails dans les sections suivantes. </p> <h3 id="GeographicCRS">Systèmes géographiques</h3> <p> Il y a plusieurs sortes de latitudes et de longitudes. Deux sortes courantes que supporte Apache <abbr>SIS</abbr> sont les latitudes <cite>géodésiques</cite> et <cite>géocentriques</cite>. Ces deux types d’angles diffèrent légèrement dans la façon dont ils interceptent la surface de l’ellipsoïde. Sur la surface de la Terre, la différence entre ces deux types de latitudes varient de 0 à environ 20 km. </p><p> Lorsque les gens parlent de latitudes et de longitudes, ils sous-entendent généralement des latitudes <em>géodésiques</em>. Un système de référence des coordonnées utilisant de telles latitudes et longitudes est dit <cite>géographique</cite> et est représenté par l’interface <code>GeographicCRS</code>. Les systèmes utilisant les autres sortes de latitudes sont représentés par d’autres interfaces <abbr>CRS</abbr>. </p> <h3 id="ProjectedCRS">Projections cartographiques</h3> <p> Les projections cartographiques représentent une surface courbe (la Terre) sur une surface plane (une carte ou un écran d’ordinateur) en contrôlant les déformations: on peut préserver les angles ou les surfaces, mais pas les deux à la fois. Les propriétés géométriques à conserver dépendent de l’objet d’étude et du travail à effectuer. Par exemple les pays plutôt allongés dans le sens Est-Ouest utilisent souvent une projection de Lambert, alors que les pays plutôt allongés dans le sens Nord-Sud préfèrent une projection de Mercator Transverse. </p> <div class="warning"> Cette section est incomplète. Voyez la version anglaise pour une version éventuellement plus complète. </div> </section> </body> </html>

content/fr/developer-guide/referencing/ComponentsOfCRS.html (233 lines of code) (raw):