sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1814367 [3/3] - in /sis/site/trunk/content/book: en/developer-guide.html fr/developer-guide.html
Date Sun, 05 Nov 2017 18:04:55 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=1814367&r1=1814366&r2=1814367&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] Sun Nov  5 18:04:55 2017
@@ -1,16 +1,15 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="UTF-8" standalone="no"?><!--
 
-<!--
   Licensed to the Apache Software Foundation (ASF)
 
       http://www.apache.org/licenses/LICENSE-2.0
 
   This is an automatically generated file. DO NOT EDIT.
   See the files in the ../../../book/ directory instead.
--->
 
-<!DOCTYPE html>
+--><!DOCTYPE html SYSTEM "about:legacy-compat">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
+
 <head>
 <title>Introduction à Apache SIS</title>
 <meta charset="UTF-8"/>
@@ -30,8 +29,6 @@
 <li><a href="#Standards">Standards et normes</a><ul>
 <li><a href="#ConceptualModels">Sources des modèles conceptuels de Apache SIS</a></li>
 <li><a href="#GeoAPI">Des modèles conceptuels vers des interfaces Java: GeoAPI</a><ul>
-<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="#AboutBook">Conventions utilisées dans ce guide</a><ul>
 <li><a href="#CodeColors">Code de couleurs</a></li></ul></li></ul></li>
@@ -79,20 +76,25 @@
 <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="#Annexes">Annexes</a><ul>
+<li><a href="#GeoAPI-details">Relation entre GeoAPI et les standards</a><ul>
+<li><a href="#GeoAPI-modules">Les modules de GeoAPI</a></li>
+<li><a href="#SpecificationToInterfaces">Des spécifications de l’OGC aux interfaces Java</a><ul>
+<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></ul></li>
 <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>
 <li><a href="#ServiceLoader">Obtenir une implémentation des interfaces de GeoAPI</a><ul>
-<li><a href="#GeoAPI-simple">Fournir sa propre implémentation</a></li></ul></li></ul></li>
+<li><a href="#GeoAPI-simple">Fournir sa propre implémentation</a></li></ul></li></ul></li></ul></li>
 <li><a href="#Tests">Les suites de tests</a><ul>
+<li><a href="#GeoAPI-conformance">Conformance avec GeoAPI</a><ul>
 <li><a href="#GeoAPI-validators">Validations des instances</a></li>
-<li><a href="#GeoAPI-tests">Exécution des tests pré-définis</a></li></ul></li>
+<li><a href="#GeoAPI-tests">Exécution des tests pré-définis</a></li></ul></li></ul></li>
 <li><a href="#DesignNotes">Notes de design</a><ul>
 <li><a href="#AffineTransform">Utilisation des transformations affines</a><ul>
 <li><a href="#AffineTransformAPI">Intégration avec les bibliothèques graphiques</a></li></ul></li>
 <li><a href="#MatrixLibrary">Particularités d’une bibliothèque de calculs matriciels pour un SIG</a><ul>
 <li><a href="#NonSquareMatrix">Que faire des matrices qui ne sont pas carrées (et pourquoi)</a></li>
-<li><a href="#MatrixLibrarySummary">La bibliothèque matricielle de Apache SIS</a></li></ul></li></ul></li></ul></li>
+<li><a href="#MatrixLibrarySummary">La bibliothèque matricielle de Apache SIS</a></li></ul></li></ul></li>
 </ul>
 </nav>
 
@@ -107,6 +109,8 @@
 
 
 
+
+
 <section>
 <header>
 <h1 id="Standards"><span class="section-number">1.</span> Standards et normes</h1>
@@ -115,8 +119,6 @@
 <nav>Dans ce chapitre:<ul class="toc">
 <li><a href="#ConceptualModels">Sources des modèles conceptuels de Apache SIS</a></li>
 <li><a href="#GeoAPI">Des modèles conceptuels vers des interfaces Java: GeoAPI</a><ul>
-<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="#AboutBook">Conventions utilisées dans ce guide</a><ul>
 <li><a href="#CodeColors">Code de couleurs</a></li></ul></li></ul></nav>
@@ -217,8 +219,8 @@ hébergées par des organisations membre
 Le continent hôte alterne entre l’Europe et l’Amérique du Nord, avec une présence croissante en Asie depuis 2011.
 Ces réunions reçoivent habituellement entre 50 et 100 participants parmi les centaines de membres de l’<abbr>OGC</abbr>.
 Certains participants sont présents à quasiment toutes les réunions et constituent des piliers de l’organisation.
-</p><p>
 Les réunions de l’<abbr>OGC</abbr> offrent des opportunités d’échanges avec des membres d’horizons diverses.
+</p><p>
 La création d’un standard <abbr>OGC</abbr> commence par le regroupement d’organisations ou d’individus constatant un intérêt commun pour une problématique.
 Un groupe de travail est proposé sous l’appellation de <i>Domain Working Group</i> (<abbr>DWG</abbr>) ou <i>Standard Working Group</i> (<abbr>SWG</abbr>).
 Les <abbr>DWG</abbr> sont ouverts à tout membre de l’<abbr>OGC</abbr>,
@@ -466,12 +468,6 @@ Enfin, les paquets GeoAPI seront introdu
 <td/>
 <td><code class="SIS">org.apache.sis.io.wkt</code></td>
 </tr><tr>
-<td><abbr>ISO</abbr> 13249</td>
-<td/>
-<td><i><abbr>SQL</abbr> spatial</i></td>
-<td/>
-<td/>
-</tr><tr>
 <td/>
 <td><s><abbr>OGC</abbr> 01-009</s></td>
 <td><s><i>Coordinate Transformation Services</i></s></td>
@@ -485,6 +481,24 @@ Enfin, les paquets GeoAPI seront introdu
 <td><code class="SIS">org.apache.sis.coverage</code></td>
 </tr><tr>
 <td/>
+<td><abbr>OGC</abbr> 10-092</td>
+<td><i>NetCDF binary encoding: classic and 64-bit offset format</i></td>
+<td/>
+<td><code class="SIS">org.apache.sis.storage.netcdf</code></td>
+</tr><tr>
+<td/>
+<td><abbr>OGC</abbr> 14-084</td>
+<td><i>Moving features Comma Separated Values (CSV) encoding</i></td>
+<td/>
+<td><code class="SIS">org.apache.sis.storage</code></td>
+</tr><tr>
+<td><abbr>ISO</abbr> 13249</td>
+<td/>
+<td><i><abbr>SQL</abbr> spatial</i></td>
+<td/>
+<td/>
+</tr><tr>
+<td/>
 <td><abbr>SLD</abbr></td>
 <td><i>Styled Layer Descriptor</i></td>
 <td><code class="GeoAPI">org.opengis.style</code></td>
