sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1794727 [3/4] - in /sis/site/trunk: book/en/ book/en/annex/ book/en/coverage/ book/en/geometry/ book/en/introduction/ book/en/overview/ book/en/storage/ book/en/xml/ book/fr/ book/fr/overview/ book/fr/referencing/ book/fr/storage/ book/fr/...
Date Wed, 10 May 2017 14:38:19 GMT
Modified: sis/site/trunk/content/book/fr/developer-guide.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/fr/developer-guide.html?rev=1794727&r1=1794726&r2=1794727&view=diff
==============================================================================
--- sis/site/trunk/content/book/fr/developer-guide.html [UTF-8] (original)
+++ sis/site/trunk/content/book/fr/developer-guide.html [UTF-8] Wed May 10 14:38:19 2017
@@ -33,8 +33,15 @@
 <li><a href="#UML-annotation">Correspondances explicites entre GeoAPI et les spécifications abstraites</a></li>
 <li><a href="#MappingToJDK">Correspondances implicites avec le JDK standard</a></li>
 <li><a href="#GeoAPI-implementation">Implémentations fournies par Apache SIS</a></li></ul></li>
-<li><a href="#About">Conventions utilisées dans ce guide</a><ul>
+<li><a href="#AboutBook">Conventions utilisées dans ce guide</a><ul>
 <li><a href="#CodeColors">Code de couleurs</a></li></ul></li></ul></li>
+<li><a href="#DataAccess">Accès aux données géospatiales</a></li>
+<li><a href="#Coverage">Couvertures de données (Coverages)</a></li>
+<li><a href="#Geometry">Géométries</a><ul>
+<li><a href="#GeometryBase">Classes de base</a><ul>
+<li><a href="#DirectPosition">Points et positions directes</a></li>
+<li><a href="#Envelope">Enveloppes</a><ul>
+<li><a href="#AntiMeridian">Enveloppes traversant l’antiméridien</a></li></ul></li></ul></li></ul></li>
 <li><a href="#Referencing">Systèmes de références spatiales</a><ul>
 <li><a href="#ComponentsOfCRS">Composantes d’un système de références par coordonnées</a><ul>
 <li><a href="#Ellipsoid">Géoïde et ellipsoïde</a></li>
@@ -57,13 +64,12 @@
 <li><a href="#TransformDerivative">Dérivées partielles des opérations</a><ul>
 <li><a href="#DerivativeAndEnvelope">Utilité des dérivées pour la reprojection d’enveloppes</a></li>
 <li><a href="#DerivativeAndRaster">Utilité des dérivées pour la reprojection d’images</a></li>
-<li><a href="#GetDerivative">Obtention de la dérivée en un point</a></li></ul></li></ul></li></ul></li>
-<li><a href="#Geometry">Géométries</a><ul>
-<li><a href="#GeometryBase">Classes de base</a><ul>
-<li><a href="#DirectPosition">Points et positions directes</a></li>
-<li><a href="#Envelope">Enveloppes</a><ul>
-<li><a href="#AntiMeridian">Enveloppes traversant l’antiméridien</a></li></ul></li></ul></li></ul></li>
-<li><a href="#Coverage">Couvertures de données (Coverages)</a></li>
+<li><a href="#GetDerivative">Obtention de la dérivée en un point</a></li></ul></li></ul></li>
+<li><a href="#Formats">Formats de stockage des données</a></li>
+<li><a href="#XML-ISO">Représentation des objets en XML</a><ul>
+<li><a href="#XML-ISO-19115">Représentation des méta-données selon ISO 19115-3</a><ul>
+<li><a href="#gco-id">Identification d’instances déjà définies</a></li>
+<li><a href="#nilReason">Représentation de valeurs manquantes</a></li></ul></li></ul></li></ul></li>
 <li><a href="#Utilities">Classes et méthodes utilitaires</a><ul>
 <li><a href="#ComparisonModes">Modes de comparaisons des objets</a></li>
 <li><a href="#ObjectConverters">Convertisseurs d’objets</a></li>
@@ -73,10 +79,6 @@
 <li><a href="#Locale.ROOT">Convention Locale.ROOT</a></li>
 <li><a href="#UnicodePoint">Traitement des caractères</a><ul>
 <li><a href="#Whitespaces">Interprétation des espaces blancs</a></li></ul></li></ul></li></ul></li>
-<li><a href="#XML-ISO">Représentation des objets en XML</a><ul>
-<li><a href="#XML-ISO-19115">Représentation des méta-données selon ISO 19115-3</a><ul>
-<li><a href="#gco-id">Identification d’instances déjà définies</a></li>
-<li><a href="#nilReason">Représentation de valeurs manquantes</a></li></ul></li></ul></li>
 <li><a href="#Annexes">Annexes</a><ul>
 <li><a href="#ReduceDependency">Réduire la dépendance directe envers Apache SIS</a><ul>
 <li><a href="#UML-annotation-indep">Correspondances entre GeoAPI et les spécifications abstraites</a></li>
@@ -104,10 +106,11 @@
 
 
 
+
 <section>
 <header>
 <h1 id="Standards"><span class="section-number">1.</span> Standards et normes</h1>
-<nav><div class="chapter-links"><div class="next-chapter"><a href="#Referencing">Chapitre suivant</a> ➡</div></div></nav>
+<nav><div class="chapter-links"><div class="next-chapter"><a href="#DataAccess">Chapitre suivant</a> ➡</div></div></nav>
 </header>
 <nav>Dans ce chapitre:<ul class="toc">
 <li><a href="#ConceptualModels">Sources des modèles conceptuels de Apache SIS</a></li>
@@ -115,7 +118,7 @@
 <li><a href="#UML-annotation">Correspondances explicites entre GeoAPI et les spécifications abstraites</a></li>
 <li><a href="#MappingToJDK">Correspondances implicites avec le JDK standard</a></li>
 <li><a href="#GeoAPI-implementation">Implémentations fournies par Apache SIS</a></li></ul></li>
-<li><a href="#About">Conventions utilisées dans ce guide</a><ul>
+<li><a href="#AboutBook">Conventions utilisées dans ce guide</a><ul>
 <li><a href="#CodeColors">Code de couleurs</a></li></ul></li></ul></nav>
 <p>
 Une communauté d’informations géospatiales est un ensemble de systèmes ou d’individus capables d’échanger
@@ -584,7 +587,7 @@ quitte à obtenir une valeur nulle en at
 
 <details>
 <summary>Pour en savoir plus sur les origines du projet GeoAPI</summary>
-<article>
+<article id="GeoAPI-history">
 <header>
 <h2>Historique du projet GeoAPI</h2>
 </header>
@@ -1115,7 +1118,7 @@ lorsqu’il n’est vraiment pas possibl
 
 <section>
 <header>
-<h2 id="About"><span class="section-number">1.3.</span> Conventions utilisées dans ce guide</h2>
+<h2 id="AboutBook"><span class="section-number">1.3.</span> Conventions utilisées dans ce guide</h2>
 </header>
 <p>
 Les standards privilégient parfois l’application de certains termes génériques à des contextes particuliers,
@@ -1173,490 +1176,843 @@ Le lecteur peut ignorer ces boîtes gris
 
 <section>
 <header>
