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

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html>  <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="fr"> <head> <title>Referencing</title> <meta charset="UTF-8"/> <link rel="stylesheet" type="text/css" href="../book.css"/> </head> <body>  <section> <header> <h1 id="Referencing">Systèmes de références spatiales</h1> </header> <p> Pour donner une position sur la Terre, on peut utiliser des noms tels que celui d’une ville ou une adresse postale — on parle alors de références spatiales par <cite>identifiants</cite> — ou on peut donner des valeurs numériques valides dans un système de coordonnées donné telles que les latitudes et longitudes — on parle alors de références spatiales par <cite>coordonnées</cite>. Chaque système de référence implique des approximations telles que le choix de la forme géométrique (géoïde, ellipsoïde, <i>etc.</i>) utilisée comme approximation de la forme de la Terre, le choix des propriétés géométriques (angles, distances, <i>etc.</i>) à préserver lors de la représentation d’une carte sur une surface plane, et les pertes de précision lorsque l’on doit transformer des coordonnées vers des systèmes utilisant un <a href="#GeodeticDatum">référentiel</a> différent. </p><p> Une fausse croyance très répandue dit que l’on peut éviter cette complexité en choisissant un seul système de référence des coordonnées (typiquement <abbr title="World Geodetic System 1984">WGS84</abbr>) comme système universel pour toutes les données. Les chapitres suivants expliqueront pourquoi la réalité n’est pas si simple. Qu’un système universel réponde ou non aux besoins d’une application dépend de la précision désirée, ainsi que du type de calculs que l’on souhaite effectuer avec les coordonnées. Sauf indication contraire, Apache <abbr>SIS</abbr> tente d’assurer une précision de 1 centimètre pour les coordonnées sur la Terre. Mais la maîtrise de cette précision nécessite le respect de certaines conditions: </p> <ul> <li>Rester dans la zone de validité du système telle que donnée par <code>ReferenceSystem.getDomainOfValidity()</code>.</li> <li>Savoir que les mesures de distances dans une projection cartographique donnée ne sont vraies qu’à certains endroits, appelés par exemple « parallèles standards ».</li> <li>Vérifier la précision des transformations de coordonnées, par exemple avec <code>CoordinateOperation.getCoordinateOperationAccuracy()</code>.</li> <li>Trouver les paramètres les plus appropriées pour une transformation de coordonnées requiert l’usage d’une base de données géodétiques telles que <abbr>EPSG</abbr>. Déclarer ces paramètres directement dans le <abbr>CRS</abbr> (par exemple avec un élément <code>TOWGS84</code>) n’est souvent pas suffisant.</li> </ul> <article> <header> <h2>Bibliothèques de type « early binding » versus « late binding »</h2> </header> <p> Le caractère universel du système <abbr>WGS84</abbr> rend tentante l’idée de l’utiliser comme système pivot, afin de simplifier l’implémentation d’une bibliothèque de transformation de coordonnées. La transformation d’une coordonnée d’un référentiel <var>A</var> vers un référentiel <var>B</var> pourrait se faire en transformant d’abord de <var>A</var> vers <abbr>WGS84</abbr>, puis de <abbr>WGS84</abbr> vers <var>B</var>. Il suffirait ainsi de stocker dans chaque objet <code>GeodeticDatum</code> les informations nécessaires à la transformation vers <abbr>WGS84</abbr>. Cette approche était encouragée dans la version 1 du format <abbr>WKT</abbr>, qui définissait un élément <code>TOWGS84[…]</code> remplissant ce rôle. Cette approche est désignée par <abbr>EPSG</abbr> sous le nom de « early binding » car elle associe des informations sur la transformations de coordonnées très tôt dans la définition des objets géodésiques, souvent directement au moment de la construction d’un object <code>GeographicCRS</code>. Bien que <abbr>EPSG</abbr> reconnaisse que cette approche soit couramment employée, elle n’est pas recommandée pour plusieurs raisons: </p> <ul> <li>Il existe parfois plusieurs transformations allant d’un référentiel <var>A</var> vers <var>B</var>, chacune étant plus précise pour une région géographique donnée.</li> <li>Certaines opérations sont conçues spécifiquement pour transformer de <var>A</var> vers <var>B</var> et n’ont pas la même précision qu’aurait une autre transformation faisant un détour par <abbr>WGS84</abbr>.</li> <li><abbr>WGS84</abbr> lui-même subit parfois des révisions, ce qui en fait une cible mouvante (bien que très lentement) pour les bibliothèques de transformations de coordonnées.</li> <li>Il existe d’autres systèmes globaux qui pourraient servir de pivot, par exemple le <cite>Galileo Reference Frame</cite> (<abbr>GTRF</abbr>) mis en place par le concurrent européen du <abbr>GPS</abbr>.</li> </ul> <div class="example"><p><b>Exemple:</b> la base de données géodésiques <abbr>EPSG</abbr> définie une cinquantaine de transformations de <abbr>NAD27</abbr> vers <abbr>NAD83</abbr>. Dans une approche de type « early binding », le même système de référence « <abbr>NAD27</abbr> » représenté dans le format <abbr>WKT</abbr> 1 aurait besoin d’être défini avec un élément <code>TOWGS84[-8, 160, 176]</code> pour des coordonnées aux États-Unis, ou avec un élément <code>TOWGS84[-10, 158, 187]</code> pour coordonnées aux Canada. Différents paramètres existent aussi pour d’autres régions telles que Cuba. Il n’est donc pas possible de représenter une telle diversité en associant un seul élément <code>TOWGS84[…]</code> à un système de référence des coordonnées. Même en restreignant l’usage d’un référenciel au domaine de validité de son élément <code>TOWGS84[…]</code>, ces transformations resteraient approximatives avec une précision de 10 mètres dans le cas des États-Unis. Des transformations plus précises existent sous la forme des grilles de changements de référentiel <abbr>NADCON</abbr>, mais ces grilles sont pour des transformations de <abbr>NAD27</abbr> vers <abbr>NAD83</abbr> (qui se déplacent ensemble sur la même plaque continentale) et non vers <abbr>WGS84</abbr> (qui se déplace indépendamment). Cette différence était souvent ignorée lorsque l’on considérait que <abbr>NAD83</abbr> et <abbr>WGS84</abbr> étaient pratiquement équivalents, mais cette supposition est aujourd’hui à prendre avec plus de précautions. </p></div> <p> <abbr>EPSG</abbr> recommande plutôt d’utiliser une approche dite « late binding », selon laquelle les méthodes et paramètres nécessaires aux transformations de coordonnées sont définis pour des paires de référentiels « <var>A</var> vers <var>B</var> » (éventuellement complétées par leurs domaines de validité) plutôt qu’associés à des référentiels pris isolément. Apache <abbr>SIS</abbr> est une implémentation de type « late binding », bien qu’une réminiscence de l’approche « early binding » existe toujours sous la forme de la propriété <code>DefaultGeodeticDatum.getBursaWolfParameters()</code>. <abbr>SIS</abbr> n’utilise cette dernière que comme solution de dernier recours s’il ne peut pas appliquer l’approche « late binding » avec les systèmes de références donnés. </p> </article> <p> Le module <code>sis-referencing</code> de Apache <abbr>SIS</abbr> fournit un ensemble de classes implémentant les différentes spécialisations de l’interface <code>ReferenceSystem</code> ainsi que leurs composantes. Ces implémentations permettent de stocker une description des systèmes de références spatiales ainsi que leurs méta-données telles que la zone de validité. Toutefois ces objets n’effectuent aucune opération sur les coordonnées. Les <cite>conversions</cite> ainsi que les <cite>transformations</cite> de coordonnées sont le travail d’une autre famille de classes, dont la racine est l’interface <code>CoordinateOperation</code>. Ces classes seront discutées dans <a href="#CoordinateOperations">une autre section</a>. </p> <xi:include href="ComponentsOfCRS.html"/> <xi:include href="CoordinateOperations.html"/> </section> </body> </html>

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