@@ -633,2116 +647,2087 @@ Cette version a été la première à ê
 </article>
 </details>
 
-<p>Les interfaces Java du projet GeoAPI sont parfois générées à partir d’autres fichiers fournis par l’<abbr>OGC</abbr>,
-tels que les fichiers <abbr title="XML Schema Definition">XSD</abbr>. Mais il y a toujours une révision manuelle, et très souvent des modifications
-par rapport aux fichiers générés par des processus automatiques.
-Les écarts par rapport aux normes sont documentés dans chaque classe et chaque méthode concernées.
-Chaque mention d’un écart est aussi recopiée dans <a href="http://www.geoapi.org/3.0/javadoc/departures.html">une page unique</a>,
-pour donner une vue d’ensemble.
-Étant donné que ces écarts brouillent les liens qui existent entre les standards et certaines interfaces Java,
-la correspondance entre ces langages est explicitée par des annotations <code class="GeoAPI">@UML</code>
-et des fichiers de propriétés, décrits dans la section suivante.
+<p id="GeoAPI-core">
+GeoAPI est constitué de plusieurs modules.
+Les modules <code class="GeoAPI">geoapi</code> et <code class="GeoAPI">geoapi-pending</code>
+fournissent les interfaces dérivées des schémas <abbr title="Unified Modeling Language">UML</abbr> des standards internationaux.
+Le modèle conceptuel sera expliqué en détails dans les chapitres décrivant l’implémentation Apache <abbr title="Spatial Information System">SIS</abbr>.
+On peut toutefois avoir un aperçu de son contenu en consultant la page listant les
+<a href="http://www.geoapi.org/3.0/javadoc/content.html">types et méthodes de GeoAPI et les standards d’où ils proviennent</a>.
+Ces modules ainsi que la correspondance entre GeoAPI et les standards internationaux sont décrits plus en détails
+<a href="#SpecificationToInterfaces">en annexe</a>.
 </p>
 
-<details>
-<summary>Pour en savoir plus sur les raisons d’une définition manuelle des interfaces Java</summary>
-<article id="SpecificationToInterfaces">
+
+
+<h3 id="GeoAPI-implementation"><span class="section-number">1.2.1.</span> Implémentations fournies par Apache SIS</h3>
+<p>
+Apache SIS implémente la plupart des interfaces de GeoAPI avec une classe du même nom que l’interface,
+mais préfixée de « <code>Abstract</code> », « <code>Default</code> » ou « <code>General</code> ».
+Les classes de Apache SIS qui sont préfixées par « <code>Default</code> » peuvent être instanciées directement
+par une instruction <code>new DefaultXXX(…)</code> ou par la méthode <code>createXXX(…)</code> correspondante d’une fabrique.
+</p>
+<div class="example"><b>Example:</b> pour représenter un système de référence de coordonnées projetées (Mercator, Lambert, <i>etc</i>):
+<ul>
+<li><code class="GeoAPI">org.opengis.referencing.crs.ProjectedCRS</code> est l’interface définie par GeoAPI sur la base du standard ISO 19111, et</li>
+<li><code class="SIS">org.apache.sis.referencing.crs.DefaultProjectedCRS</code> est l’implémentation fournie par Apache SIS.</li>
+</ul>
+Une instance peut être créée par:
+<ul>
+<li><code>ProjectedCRS crs = new DefaultProjectedCRS(…)</code>, ou</li>
+<li><code>ProjectedCRS crs = CRSFactory​.createProjectedCRS(…)</code>.</li>
+</ul>
+Les deux approches attendent les mêmes arguments (omis dans cet exemple).
+</div>
+<p>
+Dans la configuration par défaut de Apache SIS,
+utiliser <code class="GeoAPI">CRSFactory​.createXXX(…)</code> ou <code>new DefaultXXX(…)</code> revient presque au même
+excepté que les <code class="GeoAPI">Factory</code> peuvent retourner des instances existantes
+plutôt que de créer systématiquement de nouvelles instances,
+et que les exceptions en cas d’arguments invalides sont de types différents.
+Dans des configurations plus avancées, l’usage des <code class="GeoAPI">Factory</code> permet de
+<a href="#ServiceLoader">réduire la dépendance directe d’une application envers SIS</a>
+et de permettre une inversion de contrôle.
+</p><p>
+Le préfix « <code>General</code> » est parfois utilisé à la place de « <code>Default</code> »
+afin de signaler que des implémentations alternatives existent pour des cas spécifiques.
+Par exemple l’interface <code>Envelope</code> est implémentée par au moins deux classes de Apache SIS:
+<code class="SIS">GeneralEnvelope</code> et <code>Envelope2D</code>.
+La première implémentation peut représenter des enveloppes de n’importe quelle dimension
+alors que la seconde implémentation est spécialisée pour les enveloppes à deux dimensions.
+</p><p>
+Les classes de Apache SIS qui sont préfixées par « <code>Abstract</code> » ne doivent pas – en principe – être instanciées.
+Il faut plutôt instancier une sous-classe non-abstraites.
+Toutefois plusieurs classes de SIS ne sont abstraites que conceptuellement,
+sans que la définition de la classe ne contienne le mot-clé <code>abstract</code> du Java.
+Ces classes peuvent être instanciées par l’instruction <code>new AbstractXXX(…)</code>
+– mais pas par les <code class="GeoAPI">Factory</code> – malgré qu’elles soient conceptuellement abstraites.
+Mais ces instanciations ne devraient être faites qu’en dernier recours,
+lorsqu’il n’est vraiment pas possible de déterminer le sous-type exact.
+</p>
+</section>
+
+
+<section>
 <header>
-<h2>Des spécifications de l’<abbr title="Open Geospatial Consortium">OGC</abbr> aux interfaces Java</h2>
+<h2 id="AboutBook"><span class="section-number">1.3.</span> Conventions utilisées dans ce guide</h2>
 </header>
 <p>