-<h1 id="Referencing"><span class="section-number">2.</span> Systèmes de références spatiales</h1>
-<nav><div class="chapter-links"><div class="previous-chapter">⬅ <a href="#Standards">Chapitre précédent</a></div><div class="next-chapter"><a href="#Geometry">Chapitre suivant</a> ➡</div></div></nav>
+<h1 id="DataAccess"><span class="section-number">2.</span> Accès aux données géospatiales</h1>
+<nav><div class="chapter-links"><div class="previous-chapter">⬅ <a href="#Standards">Chapitre précédent</a></div><div class="next-chapter"><a href="#Coverage">Chapitre suivant</a> ➡</div></div></nav>
 </header>
-<nav>Dans ce chapitre:<ul class="toc">
-<li><a href="#ComponentsOfCRS">Composantes d’un système de références par coordonnées</a><ul>
-<li><a href="#Ellipsoid">Géoïde et ellipsoïde</a></li>
-<li><a href="#GeodeticDatum">Référentiel géodésique</a></li>
-<li><a href="#CoordinateSystem">Systèmes de coordonnées</a><ul>
-<li><a href="#AxisOrder">Ordre des axes</a></li></ul></li>
-<li><a href="#GeographicCRS">Systèmes géographiques</a><ul>
-<li><a href="#GeographicWKT">Format Well-Known Text</a></li></ul></li>
-<li><a href="#ProjectedCRS">Projections cartographiques</a><ul>
-<li><a href="#ProjectedWKT">Format Well-Known Text</a></li></ul></li>
-<li><a href="#CompoundCRS">Dimensions verticales et temporelles</a><ul>
-<li><a href="#CompoundWKT">Format Well-Known Text</a></li></ul></li></ul></li>
-<li><a href="#GetCRS">Obtention d’un système de référence spatial</a><ul>
-<li><a href="#CRSAuthorityFactory">Systèmes prédéfinis par des autorités</a></li>
-<li><a href="#CRSParsing">Lecture d’une définition au format GML ou WKT</a></li>
-<li><a href="#CRSFactory">Construction programmatique explicite</a></li>
-<li><a href="#CRS_UserCode">Ajout de définitions</a></li></ul></li>
-<li><a href="#CoordinateOperations">Opérations sur les coordonnées</a><ul>
-<li><a href="#MathTransform">Exécution de opérations</a></li>
-<li><a href="#TransformDerivative">Dérivées partielles des opérations</a><ul>
-<li><a href="#DerivativeAndEnvelope">Utilité des dérivées pour la reprojection d’enveloppes</a></li>
-<li><a href="#DerivativeAndRaster">Utilité des dérivées pour la reprojection d’images</a></li>
-<li><a href="#GetDerivative">Obtention de la dérivée en un point</a></li></ul></li></ul></li></ul></nav>
+<nav>Dans ce chapitre:<ul class="toc"/></nav>
 <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 est 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 title="Spatial Information System">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:
+Bien qu’il soit possible de créer des structures de données directement en mémoire,
+le plus souvent les données sont lues à partir de fichiers ou autres types d’entrepôts.
+Il y a plusieurs moyens d’accéder à ces données, mais une façon pratique est d’utiliser
+la méthode de commodité <code>DataStores​.open(Object)</code>.
+L’argument donné à cette méthode peut être un chemin vers un fichier
+(<code>File</code>, <code>Path</code>, <code>URL</code>, <code>URI</code>),
+un flux d’entrée vers un fichier déjà ouvert
+(<code>Channel</code>, <code>DataInput</code>, <code>InputStream</code>, <code>Reader</code>),
+une connexion à une base de données (<code>DataSource</code>, <code>Connection</code>)
+ou d’autres types d’objets spécifiques à la source de données.
+La méthode <code>DataStores​.open(Object)</code> se charge de détecter le format de données
+et retourne une instance de <code>DataStore</code> pouvant le lire.
+</p>
+<p>
+Les fonctionnalités d’un <code>DataStore</code> dépendent de la nature des données à manipuler
+(couvertures de données, ensembles de géométries, séries temporelles, <i>etc.</i>),
+mais dans tous les cas il y aura toujours au moins quelques méta-données que l’on peut extraire.
+Les méta-données permettent d’identifier les phénomènes ou entités décrits par les données
+(température, occupation du sol, <i>etc.</i>),
+la région géographique ou la plage temporelle couverte par les données ainsi que leur résolution.
+Certains sources suffisamment riches fournissent aussi une estimation de la qualité des données,
+des informations permettant de contacter la personne ou l’organisme responsable des données,
+les contraintes légales ou techniques à l’utilisation, l’historique des traitements,
+les dates prévues des prochaines mise-à-jour de mises-à-jour, <i>etc.</i>
+</p>
+<p>
+Les différents formats de données ont souvent leur propre modèle de méta-données,
+mais Apache <abbr title="Spatial Information System">SIS</abbr> les traduits tous vers un modèle unique afin de cacher cette hétérogénéité.
+Cette approche, consistant à choisir un seul modèle de méta-données comme <em>modèle pivot</em>, est fréquemment utilisée par d’autres bibliothèques aussi.
+Par exemple Apache Tika utilise le standard <cite>Dublin Core</cite> comme modèle pivot,
+alors que Java Image I/O définit son propre modèle pivot dans le paquet <code>javax.imageio.metadata</code>.
+Pour Apache <abbr>SIS</abbr>, le modèle pivot choisit est le standard international de méta-données en information géographique
+<cite><abbr title="International Organization for Standardization">ISO</abbr> 19115-1:2014 — principes de base</cite>, complété par
+<cite><abbr>ISO</abbr> 19115-2 — extensions pour l’acquisition et le traitement</cite>.
+Ce modèle organise les méta-données dans une arborescence où chaque information est accessible via un chemin bien définit,
+peu importe l’origine de cette information.
+Par exemple si un format de données peut nous fournir les coordonnées géographiques d’une boîte englobant toutes les données,
+alors cette information sera toujours accessible (peu importe le format de données) à partir de l’objet <code class="GeoAPI">Metadata</code>
+sous le noeud <code>identificationInfo</code>, sous-noeud <code>extent</code>, sous-noeud <code>geographicElement</code>.
 </p>
-<ul>
-<li>Rester dans la zone de validité du système telle que donnée par <code class="GeoAPI">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 class="GeoAPI">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 title="Coordinate Reference System">CRS</abbr> (par exemple avec un élément <code class="OGC">TOWGS84</code>) n’est souvent pas suffisant.</li>
-</ul>
-<article>
+<div class="example"><p><b>Exemple:</b>
+le code suivant lit un fichier de méta-données d’une image Landsat-8 située au Vietnam:
+</p>
+
+<pre><b>try</b> (DataStore ds = DataStores.open(<b>new</b> File(<i>"LC81230522014071LGN00_MTL.txt"</i>))) {
+    <code class="GeoAPI">Metadata</code> md = getMetadata();
+
+    <code class="comment">// Afin de simplifier cet exemple, nous omettons les vérifications de valeurs nulles ou de collections vides.
+</code>    <code class="GeoAPI">Identification</code>   idInfo = md    .getIdentificationInfo().iterator().next();
+    <code class="GeoAPI">Extent</code>           extent = idInfo.getExtents()           .iterator().next();
+    <code class="GeoAPI">GeographicExtent</code> bbox   = extent.getGeographicElements().iterator().next();
+
+    System.out.println(<i>"La région géographique des données est:"</i>);
+    System.out.println(bbox);
+}</pre>
+
+<p>
+Cet exemple produira la sortie suivante:
+</p>
+
+<pre><samp>La région géographique des données est:
+Geographic Bounding Box
+  ├─West bound longitude…………………………… 108°20′10,464″E
+  ├─East bound longitude…………………………… 110°26′39,66″E
+  ├─South bound latitude…………………………… 10°29′59,604″N
+  └─North bound latitude…………………………… 12°37′25,716″N</samp></pre>
+
+</div>
+</section>
+
+
+<section>
 <header>