-Il est possible de générer automatiquement des interfaces Java à partir des standards de l’<abbr>OGC</abbr> à l’aide d’outils existants.
-Une des approches les plus utilisées est de transformer les <a href="http://schemas.opengis.net/gml/3.3/">schémas <abbr title="XML Schema Definition">XSD</abbr></a>
-en interfaces Java à l’aide de l’utilitaire en ligne de commande <code>xjc</code>.
-Cet utilitaire étant fournit avec la plupart des distributions du Java (il fait partie des outils de <a href="http://jaxb.java.net"><abbr>JAXB</abbr></a>),
-cette approche est choisie par plusieurs projets que l’on trouve sur internet.
-D’autres approches utilisent des outils intégrés à l’environnement de développement Eclipse,
-ou prennent comme point de départ les schémas <abbr title="Unified Modeling Language">UML</abbr> plutôt que <abbr>XSD</abbr>.
+Les standards privilégient parfois l’application de certains termes génériques à des contextes particuliers,
+qui peuvent différer du contexte dans lequel d’autres communautés emploient ces termes.
+Par exemple les termes <i>domain</i> et <i>range</i> peuvent s’appliquer à des fonctions arbitraires
+pour désigner l’ensemble des valeurs possibles en entrés et en sorties respectivement.
+Mais les fonctions auxquelles certains standards <abbr title="International Organization for Standardization">ISO</abbr>
+les appliquent ne sont pas les mêmes que les fonctions auxquelles d’autres bibliothèques les appliquent.
+Par exemple <abbr>ISO</abbr> 19123 applique ces termes aux objets <code class="OGC">CV_Coverage</code>,
+vus comme des fonctions dont le domaine est l’ensemble des coordonnées spatio-temporelles de la couverture de données
+et le <i>range</i> l’ensemble des valeurs de la couverture.
+Mais la bibliothèque <abbr title="Network Common Data Form">netCDF</abbr> de l’<abbr title="University Corporation for Atmospheric Research">UCAR</abbr>
+applique plutôt ces termes à la fonction convertissant les indices de pixels (son domaine) vers les coordonnées spatio-temporelles (son <i>range</i>).
+Ainsi, un <i>range</i> de la bibliothèque de l’<abbr>UCAR</abbr> peut être le domaine de <abbr>ISO</abbr> 19123.
 </p><p>
-Une approche similaire avait été tentée dans les débuts du projet GeoAPI, mais a été rapidement abandonnée.
-Nous avons privilégié une approche manuelle pour les raisons suivantes:
+La bibliothèque Apache <abbr title="Spatial Information System">SIS</abbr> privilégie autant que possible l’utilisation des termes dans le sens des normes <abbr title="Open Geospatial Consortium">OGC</abbr> et <abbr>ISO</abbr>.
+Mais un soin particulier doit être apporté aux interfaces entre <abbr>SIS</abbr> et certaines bibliothèques externes, afin de réduire les risques de confusions.
 </p>
-<ul>
-<li>
+
+
+
+<h3 id="CodeColors"><span class="section-number">1.3.1.</span> Code de couleurs</h3>
 <p>
-Certains schémas <abbr>XSD</abbr> sont beaucoup plus verbeux que les schémas <abbr>UML</abbr> d’origines.
-Une conversion à partir des schémas <abbr>XSD</abbr> introduit, au moins dans le cas des méta-données,
-près du double du nombre d’interfaces réellement définies par le standard, sans que cela n’apporte de nouvelles fonctionnalités.
-Les schémas <abbr>XSD</abbr> définissent aussi des attributs propres aux documents <abbr>XML</abbr>
-(<code class="OGC">id</code>, <code class="OGC">uuid</code>, <code>xlink:href</code>, <i>etc.</i>),
-qui n’existent pas dans les diagrammes <abbr>UML</abbr> originaux et que l’on ne souhaite pas forcément exposer dans un <abbr title="Application Programming Interface">API</abbr> Java.
-Une conversion à partir des schémas <abbr>UML</abbr> évite ce problème, mais les outils capable d’effectuer cette opération sont plus rares.
+Les éléments définis dans un langage informatique, tels que les classes ou méthodes en Java
+ainsi que les éléments dans un fichier <abbr>XML</abbr>, apparaissent avec une police de caractères mono-espacée.
+Afin de faciliter la compréhension des liens qui existent entre Apache <abbr title="Spatial Information System">SIS</abbr> et les standards,
+ces éléments sont en outre représentés en utilisant les codes de couleurs suivants:
 </p>
-<div class="example"><p><b>Exemple:</b>
-Les schémas <abbr>XSD</abbr> des méta-données insèrent
-un élément <code class="OGC">&lt;gmd:CI_Citation&gt;</code> à l’intérieur de <code class="OGC">&lt;gmd:citation&gt;</code>,
-un élément <code class="OGC">&lt;gmd:CI_OnlineResource&gt;</code> à l’intérieur de <code class="OGC">&lt;gmd:onlineResource&gt;</code>,
-et ainsi de suite pour la centaine de classes définies dans le standard <abbr title="International Organization for Standardization">ISO</abbr> 19115.
-Cette redondance n’est absolument pas nécessaire à un programme Java.
-</p></div>
-</li>
+<ul>
 <li>
-<p>
-Les standards de l’<abbr>OGC</abbr> utilisent des conventions de nommage qui sont différentes de celles du Java.
-En particulier les noms de presque toutes les classes de l’<abbr>OGC</abbr> commencent par un préfixe de deux lettres,
-comme dans <code class="OGC">MD_Identifier</code>. Ces préfixes jouent le même rôle que les noms de paquets en Java.
-GeoAPI adapte cette pratique en utilisant des noms d’interfaces sans préfixes,
-et en plaçant ces interfaces dans des paquets correspondants aux préfixes mais avec des noms plus descriptifs.
-Occasionnellement nous changeons aussi les noms, par exemple pour éviter des acronymes
-ou pour se conformer à une convention établie telle que <i>Java beans</i>.
-</p>
-<div class="example"><p><b>Exemple:</b>
-la classe <code class="OGC">MD_Identifier</code> de l’<abbr>OGC</abbr> devient
-l’interface <code class="GeoAPI">Identifier</code> dans le paquet <code class="GeoAPI">org.opengis.metadata</code>.
-La classe <code class="OGC">SC_CRS</code> de l’<abbr>OGC</abbr> devient l’interface <code class="GeoAPI">CoordinateReferenceSystem</code>,
-et l’association <code class="OGC">usesDatum</code> devient une méthode <code class="GeoAPI">getDatum()</code> — et non pas
-« <code>getUsesDatum()</code> » comme aurait fait un outil de conversion automatique.
-Nous ne laissons pas des programmes appliquer aveuglement des règles qui ignorent les conventions de la communauté dont on traduit les schémas.
-</p></div>
+Les éléments définis dans un standard de l’<abbr title="Open Geospatial Consortium">OGC</abbr>
+ou de l’<abbr title="International Organization for Standardization">ISO</abbr> apparaissent en bleu.
+Exemple: <code class="OGC">CD_Ellipsoid</code>.
 </li>
 <li>
-<p>
-Les standards contiennent parfois des structures qui n’ont pas d’équivalent direct en Java,
-notamment les unions telles qu’on peut trouver en C/C++.
-La stratégie employée pour obtenir une fonctionnalité équivalente en Java dépend du contexte:
-multi-héritage des interfaces, modification de la hiérarchie ou simplement omettre l’union.
-Les décisions se font au cas-par-cas en fonction de l’analyse des besoins.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Le standard <abbr>ISO</abbr> 19111 définit différents types de systèmes de coordonnées, tels que sphérique, cylindrique, polaire ou cartésien.
-Puis, il définit différents <em>sous-ensembles</em> de ces types de systèmes de coordonnées.
-Ces sous-ensembles, représentés par des unions, servent à spécifier qu’une classe peut être associée à seulement tel ou tel type de système de coordonnées.
-Par exemple l’union des types pouvant être associés à une image, nommée <code class="OGC">CS_ImageCS</code>,
-ne contient que <code class="OGC">CS_CartesianCS</code> et <code class="OGC">CS_AffineCS</code>.
-Dans ce cas particulier, nous obtenons en Java l’effet souhaité par une modification de la hiérarchie des classes:
-nous définissons l’interface <code class="GeoAPI">CartesianCS</code> comme une spécialisation de <code class="GeoAPI">AffineCS</code>, ce qui est sémantiquement correct.
-Mais il n’est pas possible d’appliquer une stratégie similaire pour les autres unions sans violer la sémantique.
-</p></div>
+Les éléments définis dans GeoAPI apparaissent en vert.
+Exemple: <code class="GeoAPI">Ellipsoid</code>.
 </li>
 <li>
-<p>
-Plusieurs spécifications se chevauchent. GeoAPI effectue un travail d’intégration en remplaçant certaines
-structures qui font doublons par des références vers les structures équivalentes du standard qui les définies le mieux.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Le standard <abbr>ISO</abbr> 19115, qui définit des structures de méta-données, s’aventure aussi à décrire quelques
-structures représentant les systèmes de références des coordonnées (<abbr title="Coordinate Reference System">CRS</abbr>).
-Or ces derniers sont le sujet à part entière d’un autre standard: <abbr>ISO</abbr> 19111.
-D’ailleurs le standard <abbr>ISO</abbr> 19111:2007 stipule, dans sa section 3, qu’il réutilise tous les éléments
-de <abbr>ISO</abbr> 19115 à l’exclusion de <code class="OGC">MD_CRS</code> et de ses composantes.
-Les interfaces de GeoAPI réduisent la redondance en appliquant à l’ensemble du projet l’exclusion recommandée par <abbr>ISO</abbr> 19111.
-</p></div>
+Les éléments définis dans Apache <abbr title="Spatial Information System">SIS</abbr> apparaissent en brun.
+Exemple: <code class="SIS">DefaultEllipsoid</code>.
 </li>
 <li>
-<p>
-Certains standards ont vu leur complexité s’accroître pour des raisons historiques plutôt que techniques,
-liées au processus de standardisation. GeoAPI réduit la dette technique en concevant les interfaces comme
-si chaque élément avait pu être intégré à sa place, sans les contraintes liées à l’ordre chronologique
-dans lequel les standards ont été publiés.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Le standard <abbr>ISO</abbr> 19115-2 est une extension du standard <abbr>ISO</abbr> 19115-1 ajoutant des structures de méta-données d’images.
-Ces méta-données ont été définies dans un standard séparé parce qu’elles n’ont pas été prêtes à temps pour la publication de la première partie du standard.
-Comme il n’était pas possible, pour des raisons administratives, d’ajouter des attributs dans les classes déjà publiées,
-les nouveaux attributs ont été ajoutées dans une sous-classe portant quasiment le même nom.
-Ainsi, le standard <abbr>ISO</abbr> 19115-2 définit une classe <code class="OGC">MI_Band</code> qui étend la
-classe <code class="OGC">MD_Band</code> du standard <abbr>ISO</abbr> 19115-1 en y ajoutant les attributs qui
-auraient dû apparaître directement dans la classe parente s’ils avaient été prêts à temps.
-Dans GeoAPI, nous avons choisis de « réparer » ces anomalies en fusionnant ces deux classes en une seule interface.
-</p></div>
+Les autres éléments, notamment ceux du Java standard, sont laissés en noir.
+Exemple: <code>String</code>.
 </li>
 </ul>
-</article>
-</details>
-
-<p id="GeoAPI-core">
-GeoAPI est constitué de plusieurs modules.
-Les modules <code class="GeoAPI">geoapi</code> et <code class="GeoAPI">geoapi-pending</code>
-fournissent les interfaces dérivées des schémas <abbr>UML</abbr> des standards internationaux.
-Le modèle conceptuel sera expliqué en détails dans les chapitres décrivant l’implémentation Apache <abbr title="Spatial Information System">SIS</abbr>.
-On peut toutefois avoir un aperçu de son contenu en consultant la page listant les
-<a href="http://www.geoapi.org/3.0/javadoc/content.html">types et méthodes de GeoAPI et les standards d’où ils proviennent</a>.
+<p>
+Des compléments d’information apparaissent dans des boîtes grises.
+Le lecteur peut ignorer ces boîtes grises sans que cela ne nuise à la compréhension du texte.
 </p>
+</section>
+</section>
 
-<details>
-<summary>Pour en savoir plus sur les modules de GeoAPI</summary>
-<article id="GeoAPI-modules">
-<h2>Les modules de GeoAPI</h2>
+
+<section>
+<header>
+<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"/></nav>
 <p>
-Le projet GeoAPI est composé d’une partie standardisée (<code class="GeoAPI">geoapi</code>) et
-d’une partie expérimentale (<code class="GeoAPI">geoapi-pending</code>). Ces deux parties étant
-mutuellement exclusives, les utilisateurs doivent veiller à ne pas les mélanger dans un même projet.
-Cette séparation est garantie pour tous les projets qui ne dépendent que du dépôt central de Maven
-(incluant les versions finales de Apache <abbr title="Spatial Information System">SIS</abbr>),
-car le module <code class="GeoAPI">geoapi-pending</code> n’est jamais déployé sur ce dépôt central.
-En revanche certaines branches de développement de <abbr>SIS</abbr> peuvent dépendre de <code class="GeoAPI">geoapi-pending</code>.
-</p><p>
-Les modules de GeoAPI sont:
+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 traduit 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 standard dans le paquet <code>javax.imageio.metadata</code>.
+Pour Apache <abbr>SIS</abbr>, le modèle pivot choisi 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éfini,
+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>
+<div class="example"><p><b>Exemple:</b>
+le code suivant lit un fichier de méta-données d’une image Landsat-8 et affiche les limites géographiques qui y sont déclarées:
 </p>