-<h2>Bibliothèques de type « early binding » versus « late binding »</h2>
+<h1 id="Coverage"><span class="section-number">3.</span> Couvertures de données (<i>Coverages</i>)</h1>
+<nav><div class="chapter-links"><div class="previous-chapter">⬅ <a href="#DataAccess">Chapitre précédent</a></div><div class="next-chapter"><a href="#Geometry">Chapitre suivant</a> ➡</div></div></nav>
 </header>
+<nav>Dans ce chapitre:<ul class="toc"/></nav>
 <p>
-Le caractère universel du système <abbr title="World Geodetic System 1984">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 class="GeoAPI">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 class="GeoAPI">GeographicCRS</code>.
-Bien que <abbr>EPSG</abbr> reconnaisse que cette approche soit couramment employée, elle n’est pas recommandée pour plusieurs raisons:
+Les images, souvent nommées <i>rasters</i> en anglais, sont des cas particuliers
+d’une structure de données appelée <i>coverages</i>.
+On pourrait traduire ce terme anglais par « couverture de données ».
+Le titre du standard les décrivant, « <i>Coverage geometry and functions</i> »
+(<abbr title="International Organization for Standardization">ISO</abbr> 19123), résume bien les deux éléments essentiels des couvertures de données:
 </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>
+<li>
+<p>
+Un <i>coverage</i> est une fonction qui, à partir d’une coordonnée spécifiée en entrée,
+retourne une valeur d’attribut. L’ensemble des valeurs pouvant être données en entrée est appelé le domaine
+(<i>domain</i> en anglais), alors que l’ensemble des valeurs pouvant être retournées est appelé <i>range</i> en anglais.
+Le domaine est souvent l’espace spatio-temporel couvert par les données,
+mais rien dans <abbr title="Spatial Information System">SIS</abbr> n’empêche les couvertures de s’étendre à d’autres dimensions.
+Par exemple les études en thermodynamique utilisent souvent un espace dont les dimensions sont la température et la pression.
+</p>
 <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.
+les valeurs des pixels d’une image pourraient contenir des mesures d’élévation du terrain.
+Si une fonction <var>h</var> = <var>f</var>(φ,λ) permet d’obtenir (éventuellement à l’aide d’interpolations)
+l’élévation <var>h</var> en fonction d’une coordonnée géographique (φ,λ), alors
+l’enveloppe géographique de l’image définie le <i>domain</i>, la fonction <var>f</var> est le <i>coverage</i>,
+et l’ensemble des valeurs de <var>h</var> que peut retourner cette fonction est le <i>range</i>.
 </p></div>
+</li>
+<li>
 <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 title="Spatial Information System">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 class="SIS">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.
+Les différents types de couvertures peuvent se caractériser par la géométrie de leurs cellules.
+En particulier, une couverture n’est pas nécessairement composée de cellules quadrilatérales.
+Toutefois les cellules quadrilatérales étant de loin les plus fréquentes (puisque c’est la géométrie classique des pixels des images),
+on utilisera souvent le terme <i>grid coverage</i> pour désigner les couvertures composées de telles cellules.
+Dans <abbr>SIS</abbr>, la géométrie de ces couvertures est décrite par la classe <code class="SIS">GridGeometry</code>.
 </p>
-</article>
+</li>
+</ul>
 <p>
-Le module <code class="SIS">sis-referencing</code> de Apache <abbr>SIS</abbr> fournit un ensemble de classes implémentant
-les différentes spécialisations de l’interface <code class="GeoAPI">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 class="GeoAPI">CoordinateOperation</code>.
-Ces classes seront discutées dans <a href="#CoordinateOperation">une autre section</a>.
+Les caractéristiques du domaine spatial sont définies par le standard <abbr>ISO</abbr> 19123,
+alors que les caractéristiques du <i>range</i> ne font pas parties du standard.
+Le standard mentionne simplement que les <i>ranges</i> peuvent être finis ou infinis,
+et ne sont pas nécessairement numériques.
+Par exemple les valeurs retournées par une couverture peuvent provenir d’une énumération
+(« ceci est une forêt », « ceci est un lac », <i>etc.</i>).
+Toutefois, le standard définit deux grands types de couvertures qui ont un impact
+sur les types de <i>ranges</i> autorisés:
+les couvertures <i>discrètes</i> et les couvertures <i>continues</i>.
+Présentées simplement, les couvertures continues sont des fonctions pouvant utiliser des méthodes d’interpolations.
+Or, les interpolations n’étant possibles qu’avec des valeurs numériques, les <i>ranges</i> de valeurs
+non-numériques ne peuvent être utilisés qu’avec des couvertures de type <code class="OGC">CV_DiscreteCoverage</code>.
+En revanche, les <i>ranges</i> de valeurs numériques peuvent
+être utilisés aussi avec des couvertures de type <code class="OGC">CV_ContinuousCoverage</code>.
+</p>
+<aside>
+<h2>La classe <code class="SIS">Range</code> de SIS et sa relation avec les standards</h2>
+<p>
+La distinction entre les plages de tout type de valeurs et les plages de valeurs numériques est représentée dans <abbr title="Spatial Information System">SIS</abbr>
+par les classes <code class="SIS">Range</code> et <code class="SIS">NumberRange</code> respectivement.
+La classe <code class="SIS">NumberRange</code> est la plus utilisée, et elle est aussi celle qui se rapproche le plus de la
+<a href="http://fr.wikipedia.org/wiki/Intervalle_%28math%C3%A9matiques%29">notion mathématique usuelle d’un intervalle</a>.
+Se représentation textuelle se rapproche des spécifications du standard <abbr title="International Organization for Standardization">ISO</abbr> 31-11,
+excepté que la virgule est remplacée par le caractère “…” comme séparateur des valeurs minimales et maximales.
+Par exemple “[0 … 256)” représente la plage des valeurs 0 inclusivement à 256 exclusivement.
+</p>
+<p>
+Les objets <code class="SIS">Range</code> ne sont associés aux <i>coverages</i> que indirectement.
+Dans <abbr>SIS</abbr>, les valeurs que peuvent retourner les couvertures sont décrites par des
+objets de type <code class="SIS">SampleDimension</code>. Ce sont ces derniers qui contiendront
+des instances de <code class="SIS">Range</code> ainsi que d’autres informations telles qu’une
+<i>fonction de transfert</i> (décrite plus loin).
 </p>