-<ul>
-<li><p>
-<b><code class="GeoAPI">geoapi</code></b> — contient les interfaces couvertes par le
-<a href="http://www.opengeospatial.org/standards/geoapi">standard GeoAPI de l’<abbr title="Open Geospatial Consortium">OGC</abbr></a>.
-Les versions finales de Apache <abbr>SIS</abbr> dépendent de ce module.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-pending</code></b> — contient une
-<em>copie</em> de toutes les interfaces du module <code class="GeoAPI">geoapi</code>
-(non pas une dépendance) avec des ajouts qui n’ont pas encore été approuvés comme un standard <abbr>OGC</abbr>.
-Certains ajouts apparaissent dans des interfaces normalement définies par le module <code class="GeoAPI">geoapi</code>,
-d’où la nécessité de les copier.
-Les branches de développement
-<code>jdk7</code> et <code>jdk8</code> de Apache <abbr>SIS</abbr> dépendent de ce module,
-mais cette dépendance est transformée en une dépendance vers le module <code class="GeoAPI">geoapi</code>
-standard au moment de fusionner les branches avec le tronc.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-conformance</code></b> — contient
-une suite de tests JUnit que les développeurs peuvent utiliser pour tester leurs implémentations.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-examples</code></b> — contient des
-exemples d’implémentations relativement simples. Ces exemples sont placés dans le domaine public
-afin d’encourager les utilisateurs à les copier et les adapter à leurs besoins si les services
-de Apache <abbr>SIS</abbr> ne conviennent pas.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-proj4</code></b> — contient une
-implémentation partielle des paquets <code class="GeoAPI">org.opengis.referencing</code>
-sous forme d’adaptateurs basés sur la bibliothèque C/C++ Proj.4.
-Ce module peut être utilisé comme alternative au module <code class="SIS">sis-referencing</code>
-pour certaines fonctions.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-netcdf</code></b> — contient une implémentation partielle des paquets
-<code class="GeoAPI">org.opengis.referencing</code> et <code class="GeoAPI">org.opengis.coverage</code>
-sous forme d’adaptateurs basés sur la bibliothèque <abbr>NetCDF</abbr> de l’<abbr>UCAR</abbr>.
-La suite de tests de ce module a été conçue de manière à être réutilisable par d’autres projets.
-Apache <abbr>SIS</abbr> l’utilise pour tester son propre module <code class="SIS">sis-netcdf</code>.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-openoffice</code></b> — contient
-un <i>add-in</i> pour les suites bureautiques Libre/OpenOffice.org.
 
-</p></li>
-</ul>
-</article>
-</details>
+<pre><code><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);
+}</code></pre>
 
-<h3 id="UML-annotation"><span class="section-number">1.2.1.</span> Correspondances explicites entre GeoAPI et les spécifications abstraites</h3>
 <p>
-Pour chaque classe, méthode et constante définie à partir d’un standard <abbr title="Open Geospatial Consortium">OGC</abbr> ou <abbr title="International Organization for Standardization">ISO</abbr>,
-GeoAPI indique sa provenance à l’aide d’annotations définies dans le paquet <code class="GeoAPI">org.opengis.annotation</code>.
-En particulier l’annotation <code class="GeoAPI">@UML</code> indique le standard,
-le nom de l’élément dans ce standard ainsi que son niveau d’obligation.
-Par exemple dans l’extrait de code suivant, la première annotation <code class="GeoAPI">@UML</code> indique
-que l’interface Java qui la suit (<code class="GeoAPI">ProjectedCRS</code>) est définie à partir du type
-<code class="OGC">SC_ProjectedCRS</code> du standard <abbr>ISO</abbr> 19111.
-La seconde annotation <code class="GeoAPI">@UML</code>, appliquée cette fois à la méthode
-<code class="GeoAPI">getCoordinateSystem()</code>, indique que la méthode est définie
-à partir de l’association <code class="OGC">coordinateSystem</code> du standard <abbr>ISO</abbr> 19111,
-et que cette association est obligatoire — ce qui, traduit en Java, signifie que la méthode n’est
-pas autorisée à retourner la valeur <code>null</code>.
+Cet exemple produit la sortie suivante (la région est située au Vietnam):
 </p>
 
-<pre><code><b>package</b> <code class="GeoAPI">org.opengis.referencing.crs</code>;
+<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>
 
-  <code class="comment">/**
-   * A 2D coordinate reference system used to approximate the shape of the earth on a planar surface.
-   */</code>
-  @<code class="GeoAPI">UML</code>(specification=ISO_19111, identifier=<i>"<code class="OGC">SC_ProjectedCRS</code>"</i>)
-  <b>public</b> <b>interface</b> <code class="GeoAPI">ProjectedCRS</code> <b>extends</b> <code class="GeoAPI">GeneralDerivedCRS</code> {
-      <code class="comment">/**
-       * Returns the coordinate system, which must be Cartesian.
-       */</code>
-      @<code class="GeoAPI">UML</code>(obligation=MANDATORY, specification=ISO_19111, identifier=<i>"<code class="OGC">coordinateSystem</code>"</i>)
-      <code class="GeoAPI">CartesianCS</code> <code class="GeoAPI">getCoordinateSystem()</code>;
-  }</code></pre>
+<p>
+Le code Java dans cet exemple extrait des éléments de méta-données par des appels à des méthodes Java telles que <code class="GeoAPI">getExtents()</code>,
+mais les chapitres suivants introduiront d’autres façons utilisant des identifiants sous forme de chaînes de caractères.
+Ces approches alternatives sont plus pratiques lorsque l’on ne connaît pas à l’avance les méthodes à appeler.
+</p>
+</div>
 
 <p>
-Les méthodes d’introspections du Java permettent d’accéder à ces informations pendant l’exécution d’une application.
-C’est utile pour obtenir les noms à afficher à des utilisateurs familiers avec les normes de l’<abbr>OGC</abbr>,
-ou pour écrire des éléments dans un document <abbr>XML</abbr>.
-La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit des méthodes de commodité
-telles que <code class="SIS">getStandardName(Class)</code> pour effectuer cette opération.
-Par exemple le code suivant affichera
-« Le nom standard du type <code class="GeoAPI">org.opengis.referencing.crs.ProjectedCRS</code> est <code class="OGC">SC_ProjectedCRS</code> »:
+La norme <abbr>ISO</abbr> 19115 définit des centaines d’éléments.
+Certains de ces éléments seront introduits progressivement dans les chapitres suivants.
+Mais afin de donner une petite idée de ce qui est disponible, le tableau suivant en liste quelques uns.
+La plupart des noeuds acceptent un nombre arbitraire de valeurs.
+Par exemple il peut y avoir plusieurs zones géographiques décrites sous le noeud <code class="OGC">extent</code>.
 </p>
 
-<pre><code>Class&lt;?&gt; type = <code class="GeoAPI">ProjectedCRS</code>.<b>class</b>;
-System.out.println(<i>"Le nom standard du type "</i> + type.getName() + <i>" est "</i> + Types.getStandardName(type));</code></pre>
+<table style="line-height:1">
+<caption>Quelques éléments de méta-données extraits de ISO 19115</caption>
+<tr><th>Élément</th>                                <th>Description</th></tr>
+<tr><td style="padding-top:9px">Metadata</td>       <td style="padding-top:9px">Méta-données à propos d’un jeu de données, d’un service ou autres ressources.</td></tr>
+<tr><td>  ├─Reference system info</td>              <td>Description du système de référence spatial et temporel utilisé dans le jeu de données.</td></tr>
+<tr><td>  ├─Identification info</td>                <td>Information de base à propos de la ressource décrite par les méta-données.</td></tr>
+<tr><td>  │   ├─Citation</td>                       <td>Nom selon lequel la ressource est connue, ainsi que des dates de références, la forme de présentation, <i>etc.</i></td></tr>
+<tr><td>  │   │   └─Cited responsible party</td>    <td>Rôle, nom, contact et position des individus ou organisations qui sont responsables de la ressource.</td></tr>
+<tr><td>  │   ├─Topic category</td>                 <td>Principaux thèmes de la ressource (agriculture, climatologie, environnement, économie, santé, transport, <i>etc.</i>).</td></tr>
+<tr><td>  │   ├─Descriptive keywords</td>           <td>Mots-clés, leurs types, et référence vers la source les définissant.</td></tr>
+<tr><td>  │   ├─Spatial resolution</td>             <td>Facteur (échelle, taille de pixel) donnant une idée globale de la densité spatiale des données de la ressource.</td></tr>
+<tr><td>  │   ├─Temporal resolution</td>            <td>La plus petite période temporelle pouvant être résolue dans la ressource.</td></tr>
+<tr><td>  │   ├─Extent</td>                         <td>Étendue spatiale et temporelle de la ressource.</td></tr>
+<tr><td>  │   ├─Resource format</td>                <td>Description du format de la ressource.</td></tr>
+<tr><td>  │   ├─Resource maintenance</td>           <td>Information sur la fréquence des mises-à-jours de la ressources, ainsi que la portée de ces mises-à-jours.</td></tr>
+<tr><td>  │   └─Resource constraints</td>           <td>Information sur les contraintes légales ou de sécurités qui s’appliquent à la ressource.</td></tr>
+<tr><td>  ├─Content info</td>                       <td>Information sur le catalogue d’entités ainsi que les caractéristiques des couvertures de données ou images.</td></tr>
+<tr><td>  │   ├─Imaging condition</td>              <td>Conditions qui affectent les images (image floue, brouillard, semi-obscurité, <i>etc.</i>).</td></tr>
+<tr><td>  │   ├─Cloud cover percentage</td>         <td>Proportion des données masquées par les nuages, comme pourcentage de l’étendue spatiale.</td></tr>
+<tr><td>  │   └─Attribute group</td>                <td>Information sur les groupes d’attributs de la ressource.</td></tr>
+<tr><td>  │       ├─Content type</td>               <td>Types d’information représentée par les valeurs (classification thématique, mesures physiques, <i>etc.</i>).</td></tr>
+<tr><td>  │       └─Attribute</td>                  <td>Information sur un attribut d’une ressource.</td></tr>
+<tr><td>  │           ├─Sequence identifier</td>    <td>Nom ou numéro unique qui identifie l’attribut dans une couverture de données.</td></tr>
+<tr><td>  │           ├─Peak response</td>          <td>Longueur d’onde à laquelle la réponse du capteur est maximale.</td></tr>
+<tr><td>  │           ├─Min/max value</td>          <td>Valeur minimale/maximale des données pour chaque dimension d’échantillonage inclue dans la ressource.</td></tr>
+<tr><td>  │           ├─Units</td>                  <td>Unités de mesures pour chaque dimension d’échantillonage inclue dans la ressource.</td></tr>
+<tr><td>  │           └─Transfer function type</td> <td>Type de fonction de transfert utilisée pour convertir un élément en valeur physique.</td></tr>
+<tr><td>  ├─Distribution info</td>                  <td>Information sur les distributeurs et les façons d’obtenir la ressource.</td></tr>
+<tr><td>  │   ├─Distribution format</td>            <td>Description des formats dans lesquels les données peuvent être distribuées.</td></tr>
+<tr><td>  │   └─Transfer options</td>               <td>Moyens techniques et médias par lesquels une ressource peut être obtenue à partir de son distributeur.</td></tr>
+<tr><td>  ├─Data quality info</td>                  <td>Évaluation globale de la qualité de la ressource.</td></tr>
+<tr><td>  ├─Acquisition information</td>            <td>Information sur l’acquisition des données.</td></tr>
+<tr><td>  │   ├─Environmental conditions</td>       <td>Conditions environnementales dans lesquels les données ont été acquises.</td></tr>
+<tr><td>  │   └─Platform</td>                       <td>Information générale sur la plate-forme à partir de laquelle les données ont été acquises.</td></tr>
+<tr><td>  │       └─Instrument</td>                 <td>Instruments montées sur la plate-forme.</td></tr>
+<tr><td>  └─Resource lineage</td>                   <td>Information sur la provenance, les sources et/ou les étapes de production de la ressource.</td></tr>
+<tr><td>      ├─Source</td>                         <td>Information sur les données sources utilisées pour créer les données décrites par les méta-données.</td></tr>
+<tr><td>      └─Process step</td>                   <td>Historique des événements survenues dans la productions des données.</td></tr>
+</table>
+</section>
+
 