+</aside>
+</section>
 
 
+<section>
+<header>
+<h1 id="Geometry"><span class="section-number">4.</span> Géométries</h1>
+<nav><div class="chapter-links"><div class="previous-chapter">⬅ <a href="#Coverage">Chapitre précédent</a></div><div class="next-chapter"><a href="#Referencing">Chapitre suivant</a> ➡</div></div></nav>
+</header>
+<nav>Dans ce chapitre:<ul class="toc">
+<li><a href="#GeometryBase">Classes de base</a><ul>
+<li><a href="#DirectPosition">Points et positions directes</a></li>
+<li><a href="#Envelope">Enveloppes</a><ul>
+<li><a href="#AntiMeridian">Enveloppes traversant l’antiméridien</a></li></ul></li></ul></li></ul></nav>
+<p>
+Ce chapitre introduit quelques aspects de la norme <abbr title="International Organization for Standardization">ISO</abbr> 19107 (<i>Spatial schema</i>)
+et les classes de Apache <abbr title="Spatial Information System">SIS</abbr> qui les implémentent.
+</p>
 
 
 
 
 <section>
 <header>
-<h2 id="ComponentsOfCRS"><span class="section-number">2.1.</span> Composantes d’un système de références par coordonnées</h2>
+<h2 id="GeometryBase"><span class="section-number">4.1.</span> Classes de base</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 title="Spatial Information System">SIS</abbr>,
-ils sont pratiquement tous représentés par des classes dont le nom se termine en <abbr title="Coordinate Reference System">CRS</abbr>
-(l’abréviation de <i>Coordinate Reference System</i> en anglais). Ces objets contiennent:
+Chaque objet géométrique est considéré comme un ensemble infini de points.
+En tant qu’ensemble, leurs opérations les plus fondamentales sont de même nature que les opérations standards des collections du Java.
+On pourrait donc voir une géométrie comme une sorte de <code>java.util.Set</code> dont les éléments seraient des points,
+à ceci près que le nombre d’éléments contenus dans cet ensemble est infini (à l’exception des géométries représentant un simple point).
+Pour mieux représenter ce concept, la norme <abbr title="International Organization for Standardization">ISO</abbr> et GeoAPI définissent une interface <code class="OGC">TransfiniteSet</code>
+que l’on peut voir comme un <code>Set</code> de taille infini. Bien qu’un lien de parenté existe conceptuellement entre ces interfaces,
+GeoAPI ne définit pas <code class="GeoAPI">TransfiniteSet</code> comme une sous-interface de <code>java.util.Set</code>
+car la définition de certaines méthodes telles que <code>size()</code> et <code>iterator()</code> serait problématique.
+On y retrouve toutefois des méthodes très similaires telles que <code class="GeoAPI">contains(…)</code> et <code class="GeoAPI">intersects(…)</code>.
 </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 title="International Organization for Standardization">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.
+Toutes les géométries sont des spécialisations de <code class="GeoAPI">TransfiniteSet</code>.
+La classe parente de toutes ces géométries est appelée <code class="OGC">GM_Object</code> dans la norme <abbr>ISO</abbr> 19107.
+Les interfaces de GeoAPI utilisent plutôt le nom <code class="GeoAPI">Geometry</code>, car l’omission du préfixe <code class="OGC">GM_</code>
+(comme le veut la convention dans GeoAPI) aurait laissé un nom trop proche de la classe <code>Object</code> du Java.
 </p>
 
-<h3 id="Ellipsoid"><span class="section-number">2.1.1.</span> Géoïde et ellipsoïde</h3>
+
+
+<h3 id="DirectPosition"><span class="section-number">4.1.1.</span> Points et positions directes</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 class="GeoAPI">Ellipsoid</code>,
-qui constitue un élément fondamental des systèmes de références de type <code class="GeoAPI">GeographicCRS</code> et <code class="GeoAPI">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.
+<abbr title="International Organization for Standardization">ISO</abbr> 19107 définit deux types de structures pour représenter un point:
+<code class="OGC">GM_Point</code> et <code class="OGC">DirectPosition</code>.
+Le premier type est une véritable géométrie et peut donc être relativement lourd, selon les implémentations.
+Le second type n’est pas considéré formellement comme une géométrie;
+il n’étend ni <code class="OGC">GM_Object</code> ni <code class="OGC">TransfiniteSet</code>.
+Il ne définit pratiquement pas d’opérations autres que le stockage d’une séquence de nombres représentant une coordonnée.
+Il peut donc être un objet plus léger.
 </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>
-
-<h3 id="GeodeticDatum"><span class="section-number">2.1.2.</span> 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 class="GeoAPI">Ellipsoid</code> à la surface de la Terre (par exemple la position de son centre)
-sont représentées par un objet de type <code class="GeoAPI">GeodeticDatum</code>, que l’on traduit en français par « référentiel géodésique ».
-Plusieurs <code class="GeoAPI">GeodeticDatum</code> peuvent utiliser le même <code class="GeoAPI">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 class="GeoAPI">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 class="GeoAPI">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.
+Afin de permettre à l’<abbr title="Application Programming Interface">API</abbr> de travailler indifféremment avec ces deux types de positions,
+<abbr>ISO</abbr> 19107 définit <code class="OGC">Position</code> comme une <cite>union</cite> de
+<code class="OGC">DirectPosition</code> et <code class="OGC">GM_Point</code>.
+Il s’agit d’une union au sens du C/C++. Pour le langage Java, GeoAPI obtient le même effet en définissant
+<code class="GeoAPI">Position</code> comme l’interface parente de <code class="GeoAPI">DirectPosition</code> et <code class="GeoAPI">Point</code>.
+Dans la pratique, la grande majorité des <abbr>API</abbr> de Apache <abbr title="Spatial Information System">SIS</abbr> travaillent sur des <code class="GeoAPI">DirectPosition</code>,
+ou occasionnellement des <code class="GeoAPI">Position</code> quand il semble utile d’autoriser aussi des points géométriques.
 </p>
 
-<h3 id="CoordinateSystem"><span class="section-number">2.1.3.</span> Systèmes de coordonnées</h3>
-<p style="color: red">TODO</p>
 
-<h4 id="AxisOrder"><span class="section-number">2.1.3.1.</span> Ordre des axes</h4>
+
+<h3 id="Envelope"><span class="section-number">4.1.2.</span> Enveloppes</h3>
 <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 title="Coordinate Reference System">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 class="GeoAPI">GeographicCRS</code>, pour certains <code class="GeoAPI">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 title="Open Geospatial Consortium">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 title="Spatial Information System">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:
+Les enveloppes stockent les valeurs minimales et maximales des coordonnées d’une géométrie.
+Les enveloppes <em>ne sont pas</em> elles-mêmes des géométries; ce ne sont pas des ensembles
+infinis de points (<code class="OGC">TransfiniteSet</code>). Il n’y a aucune garantie
+que toutes les positions contenues dans les limites d’une enveloppe soient géographiquement valides.
+Il faut voir les enveloppes comme une information sur les valeurs extrêmes que peuvent prendre les
+coordonnées d’une géométrie en faisant comme si chaque dimension était indépendante des autres,
+rien de plus. Nous assimilons néanmoins les enveloppes à des rectangles, cubes ou hyper-cubes
+(selon le nombre de dimensions) afin de faciliter la discussion, mais en gardant à l’esprit leur
+nature non-géométrique.
+</p>
+<div class="example"><p><b>Exemple:</b>
+Nous pouvons tester si une position est à l’intérieur des limites de l’enveloppe.
+Un résultat positif ne garantie pas que la position est à l’intérieur de la géométrie délimitée par l’enveloppe,
+mais un résultat négatif garantie qu’elle est à l’extérieur. De même on peut effectuer des tests d’intersections.
+En revanche appliquer une rotation n’a pas beaucoup de sens pour une enveloppe, car le résultat peut être très différent
+de celui que nous aurions obtenu en effectuant une rotation de la géométrie originale, puis en recalculant son enveloppe.
+</p></div>
+<p>
+Une enveloppe peut être représentée par deux positions correspondant à deux coins opposés
+d’un rectangle, cube ou hyper-cube. On prend souvent comme premier coin celui dont toutes
+les ordonnées ont la valeur minimale (<code class="OGC">lowerCorner</code>), et comme second
+coin celui dont toutes les ordonnées ont la valeur maximale (<code class="OGC">upperCorner</code>).
+Lors d’un affichage utilisant un système de coordonnées classique (valeurs de l’axe des <var>y</var> augmentant vers le haut),
+ces deux positions apparaissent respectivement dans le coin inférieur gauche et dans le coin supérieur droit d’un rectangle.
+Attention toutefois aux différents systèmes de coordonnées, qui peuvent faire varier les positions de ces coins à l’écran.
+Les expressions <i>lower corner</i> et <i>upper corner</i>
+doivent être comprises au sens mathématique plutôt que visuel.
 </p>
 
-<pre><code class="GeoAPI">CoordinateReferenceSystem</code> crs = …;  <code class="comment">// CRS obtenu de n’importe quelle façon.
-</code>crs = AbstractCRS.castOrCopy(crs).forConvention(AxesConvention.RIGHT_HANDED)</pre>
 
+
+<h4 id="AntiMeridian"><span class="section-number">4.1.2.1.</span> Enveloppes traversant l’antiméridien</h4>
 <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:
+Les minimums et maximums sont les valeurs les plus souvent assignées aux <code class="OGC">lowerCorner</code>
+et <code class="OGC">upperCorner</code>. Mais les choses se compliquent dans le cas d’une enveloppe traversant
+l’antiméridien (-180° ou 180° de longitude). Par exemple, une enveloppe de 10° de largeur peut commencer à 175° de longitude et
+se terminer à -175°. Dans ce cas, la valeur de longitude assignée au <code class="OGC">lowerCorner</code> est
+supérieure à celle qui est assignée à l’<code class="OGC">upperCorner</code>.
+Apache <abbr title="Spatial Information System">SIS</abbr> emploie donc une définition légèrement différente de ces deux coins:
 </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 title="International Organization for Standardization">ISO</abbr> 19162 ne mentionne pas de comportement par défaut.</li>
+<li><b><code class="SIS">lowerCorner</code>:</b>
+le point de départ lorsque l’on parcourt l’intérieur de l’enveloppe dans la direction des valeurs croissantes.
+</li>
+<li><b><code class="SIS">upperCorner</code>:</b>
+le point d’arrivé lorsque l’on a parcouru l’intérieur de l’enveloppe dans la direction des valeurs croissantes.
+</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.
+Lorsque l’enveloppe ne traverse par l’antiméridien, ces deux définitions sont équivalentes à la sélection
+des valeurs minimales et maximales respectivement. C’est le cas du rectangle vert dans la figure ci-dessous.
+Lorsque l’enveloppe traverse l’antiméridien, les coins <code class="SIS">lowerCorner</code>
+et <code class="SIS">upperCorner</code> apparaissent encore en bas et en haut du rectangle
+(en supposant un système de coordonnées classique), donc leurs noms restent appropriés d’un point de vue visuel.
+Mais les positions gauche et droite sont interchangées.
+Ce cas est représenté par le rectangle rouge dans la figure ci-dessous.
+</p>
+<p style="text-align:center">
+<img alt="Exemples d’enveloppes avec et sans croisement de l’antiméridien." src="../../apidocs/org/apache/sis/geometry/doc-files/AntiMeridian.png"/>
 </p>
-
-<h3 id="GeographicCRS"><span class="section-number">2.1.4.</span> Systèmes géographiques</h3>
-<p style="color: red">TODO</p>
-
-<h4 id="GeographicWKT"><span class="section-number">2.1.4.1.</span> Format <i>Well-Known Text</i></h4>
-<p style="color: red">TODO</p>
-
-<h3 id="ProjectedCRS"><span class="section-number">2.1.5.</span> 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.
+Les notions d’inclusion et d’intersection s’interprètent toutefois de manière légèrement différente dans ces deux cas.
+Dans le cas habituel où l’on ne traverse pas l’antiméridien, le rectangle vert délimite bien une région d’inclusion.
+Les régions exclues de ce rectangle se propagent à l’infini dans toutes les directions.
+En d’autres mots, la région d’inclusion n’est pas répétée tous les 360°.
+Mais dans le cas du rectangle rouge, l’information fournie par l’enveloppe délimite plutôt la région d’exclusion qui
+se trouve entre les deux bords du rectangle. La région d’inclusion se propage à l’infini des côtés gauche et droit.
+Nous pourrions stipuler que toute longitude inférieure à -180° ou supérieure à 180° est considérée exclue,
+mais ça serait une décision arbitraire qui ne serait pas un reflet symétrique du cas habituel (rectangle vert).
+Un développeur pourrait vouloir utiliser ces valeurs, par exemple dans une mosaïque où la carte du monde
+est répétée plusieurs fois horizontalement tout en considérant chaque répétition comme distincte des autres.
+Si un développeur souhaite effectuer des opérations comme si les régions d’inclusions ou d’exclusions étaient
+répétées tous les 360°, alors il doit lui-même ramener ses valeurs de longitudes entre -180° et 180° au préalable.
+Toutes les fonctions <code class="SIS">add(…)</code>, <code class="SIS">contains(…)</code>,
+<code class="SIS">intersect(…)</code>, <i>etc.</i> de toutes les enveloppes
+définies dans le paquet <code class="SIS">org.apache.sis.geometry</code> effectuent leurs calculs selon cette convention.
 </p>