+<section>
+<header>
+<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>
-La méthode de commodité <code class="SIS">Types​.forStandardName(String)</code> effectue l’opération inverse.
-Les applications qui souhaiteraient effectuer ces opérations sans utiliser les méthodes de commodités de Apache SIS
-trouveront des indications dans un <a href="#UML-annotation-geoapi">chapitre séparé</a>.
+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>
+<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>
+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>
+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>
+</li>
+</ul>
+<p>
+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>
 
 
-<h3 id="MappingToJDK"><span class="section-number">1.2.2.</span> Correspondances implicites avec le <abbr>JDK</abbr> standard</h3>
+<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>
-Certaines classes et méthodes n’ont ni annotation <code class="GeoAPI">@UML</code>,
-ni entrée dans le fichier <code class="GeoAPI">class-index.properties</code>.
-Il s’agit soit d’extensions de GeoAPI, ou soit de types définis dans d’autres bibliothèques,
-notamment le <abbr title="Java Development Kit">JDK</abbr> standard.
-Pour ce dernier cas, la correspondance avec les standards <abbr title="International Organization for Standardization">ISO</abbr> est implicite.
-Le tableau suivant décrit cette correspondance pour les types de la norme <abbr>ISO</abbr> 19103.
-Les types primitifs du Java standard sont préférés lorsqu’ils sont applicables,
-mais parfois leurs équivalents sous forme d’objets sont employés lorsqu’il est nécessaire d’autoriser des valeurs nulles.
+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>
-<table>
-<caption>Correspondances entre <abbr>ISO</abbr> 19103 et <abbr>JDK</abbr></caption>
-<tr>
-<th>Type <abbr>ISO</abbr></th>
-<th>Type <abbr>JDK</abbr></th>
-<th>Remarques</th>
-</tr>
-<tr>
-<td class="separator" colspan="2">Nombres</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Integer</code></td>
-<td><code>int</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Integer</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Integer</code> (certains cas)</td>
-<td><code>long</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Long</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Real</code></td>
-<td><code>double</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Double</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Decimal</code></td>
-<td><code>java.math.BigDecimal</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Number</code></td>
-<td><code>java.lang.Number</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Textes</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">FreeText</code></td>
-<td>(pas d’équivalent)</td>
-<td class="leftBorder">Voir <code class="GeoAPI">org.opengis.util.InternationalString</code> ci-dessous.</td>
-</tr>
-<tr>
-<td><code class="OGC">CharacterString</code></td>
-<td><code>java.lang.String</code></td>
-<td class="leftBorder">Souvent <code class="GeoAPI">org.opengis.util.InternationalString</code> (voir ci-dessous).</td>
-</tr>
-<tr>
-<td><code class="OGC">LocalisedCharacterString</code></td>
-<td><code>java.lang.String</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Sequence&lt;Character&gt;</code></td>
-<td><code>java.lang.CharSequence</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Character</code></td>
-<td><code>char</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Dates et heures</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Date</code></td>
-<td><code>java.util.Date</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Time</code></td>
-<td><code>java.util.Date</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">DateTime</code></td>
-<td><code>java.util.Date</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Collections</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Collection</code></td>
-<td><code>java.util.Collection</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Bag</code></td>
-<td><code>java.util.Collection</code></td>
-<td class="leftBorder">Un <code class="OGC">Bag</code> est similaire à un
-<code class="OGC">Set</code> sans la restriction d’unicité.</td>
-</tr>
-<tr>
-<td><code class="OGC">Set</code></td>
-<td><code>java.util.Set</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Sequence</code></td>
-<td><code>java.util.List</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Dictionary</code></td>
-<td><code>java.util.Map</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">KeyValuePair</code></td>
-<td><code>java.util.Map.Entry</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Énumérations</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Enumeration</code></td>
-<td><code>java.lang.Enum</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">CodeList</code></td>
-<td>(pas d’équivalent)</td>
-<td class="leftBorder">Voir <code class="GeoAPI">org.opengis.util.CodeList</code> ci-dessous.</td>
-</tr>
-<tr>
-<td class="separator" colspan="2">Divers</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Boolean</code></td>
-<td><code>boolean</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Boolean</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Any</code></td>
-<td><code>java.lang.Object</code></td>
-<td class="leftBorder"/>
-</tr>
-</table>
 
+
+
+
+<section>
+<header>
+<h2 id="GeometryBase"><span class="section-number">4.1.</span> Classes de base</h2>
+</header>
 <p>
-L’équivalent le plus direct de <code class="OGC">CharacterString</code> est la classe <code>String</code>,
-mais GeoAPI emploie souvent l’interface <code class="GeoAPI">InternationalString</code> pour permettre au client de choisir la langue.
-C’est utile par exemple sur un serveur fournissant simultanément des pages dans plusieurs langues.
-En reportant les traductions à l’utilisation des objets plutôt qu’au moment de leur création, on permet à la bibliothèque
-<abbr title="Spatial Information System">SIS</abbr> de fournir les mêmes instances de <code class="GeoAPI">Metadata</code>
-ou <code class="GeoAPI">Coverage</code> (par exemple) pour les mêmes données peu importe la langue du client.
-Les traductions peuvent être faites à la volée à l’aide d’un <code>ResourceBundle</code> de l’application,
-ou être fournies directement avec les données (cas des <code class="GeoAPI">Metadata</code> notamment).
+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>
 <p>
-Les <code class="OGC">Enumeration</code> correspondent aux <code>Enum</code> du Java.
-Ils ont en commun de définir toutes les valeurs autorisées, sans permettre à l’utilisateur d’en ajouter.
-Les <code class="OGC">CodeList</code> sont similaires à ces énumérations, excepté que les utilisateurs peuvent y ajouter leurs propres éléments.
-Le <abbr>JDK</abbr> standard n’offrant pas cette possibilité,
-GeoAPI définit une classe abstraite <code class="GeoAPI">CodeList</code> reproduisant certaines fonctionnalités de <code>Enum</code> tout en étant extensible.
-Les extensions s’obtiennent par les méthodes statiques <code class="GeoAPI">valueOf(String)</code> qui,
-contrairement à celle de <code>Enum</code>, créeront de nouvelles instances si le nom donné ne correspond pas au nom d’une instance existante.
+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>
 
-<pre><code><code class="GeoAPI">MediumName</code> cdRom  = <code class="GeoAPI">MediumName</code>.<code class="GeoAPI">CD_ROM;</code>
-<code class="GeoAPI">MediumName</code> usbKey = <code class="GeoAPI">MediumName</code>.<code class="GeoAPI">valueOf</code>(<i>"<code class="GeoAPI">USB_KEY</code>"</i>); <code class="comment">// Aucune constante n’existe pour cette valeur.
-</code><b>assert</b> <code class="GeoAPI">MediumName</code>.<code class="GeoAPI">valueOf</code>(<i>"<code class="GeoAPI">CD_ROM</code>"</i>)  == cdRom  : <i>"valueOf doit retourner les constantes existantes."</i>;
-<b>assert</b> <code class="GeoAPI">MediumName</code>.<code class="GeoAPI">valueOf</code>(<i>"<code class="GeoAPI">USB_KEY</code>"</i>) == usbKey : <i>"valueOf doit cacher les valeurs précédemment demandées."</i>;</code></pre>
-
 
 
-<h3 id="GeoAPI-implementation"><span class="section-number">1.2.3.</span> Implémentations fournies par Apache SIS</h3>
+<h3 id="DirectPosition"><span class="section-number">4.1.1.</span> Points et positions directes</h3>
 <p>
-Apache SIS implémente la plupart des interfaces de GeoAPI avec une classe du même nom que l’interface,
-mais préfixée de « <code>Abstract</code> », « <code>Default</code> » ou « <code>General</code> ».
-Les classes de Apache SIS qui sont préfixées par « <code>Default</code> » peuvent être instanciées directement
-par une instruction <code>new DefaultXXX(…)</code> ou par la méthode <code>createXXX(…)</code> correspondante d’une fabrique.
+<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"><b>Example:</b> pour représenter un système de référence de coordonnées projetées (Mercator, Lambert, <i>etc</i>):
-<ul>
-<li><code class="GeoAPI">org.opengis.referencing.crs.ProjectedCRS</code> est l’interface définie par GeoAPI sur la base du standard ISO 19111, et</li>
-<li><code class="SIS">org.apache.sis.referencing.crs.DefaultProjectedCRS</code> est l’implémentation fournie par Apache SIS.</li>
-</ul>
-Une instance peut être créée par:
-<ul>
-<li><code>ProjectedCRS crs = new DefaultProjectedCRS(…)</code>, ou</li>
-<li><code>ProjectedCRS crs = CRSFactory​.createProjectedCRS(…)</code>.</li>
-</ul>
-Les deux approches attendent les mêmes arguments (omis dans cet exemple).
-</div>
 <p>