-<p style="color: red">TODO</p>
-
-<h4 id="ProjectedWKT"><span class="section-number">2.1.5.1.</span> Format <i>Well-Known Text</i></h4>
-<p style="color: red">TODO</p>
-
-<h3 id="CompoundCRS"><span class="section-number">2.1.6.</span> Dimensions verticales et temporelles</h3>
-<p style="color: red">TODO</p>
-
-<h4 id="CompoundWKT"><span class="section-number">2.1.6.1.</span> Format <i>Well-Known Text</i></h4>
-<p style="color: red">TODO</p>
+<aside>
+<h5>Généralisation à d’autres types d’axes</h5>
+<p>
+Cette section nomme spécifiquement la longitude car il constitue le cas le plus courant d’axe cyclique.
+Mais dans les enveloppes de Apache <abbr title="Spatial Information System">SIS</abbr>, il n’est fait nul part mention explicite du cas de la longitude, ni de son cycle de 360°.
+Les caractéristiques de la plage de valeurs de chaque axe (ses extremums, unités, type de cycle, <i>etc.</i>)
+sont des attributs des objets <code class="GeoAPI">CoordinateSystemAxis</code>, indirectement associés aux enveloppes via le système de référence des coordonnées.
+Apache <abbr>SIS</abbr> inspecte ces attributs pour déterminer de quelle façon il doit effectuer ses opérations.
+Ainsi, tout axe associé au code <code class="GeoAPI">RangeMeaning.WRAPAROUND</code> bénéficiera du même traitement que la longitude.
+Cela pourrait être par exemple un axe du temps dans des données climatologiques
+(une “année” représentant la température moyenne de tous les mois de janvier, suivit de la moyenne de tous les mois de février,
+<i>etc.</i>).
+Cette généralisation s’applique aussi aux axes de longitudes définis par une plage de 0° à 360° plutôt que de -180° à 180°.
+</p>
+</aside>
+<p>
+Pour que les fonctions telles que <code class="SIS">add(…)</code> fonctionnent correctement,
+tous les objets impliqués doivent utiliser le même système de référence des coordonnées, y compris
+la même plage de valeurs. Ainsi, une enveloppe exprimant les longitudes dans la plage [-180 … +180]°
+n’est pas compatible avec une enveloppe exprimant les longitudes dans la plage [0 … 360]°.
+Les conversions, si nécessaires, sont à la charge de l’utilisateur
+(la classe <code class="SIS">Envelopes</code> fournit des méthodes de commodités pour ce faire).
+En outre, les coordonnées de l’enveloppe doivent être comprises dans les limites du système de coordonnées,
+sauf si le développeur souhaite volontairement considérer (par exemple) 300° de longitude
+comme un position distincte de -60°. La classe <code class="SIS">GeneralEnvelope</code>
+fournit une méthode <code class="SIS">normalize()</code> pour ramener les coordonnées
+dans les limites attendues, au prix parfois de valeurs <cite><i>lower</i></cite>
+supérieures à la valeur <cite><i>upper</i></cite>.
+</p>
+<aside>
+<h5>Le cas particulier de la plage [+0 … -0]</h5>
+<p>
+le Java (ou de manière plus générale, la norme IEEE 754) définit deux valeurs distinctes de zéro:
+un zéro positif et un zéro négatif. Ces deux valeurs sont considérées égales lorsqu’on les compares avec l’opérateur <code>==</code> du Java.
+Mais dans les enveloppes de <abbr title="Spatial Information System">SIS</abbr>, ils peuvent mener à des résultats opposés pour les axes ayant <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
+Une enveloppe dont la plage est [0 … 0], [-0 … -0] ou [-0 … +0] sera bien considérée comme une enveloppe vide,
+mais la page [+0 … -0] sera au contraire considérée comme incluant la totalité des valeurs, jusqu’à l’infini.
+Ce comportement est conforme à la définition de <code class="SIS">lowerCorner</code> et <code class="SIS">upperCorner</code>
+qui considère +0 comme le point de départ, et -0 comme le point d’arrivé après avoir fait le tour des valeurs possibles.
+Un tel comportement ne se produit que pour la paire de valeurs +0 et -0, et seulement dans cet ordre.
+Pour toutes les autres valeurs réelles, si la condition <code>lower</code> <code>==</code> <code>upper</code>
+est vrai, alors il est garanti que l’enveloppe est vide.
+</p>
+</aside>
 </section>
-
-
-<section>
-<header>
-<h2 id="GetCRS"><span class="section-number">2.2.</span> Obtention d’un système de référence spatial</h2>
-</header>
-<p style="color: red">TODO</p>
-
-<h3 id="CRSAuthorityFactory"><span class="section-number">2.2.1.</span> Systèmes prédéfinis par des autorités</h3>
-<p style="color: red">TODO</p>
-
-<h3 id="CRSParsing"><span class="section-number">2.2.2.</span> Lecture d’une définition au format GML ou WKT</h3>
-<p style="color: red">TODO</p>
-
-<h3 id="CRSFactory"><span class="section-number">2.2.3.</span> Construction programmatique explicite</h3>
-<p style="color: red">TODO</p>
-
-<h3 id="CRS_UserCode"><span class="section-number">2.2.4.</span> Ajout de définitions</h3>
-<p style="color: red">TODO</p>
 </section>
 
 
 <section>
 <header>
-<h2 id="CoordinateOperations"><span class="section-number">2.3.</span> Opérations sur les coordonnées</h2>
+<h1 id="Referencing"><span class="section-number">5.</span> Systèmes de références spatiales</h1>
+<nav><div class="chapter-links"><div class="previous-chapter">⬅ <a href="#Geometry">Chapitre précédent</a></div><div class="next-chapter"><a href="#Utilities">Chapitre suivant</a> ➡</div></div></nav>
 </header>
+<nav>Dans ce chapitre:<ul class="toc">
+<li><a href="#ComponentsOfCRS">Composantes d’un système de références par coordonnées</a><ul>
+<li><a href="#Ellipsoid">Géoïde et ellipsoïde</a></li>
+<li><a href="#GeodeticDatum">Référentiel géodésique</a></li>
+<li><a href="#CoordinateSystem">Systèmes de coordonnées</a><ul>
+<li><a href="#AxisOrder">Ordre des axes</a></li></ul></li>
+<li><a href="#GeographicCRS">Systèmes géographiques</a><ul>
+<li><a href="#GeographicWKT">Format Well-Known Text</a></li></ul></li>
+<li><a href="#ProjectedCRS">Projections cartographiques</a><ul>
+<li><a href="#ProjectedWKT">Format Well-Known Text</a></li></ul></li>
+<li><a href="#CompoundCRS">Dimensions verticales et temporelles</a><ul>
+<li><a href="#CompoundWKT">Format Well-Known Text</a></li></ul></li></ul></li>
+<li><a href="#GetCRS">Obtention d’un système de référence spatial</a><ul>
+<li><a href="#CRSAuthorityFactory">Systèmes prédéfinis par des autorités</a></li>
+<li><a href="#CRSParsing">Lecture d’une définition au format GML ou WKT</a></li>
+<li><a href="#CRSFactory">Construction programmatique explicite</a></li>
+<li><a href="#CRS_UserCode">Ajout de définitions</a></li></ul></li>
+<li><a href="#CoordinateOperations">Opérations sur les coordonnées</a><ul>
+<li><a href="#MathTransform">Exécution de opérations</a></li>
+<li><a href="#TransformDerivative">Dérivées partielles des opérations</a><ul>
+<li><a href="#DerivativeAndEnvelope">Utilité des dérivées pour la reprojection d’enveloppes</a></li>
+<li><a href="#DerivativeAndRaster">Utilité des dérivées pour la reprojection d’images</a></li>
+<li><a href="#GetDerivative">Obtention de la dérivée en un point</a></li></ul></li></ul></li>
+<li><a href="#Formats">Formats de stockage des données</a></li>
+<li><a href="#XML-ISO">Représentation des objets en XML</a><ul>
+<li><a href="#XML-ISO-19115">Représentation des méta-données selon ISO 19115-3</a><ul>
+<li><a href="#gco-id">Identification d’instances déjà définies</a></li>
+<li><a href="#nilReason">Représentation de valeurs manquantes</a></li></ul></li></ul></li></ul></nav>
 <p>
-Étant donné un système de référence des coordonnées (<abbr title="Coordinate Reference System">CRS</abbr>) <em>source</em> selon lequel sont exprimés des coordonnées existantes
-et un système de référence des coordonnées <em>destination</em> selon lequel les coordonnées sont désirées,
-Apache <abbr title="Spatial Information System">SIS</abbr> peut fournir une <em>opération sur les coordonnées</em> qui effectuera le travail de conversion ou de transformation.
-La recherche d’une opération peut utiliser un troisième argument, optionnel mais recommandé: la région géographique des données à transformer.
-Ce dernier argument est recommandé parce que les opérations sur les coordonnées sont souvent valides seulement dans une région géographique
-(typiquement un pays ou une province particulière), et plusieurs transformations peuvent exister pour la même paire de <abbr>CRS</abbr>
-source et destination mais avec des domaines de validité différents.
-Il peut aussi y avoir des différentes transformations qui sont différents compromis entre la précision et le domaine de validité,
-de sorte que spécifier à Apache <abbr>SIS</abbr> qu’on s’intéresse à une région plus petite
-peut lui permettre de sélectionner une opération plus précise.
-</p>
-<div class="example"><p><b>Exemple:</b>
-la base de données géodésiques <abbr>EPSG</abbr> (dans sa version 7.9) définit 77 opérations sur les coordonnées
-allant du système géographique <cite>North American Datum 1927</cite> (EPSG:4267)
-vers le système <cite>World Geodetic System 1984</cite> (EPSG:4326).
-Il y a une opération valide seulement pour la transformation de coordonnées au Québec,
-une autre opération valide pour la transformation de coordonnées au Texas mais à l’ouest de 100°W,
-une autre opération pour le même état mais à l’est de 100°W, <i>etc</i>.
-Si l’utilisateur ne spécifie pas la région géographique qui l’intéresse,
-alors le comportement par défaut de Apache <abbr>SIS</abbr> est de sélectionner l’opération valide dans la plus grande région géographique.
-Dans cet exemple, ce critère entraîne la sélection d’une opération valide pour le Canada, mais qui n’est pas valide pour les États-Unis.</p>
-</div>
-<p>
-La façon la plus facile d’obtenir une opération sur les coordonnées à partir des informations présentées ci-dessus
-est d’utiliser la classe de commodité <code class="SIS">org.apache.sis.referencing.CRS</code>:
-</p>
-
-<pre><code class="GeoAPI">CoordinateOperation</code> cop = CRS.findOperation(sourceCRS, targetCRS, areaOfInterest);</pre>
-
-<p>
-Parmi les information fournies par l’objet <code class="GeoAPI">CoordinateOperation</code> obtenu, on note en particulier:
+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 est 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 title="Spatial Information System">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>Le <cite>domaine de validité</cite>, soit comme une description textuelle telle que « Canada – onshore and offshore »
-ou comme les coordonnées géographiques d’une boîte englobante.</li>
-<li>La <cite>précision</cite>, qui peut être n’importe quoi entre 1 centimètre et quelques kilomètres.</li>
-<li>Le sous-type de l’opération sur les coordonnées. Parmi les sous-types possibles,
-deux offrent les mêmes fonctionnalités mais avec une différence conceptuelle notable:
-<ul class="verbose">
-<li>
-Les <strong>conversions</strong> de coordonnées sont entièrement définies par une formule mathématique.
-Les conversions s’effectueraient avec une précision infinie s’il n’y avait pas les inévitables
-erreurs d’arrondissements inhérents aux calculs sur des nombres réels.
-Les projections cartographiques entrent dans cette catégorie.
-</li><li>
-Les <strong>transformations</strong> de coordonnées sont définies de manière empirique.
-Elles ont souvent des erreurs de quelques mètres qui ne sont pas dues à des limites de la précision des ordinateurs.
-Ces erreurs découlent du fait que la transformation utilisée n’est qu’une approximation d’une réalité plus complexe.
-Les changements de référentiels tel que le passage de la
-<cite>Nouvelle Triangulation Française</cite> (<abbr>NTF</abbr>) vers le
-<cite>Réseau Géodésique Français 1993</cite> (<abbr>RGF93</abbr>) entrent dans cette catégorie.
-</li>
-</ul>
-</li>
+<li>Rester dans la zone de validité du système telle que donnée par <code class="GeoAPI">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 class="GeoAPI">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 title="Coordinate Reference System">CRS</abbr> (par exemple avec un élément <code class="OGC">TOWGS84</code>) n’est souvent pas suffisant.</li>
 </ul>
+<article>
+<header>
+<h2>Bibliothèques de type « early binding » versus « late binding »</h2>
+</header>
 <p>
-Lorsque l’opération sur les coordonnées est une instance de <code class="GeoAPI">Transformation</code>,
-il est possible que l’instance choisie par <abbr>SIS</abbr> ne soit qu’une parmi plusieurs possibilités en fonction de la région d’intérêt.
-En outre, sa précision sera certainement moindre que la précision centimétrique que l’on peut attendre d’une <code class="GeoAPI">Conversion</code>.
-Vérifier la zone de validité ainsi que la précision déclarées dans les méta-données de la transformation prend alors une importance particulière.
+Le caractère universel du système <abbr title="World Geodetic System 1984">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 class="GeoAPI">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 class="GeoAPI">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>
-
-<h3 id="MathTransform"><span class="section-number">2.3.1.</span> Exécution de opérations</h3>
+<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>
-L’objet <code class="GeoAPI">CoordinateOperation</code> introduit dans la section précédente fournit des informations de haut-niveau
-(<abbr title="Coordinate Reference System">CRS</abbr> source et destination, zone de validité, précision, paramètres de l’opération, <i>etc</i>).
-Le travail mathématique réel est effectué par un objet séparé, obtenu par un appel à <code class="GeoAPI">CoordinateOperation​.getMathTransform()</code>.
-Contrairement aux instances de <code class="GeoAPI">CoordinateOperation</code>, les instances de <code class="GeoAPI">MathTransform</code> ne contiennent aucune méta-données.
-Elles sont une sorte de boîte noire qui ignore tout des <abbr>CRS</abbr> source et destination
-(en fait la même instance de <code class="GeoAPI">MathTransform</code> peut être utilisée pour différentes paires de <abbr>CRS</abbr> si le travail mathématique est le même).
-En outre une instance de <code class="GeoAPI">MathTransform</code> peut être implémentée d’une manière très différente à ce que <code class="GeoAPI">CoordinateOperation</code> dit.
-En particulier, plusieurs opérations conceptuellement différentes (par exemple rotations de la longitude,
-changements d’unités de mesure, conversions entre deux projections de Mercator qui utilisent le même référentiel, <i>etc.</i>)
-sont implémentées par <code class="GeoAPI">MathTransform</code> comme des <a href="#AffineTransform">transformations affines</a>
-et concaténées pour des raisons d’efficacité, même si <code class="GeoAPI">CoordinateOperation</code> les affiche comme une chaîne d’opérations telles que la projection de Mercator.
-La section « <a href="#CoordinateOperationSteps">chaîne d’opération conceptuelle versus réelle</a> » explique plus en détails les différences.
+<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 title="Spatial Information System">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 class="SIS">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 code Java suivant effectue une projection cartographique à partir de coordonnées géographiques selon le référentiel
-<cite>World Geodetic System 1984</cite> (<abbr title="World Geodetic System 1984">WGS84</abbr>) vers des coordonnées selon le système <cite>WGS 84 / UTM zone 33N</cite>.
-Afin de rendre l’exemple un peu plus simple, ce code utilise des constantes pré-définies dans la classe de commodité <code>CommonCRS</code>.
-Mais des applications plus avancées voudront souvent utiliser des codes <abbr>EPSG</abbr> plutôt.
-Notons que toutes les coordonnées géographiques dans ce code ont la latitude avant la longitude.
+Le module <code class="SIS">sis-referencing</code> de Apache <abbr>SIS</abbr> fournit un ensemble de classes implémentant
+les différentes spécialisations de l’interface <code class="GeoAPI">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 class="GeoAPI">CoordinateOperation</code>.
+Ces classes seront discutées dans <a href="#CoordinateOperations">une autre section</a>.
 </p>
 