-Dans la configuration par défaut de Apache SIS,
-utiliser <code class="GeoAPI">CRSFactory​.createXXX(…)</code> ou <code>new DefaultXXX(…)</code> revient presque au même
-excepté que les <code class="GeoAPI">Factory</code> peuvent retourner des instances existantes
-plutôt que de créer systématiquement de nouvelles instances,
-et que les exceptions en cas d’arguments invalides sont de types différents.
-Dans des configurations plus avancées, l’usage des <code class="GeoAPI">Factory</code> permet de
-<a href="#ServiceLoader">réduire la dépendance directe d’une application envers SIS</a>
-et de permettre une inversion de contrôle.
-</p><p>
-Le préfix « <code>General</code> » est parfois utilisé à la place de « <code>Default</code> »
-afin de signaler que des implémentations alternatives existent pour des cas spécifiques.
-Par exemple l’interface <code>Envelope</code> est implémentée par au moins deux classes de Apache SIS:
-<code class="SIS">GeneralEnvelope</code> et <code>Envelope2D</code>.
-La première implémentation peut représenter des enveloppes de n’importe quelle dimension
-alors que la seconde implémentation est spécialisée pour les enveloppes à deux dimensions.
-</p><p>
-Les classes de Apache SIS qui sont préfixées par « <code>Abstract</code> » ne doivent pas – en principe – être instanciées.
-Il faut plutôt instancier une sous-classe non-abstraites.
-Toutefois plusieurs classes de SIS ne sont abstraites que conceptuellement,
-sans que la définition de la classe ne contienne le mot-clé <code>abstract</code> du Java.
-Ces classes peuvent être instanciées par l’instruction <code>new AbstractXXX(…)</code>
-– mais pas par les <code class="GeoAPI">Factory</code> – malgré qu’elles soient conceptuellement abstraites.
-Mais ces instanciations ne devraient être faites qu’en dernier recours,
-lorsqu’il n’est vraiment pas possible de déterminer le sous-type exact.
+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>
-</section>
 
 
-<section>
-<header>
-<h2 id="AboutBook"><span class="section-number">1.3.</span> Conventions utilisées dans ce guide</h2>
-</header>
+
+<h3 id="Envelope"><span class="section-number">4.1.2.</span> Enveloppes</h3>
 <p>
-Les standards privilégient parfois l’application de certains termes génériques à des contextes particuliers,
-qui peuvent différer du contexte dans lequel d’autres communautés emploient ces termes.
-Par exemple les termes <i>domain</i> et <i>range</i> peuvent s’appliquer à des fonctions arbitraires
-pour désigner l’ensemble des valeurs possibles en entrés et en sorties respectivement.
-Mais les fonctions auxquelles certains standards <abbr title="International Organization for Standardization">ISO</abbr>
-les appliquent ne sont pas les mêmes que les fonctions auxquelles d’autres bibliothèques les appliquent.
-Par exemple <abbr>ISO</abbr> 19123 applique ces termes aux objets <code class="OGC">CV_Coverage</code>,
-vus comme des fonctions dont le domaine est l’ensemble des coordonnées spatio-temporelles de la couverture de données
-et le <i>range</i> l’ensemble des valeurs de la couverture.
-Mais la bibliothèque <abbr title="Network Common Data Form">NetCDF</abbr> de l’<abbr title="University Corporation for Atmospheric Research">UCAR</abbr>
-applique plutôt ces termes à la fonction convertissant les indices de pixels (son domaine) vers les coordonnées spatio-temporelles (son <i>range</i>).
-Ainsi, un <i>range</i> de la bibliothèque de l’<abbr>UCAR</abbr> peut être le domaine de <abbr>ISO</abbr> 19123.
-</p><p>
-La bibliothèque Apache <abbr title="Spatial Information System">SIS</abbr> privilégie autant que possible l’utilisation des termes dans le sens des normes <abbr title="Open Geospatial Consortium">OGC</abbr> et <abbr>ISO</abbr>.
-Mais un soin particulier doit être apporté aux interfaces entre <abbr>SIS</abbr> et certaines bibliothèques externes, afin de réduire les risques de confusions.
+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>
 
 
 
-<h3 id="CodeColors"><span class="section-number">1.3.1.</span> Code de couleurs</h3>
+<h4 id="AntiMeridian"><span class="section-number">4.1.2.1.</span> Enveloppes traversant l’antiméridien</h4>
 <p>
-Les éléments définis dans un langage informatique, tels que les classes ou méthodes en Java
-ainsi que les éléments dans un fichier <abbr>XML</abbr>, apparaissent avec une police de caractères mono-espacée.
-Afin de faciliter la compréhension des liens qui existent entre Apache <abbr title="Spatial Information System">SIS</abbr> et les standards,
-ces éléments sont en outre représentés en utilisant les codes de couleurs suivants:
+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>
-Les éléments définis dans un standard de l’<abbr title="Open Geospatial Consortium">OGC</abbr>
-ou de l’<abbr title="International Organization for Standardization">ISO</abbr> apparaissent en bleu.
-Exemple: <code class="OGC">CD_Ellipsoid</code>.
-</li>
-<li>
-Les éléments définis dans GeoAPI apparaissent en vert.
-Exemple: <code class="GeoAPI">Ellipsoid</code>.
-</li>
-<li>
-Les éléments définis dans Apache <abbr title="Spatial Information System">SIS</abbr> apparaissent en brun.
-Exemple: <code class="SIS">DefaultEllipsoid</code>.
+<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>
-Les autres éléments, notamment ceux du Java standard, sont laissés en noir.
-Exemple: <code>String</code>.
+<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>
-Des compléments d’information apparaissent dans des boîtes grises.
-Le lecteur peut ignorer ces boîtes grises sans que cela ne nuise à la compréhension du texte.
+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>
+<p>
+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>
+<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>
 
 
 <section>
 <header>
-<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>
+<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"/></nav>
-<p>
-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>
+<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>
-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>
+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>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>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>
-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 traduit 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 standard dans le paquet <code>javax.imageio.metadata</code>.
-Pour Apache <abbr>SIS</abbr>, le modèle pivot choisi 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éfini,
-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>.
+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>
+<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>
-le code suivant lit un fichier de méta-données d’une image Landsat-8 et affiche les limites géographiques qui y sont déclarées:
+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.

[... 3674 lines stripped ...]


Mime
View raw message