-<pre><b>import</b> org.opengis.geometry.<code class="GeoAPI">DirectPosition</code>;
-<b>import</b> org.opengis.referencing.crs.<code class="GeoAPI">CoordinateReferenceSystem</code>;
-<b>import</b> org.opengis.referencing.operation.<code class="GeoAPI">CoordinateOperation</code>;
-<b>import</b> org.opengis.referencing.operation.<code class="GeoAPI">TransformException</code>;
-<b>import</b> org.opengis.util.<code class="GeoAPI">FactoryException</code>;
-<b>import</b> org.apache.sis.referencing.CRS;
-<b>import</b> org.apache.sis.referencing.CommonCRS;
-<b>import</b> org.apache.sis.geometry.DirectPosition2D;
 
-<b>public</b> <b>class</b> MyApp {
-    <b>public</b> <b>static</b> <b>void</b> main(String[] args) <b>throws</b> <code class="GeoAPI">FactoryException</code>, <code class="GeoAPI">TransformException</code> {
-        <code class="GeoAPI">CoordinateReferenceSystem</code> sourceCRS = CommonCRS.WGS84.geographic();
-        <code class="GeoAPI">CoordinateReferenceSystem</code> targetCRS = CommonCRS.WGS84.UTM(40, 14);  <code class="comment">// Obtient la zone valide pour 14°E.
-</code>        <code class="GeoAPI">CoordinateOperation</code> operation = CRS.findOperation(sourceCRS, targetCRS, <b>null</b>);
 
-        <code class="comment">// Les lignes précédentes sont coûteuses et ne devraient être exécutées qu’une seule fois avant
-</code>        <code class="comment">// de transformer plusieurs points.  Dans cet exemple, l’opération que nous obtenons est valide
-</code>        <code class="comment">// pour des coordonnées dans la région géographique allant de 12°E à 18°E (zone 33) et 0°N à 84°N.
-</code>
-        <code class="GeoAPI">DirectPosition</code> ptSrc = <b>new</b> DirectPosition2D(40, 14);           <code class="comment">// 40°N 14°E
-</code>        <code class="GeoAPI">DirectPosition</code> ptDst = operation.getMathTransform().transform(ptSrc, <b>null</b>);
 
-        System.out.println(<i>"Source: "</i> + ptSrc);
-        System.out.println(<i>"Target: "</i> + ptDst);
-    }
-}</pre>
 
 
-<h3 id="TransformDerivative"><span class="section-number">2.3.2.</span> Dérivées partielles des opérations</h3>
+<section>
+<header>
+<h2 id="ComponentsOfCRS"><span class="section-number">5.1.</span> Composantes d’un système de références par coordonnées</h2>
+</header>
 <p>
-La section précédente indiquait comment projeter les coordonnées d’un système de référence vers un autre.
-Mais il existe une autre opération moins connue, qui consiste à calculer non pas la coordonnée projetée d’un point,
-mais plutôt la dérivée de la fonction de projection cartographique en ce point.
-Cette opération était définie dans une ancienne spécification du consortium Open Geospatial,
-<a href="http://www.opengeospatial.org/standards/ct">OGC 01-009</a>, aujourd’hui un peu oubliée mais pourtant encore utile.
-Appelons <var>P</var> une projection cartographique qui convertit une latitude et longitude (<var>φ</var>, <var>λ</var>) en degrés
-vers une coordonnée projetée (<var>x</var>, <var>y</var>) en mètres.
-Dans l’expression ci-dessous, nous représentons le résultat de la projection cartographique
-sous forme d’une matrice colonne (la raison sera plus claire bientôt):
+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 title="Spatial Information System">SIS</abbr>,
+ils sont pratiquement tous représentés par des classes dont le nom se termine en <abbr title="Coordinate Reference System">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 title="International Organization for Standardization">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>
 
-<table class="hidden">
-<tr>
-<th>Équation</th>
-<th>Code Java</th>
-</tr>
-<tr>
-<td style="vertical-align:middle; min-width:350px; padding-right:60px">
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<mi>P</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo>
-<mo>=</mo>
-<mfenced close="]" open="[">
-<mtable>
-<mtr><mtd><mi>x</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mtd></mtr>
-<mtr><mtd><mi>y</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mtd></mtr>
-</mtable>
-</mfenced>
-</math>
-</td>
-<td style="vertical-align:middle; min-width:500px; padding-left:60px">
-
-<pre style="margin:0"><code class="GeoAPI">DirectPosition</code> geographic = <b>new</b> DirectPosition2D(<var>φ</var>, <var>λ</var>);
-<code class="GeoAPI">DirectPosition</code> projected = <var><b>P</b></var>.transform(geographic, <b>null</b>);
-<b>double</b> <var>x</var> = projected.getOrdinate(0);
-<b>double</b> <var>y</var> = projected.getOrdinate(1);</pre>
-
-</td>
-</tr>
-</table>
-
-<p>La dérivée de la projection cartographique en ce même point peut se représenter par une matrice Jacobienne:</p>
-
-<table class="hidden">
-<tr>
-<th>Équation</th>
-<th>Code Java</th>
+<h3 id="Ellipsoid"><span class="section-number">5.1.1.</span> 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 class="GeoAPI">Ellipsoid</code>,
+qui constitue un élément fondamental des systèmes de références de type <code class="GeoAPI">GeographicCRS</code> et <code class="GeoAPI">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>
+
+<h3 id="GeodeticDatum"><span class="section-number">5.1.2.</span> 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 class="GeoAPI">Ellipsoid</code> à la surface de la Terre (par exemple la position de son centre)
+sont représentées par un objet de type <code class="GeoAPI">GeodeticDatum</code>, que l’on traduit en français par « référentiel géodésique ».
+Plusieurs <code class="GeoAPI">GeodeticDatum</code> peuvent utiliser le même <code class="GeoAPI">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 class="GeoAPI">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 class="GeoAPI">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>
+
+<h3 id="CoordinateSystem"><span class="section-number">5.1.3.</span> Systèmes de coordonnées</h3>
+<p style="color: red">TODO</p>
+
+<h4 id="AxisOrder"><span class="section-number">5.1.3.1.</span> 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 title="Coordinate Reference System">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 class="GeoAPI">GeographicCRS</code>, pour certains <code class="GeoAPI">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 title="Open Geospatial Consortium">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 title="Spatial Information System">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>.

[... 2263 lines stripped ...]


Mime
View raw message