sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1794573 [8/10] - in /sis/site/trunk/book: en/ fr/
Date Tue, 09 May 2017 13:09:59 GMT
Modified: sis/site/trunk/book/fr/introduction.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/introduction.html?rev=1794573&r1=1794572&r2=1794573&view=diff
==============================================================================
--- sis/site/trunk/book/fr/introduction.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/introduction.html [UTF-8] Tue May  9 13:09:58 2017
@@ -31,942 +31,943 @@
       Content below this point is copied in "../../content/book/fr/developer-guide.html"
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
-    <header>
-      <h1 id="Standards">Standards et normes</h1>
-    </header>
-    <p>
-      Une communauté d’informations géospatiales est un ensemble de systèmes ou d’individus capables d’échanger
-      leurs données géospatiales grâce à des définitions et des standards communs ainsi qu’une reconnaissance réciproque.
-      Comme il existe une multitude de façons de représenter des informations géospatiales,
-      chaque communauté est amenée à les structurer en fonction de ses centres d’intérêts.
-      Cette diversité complique la tâche des utilisateurs de systèmes d’information géographiques (<abbr>SIG</abbr>)
-      en les plaçant devant une variété apparemment chaotique de formats et de structures de données.
-      Les caractéristiques de ces structures varient en fonction des phénomènes observés et des méthodes de mesure,
-      ainsi que des habitudes des organisations produisant les données.
-      Une telle variété agit comme un frein aux études qui requièrent des combinaisons de données hétérogènes,
-      surtout lorsqu’elles proviennent de communautés traditionnellement distinctes.
-      Par exemple, un chercheur étudiant le choléra peut s’intéresser aux populations de crevettes comme vecteur de propagation de la maladie.
-      Mais les médecins et les océanographes n’ayant pas forcement l’habitude de partager leurs travaux,
-      les participants à une telle étude peuvent être limités par les efforts qu’ils sont disposés à fournir pour convertir les données.
-    </p><p>
-      Nous ne pouvons pas imposer un format uniforme à l’ensemble des données, car la diversité des formats tient
-      à des facteurs tels que les contraintes des appareils de mesure et la distribution statistique des valeurs.
-      Une solution plus flexible consiste à assurer l’interopérabilité des données à travers une interface de programmation
-      (<abbr title="Application Programming Interface">API</abbr>) commune.
-      Cette <abbr>API</abbr> n’est pas forcement définie dans un langage de programmation;
-      la tendance actuelle est plutôt de définir des conventions utilisant les protocoles web existants,
-      que l’on peut transposer dans des langages de programmation.
-      Mais pour que cette démarche puisse être pérennisée, l’<abbr>API</abbr> doit être largement accepté par des développeurs indépendants.
-      Autrement dit, l’<abbr>API</abbr> doit s’approcher autant que possible des standards industriels.
-    </p><p>
-      Les accès aux bases de données relationnelles sont un exemple de tâche ayant bénéficié d’une standardisation relativement bien réussie.
-      L’industrie a établie un langage commun — le standard <abbr title="Structured Query Language">SQL</abbr> — que les concepteurs du Java
-      ont enrobé dans des interfaces de programmation formant le standard <abbr title="Java DataBase Connectivity">JDBC</abbr>.
-      Ces interfaces sont aujourd’hui implementées par de nombreux logiciels libres et commerciaux.
-      Comme pour les bases de données, des méthodes d’accès aux informations géographiques ont été standardisées.
-      Mais les efforts en ce sens sont plus récents et leurs intégrations dans les logiciels, surtout les plus anciens,
-      sont incomplètes et pas toujours cohérentes.
-      Au moment d’écrire ces lignes, aucun produit de notre connaissance n’implémente la totalité des spécifications.
-      Mais on trouve de nombreuses implémentations couvrant un spectre plus ou moins large.
-      La bibliothèque Apache <abbr>SIS</abbr>® décrite dans ce document en est une.
-    </p><p>
-      Apache <abbr title="Spatial Information System">SIS</abbr> se caractérise par un effort soutenu de respect des standards.
-      De manière générale, le respect des standards exige un effort plus grand que ce qu’aurait requis un développement isolé,
-      mais se rentabilise par un double avantage: en plus d’accroître l’interopérabilité des données avec celles des projets externes,
-      il nous indique aussi une voie robuste à suivre pour l’élaboration du modèle conceptuel qui sera reflété par l’<abbr>API</abbr>.
-      En effet, les groupes d’experts qui conçoivent les standards anticipent des difficultés qui échappent parfois à l’ingénieur en début de projet,
-      mais qui risquent de le rattraper avant la fin.
-    </p>
-
-
-
-    <h2 id="ConceptualModels">Sources des modèles conceptuels de Apache SIS</h2>
-    <p>
-      La majorité des standards utilisés par Apache <abbr>SIS</abbr> ont été élaborés
-      par le <a href="http://www.opengeospatial.org">consortium <i>Open Geospatial</i></a> (<abbr>OGC</abbr>),
-      parfois en collaboration avec l’<a href="http://www.iso.org">organisation internationale de normalisation</a> (<abbr>ISO</abbr>).
-      Certains standards de l’<abbr>ISO</abbr> deviennent eux-mêmes des standards Européens via la
-      <a href="http://inspire.jrc.ec.europa.eu">directive INSPIRE</a>, ou des standards français via l’<abbr>AFNOR</abbr>.
-      Ces standards offrent deux technologies clés:
-    </p>
-    <ul>
-      <li>
-        Permettre à une communauté d’annoncer leurs informations,
-        de manière à ce que des individus ou des systèmes en dehors de cette communauté puissent les découvrir.
-      </li>
-      <li>
-        Transférer des informations d’une communauté vers une autre en préservant leurs sémantiques,
-        même si les deux communautés utilisent des représentations internes très différentes.
-      </li>
-    </ul>
-    <p>
-      Ces standards sont fournis gratuitement à la communauté internationale sous la forme de
-      <a href="http://www.opengeospatial.org/standards/is">spécifications (fichiers <abbr title="Portable Document Format">PDF</abbr>)</a> ou de
-      <a href="http://schemas.opengis.net/gml/3.3/">schémas (fichiers <abbr title="XML Schema Definition">XSD</abbr>)</a>.
-      Les organismes de normalisation ne fabriquent pas de logiciel; pour obtenir une implémentation de ces spécifications,
-      les utilisateurs doivent choisir un des produits conformes disponibles sur le marché ou développer leur propres solutions.
-      C’est le respect volontaire de ces spécifications qui permet à des communautés à priori indépendantes d’échanger
-      plus facilement des informations géographiques.
-    </p>
-
-
-
-    <details>
-      <summary>Pour en savoir plus sur le processus de standardisation</summary>
-      <article id="OGC-process">
-        <header>
-          <h2>Processus de standardisation à l’<abbr>OGC</abbr></h2>
-        </header>
-        <p>
-          Les travaux de l’<abbr title="Open Geospatial Consortium">OGC</abbr> se font par courriers électroniques,
-          par conférences téléphoniques et par <a href="http://www.opengeospatial.org/event?category=ogctcpc">réunions réelles</a>.
-          L’<abbr>OGC</abbr> organise quatre réunions par années, chacune d’une durée de cinq jours,
-          hébergées par des organisations membres sponsorisant l’événement (compagnies, universités, centres de recherches, <i>etc.</i>).
-          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.
-          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>,
-          tandis que les <abbr>SWG</abbr> nécessitent de la part des participants un engagement à ne pas entraver
-          la diffusion du standard par des réclamations de propriétés intellectuelles.
-        </p>
-
-        <h2 id="OGC-SWG">Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</h2>
-        <p>
-          Pour être accepté, un projet de standardisation doit être supporté par un nombre minimal de membres appartement à des organisations distinctes.
-          Ces membres fondateurs rédigent une charte définissant les objectifs du <abbr>SWG</abbr>,
-          qui doit être approuvée par le comité technique de l’<abbr>OGC</abbr>.
-          Chaque membre fondateur est doté d’un droit de vote, dans les limites d’un membre votant par organisation.
-          Tout nouveau membre qui souhaite joindre le <abbr>SWG</abbr> après sa création se verra attribué un rôle d’observateur,
-          avec attribution sur demande d’un droit de vote après quelques mois d’observation.
-        </p><p>
-          Un <abbr>SWG</abbr> peut contenir plusieurs dizaines de membres,
-          mais les volontaires effectuant l’essentiel du travail sont habituellement moins nombreux.
-          Leurs propositions sont soumises à l’ensemble des membres du groupe, qui peuvent les accepter par consentement unanime.
-          Les objections, s’il y en a, doivent être argumentées et une alternative proposée.
-          Les <abbr>SWG</abbr> essaient généralement de débattre d’un problème jusqu’à ce qu’un consensus se forme
-          plutôt que d’avancer malgré des votes négatifs, même s’ils sont minoritaires.
-          Les décisions du groupes sont alors intégrées dans la spécification par un membre assumant le rôle d’éditeur.
-        </p><p>
-          Le groupe de travail doit autant que possible structurer la spécification sous forme d’un noyau autour duquel gravite diverses extensions.
-          Une suite de tests doit accompagner le standard, et permettre de classer les implémentations en fonction du niveau des tests passés.
-          Au moins une <i>implémentation de référence</i> passant les tests doit exister pour démontrer que le standard est utilisable.
-        </p><p>
-          Lorsque le standard est jugé prêt, le <abbr>SWG</abbr> vote une motion
-          proposant de le soumettre au vote des instances supérieures de l’<abbr>OGC</abbr>.
-          Cette procédure nécessite plusieurs mois.
-          Il existe une procédure plus rapide pour entériner des standards de fait, mais elle n’est appliquée qu’avec parcimonie.
-        </p>
-
-        <h2 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</h2>
-        <p>
-          Toute proposition de standard est d’abord examinée par le conseil d’architecture (<i><abbr>OGC</abbr> Architecture Board</i> — <abbr>OAB</abbr>).
-          Ce conseil vérifie que le standard répond aux exigences de l’<abbr>OGC</abbr> sur la forme,
-          sur la modularisation, et en termes d’intégration avec les autres standards.
-          Si l’<abbr>OAB</abbr> donne son aval, le standard est alors soumis au vote des membres du comité technique (<abbr>TC</abbr>).
-          Ce comité regroupe les principaux membres de l’<abbr>OGC</abbr> qui sont seuls habilités à donner le vote final.
-          En cas d’approbation, le standard est diffusé publiquement pour commentaires pendant une période de quelques mois.
-          Au terme de cette période, le <abbr title="Standard Working Group">SWG</abbr> doit examiner et répondre à chacun des commentaires.
-          Les éventuelles modifications au standard sous soumises à l’<abbr>OAB</abbr>, puis le standard est définitivement publié.
-          Cette diffusion est alors annoncée par un communiqué de presse de l’<abbr>OGC</abbr>.
-        </p><p>
-          Certains membres de l’<abbr title="Open Geospatial Consortium">OGC</abbr> et du <abbr title="Technical Committe">TC</abbr>
-          assurent aussi la liaison avec l’organisation internationale de normalisation (<abbr title="International Organization for Standardization">ISO</abbr>).
-          La coopération entre les deux organismes va dans les deux sens: l’<abbr>OGC</abbr> adopte les standards <abbr>ISO</abbr> comme base sur
-          laquelle développer de nouveaux standards, et certains de ces nouveaux standards <abbr>OGC</abbr> deviennent des standards <abbr>ISO</abbr>.
-        </p>
-
-        <h2 id="OGC-RFC">Procédure de soumission de propositions de modifications</h2>
-        <p>
-          Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications à des standards <abbr>OGC</abbr>.
-          Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles,
-          sont <a href="http://www.opengeospatial.org/standards/cr">disponibles en ligne</a>.
-          Chaque proposition est revue par le <abbr title="Standard Working Group">SWG</abbr>.
-        </p><p>
-          Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle, par exemple GitHub,
-          hébergés en dehors des structures de l’<abbr>OGC</abbr>.
-        </p>
-      </article>
-    </details>
-
-
-
-    <p>
-      Outre ces organisations formelles de normalisation, il existe aussi des organisations qui ne sont pas officiellement
-      dédiées à l’élaboration de normes mais dont les travaux ont été largement adoptés comme standards de fait.
-      En particulier, la base de données <a href="http://www.epsg.org">EPSG</a> fournit des codes numériques permettant d’identifier
-      facilement un système de référence des coordonnées parmi <a href="../../tables/CoordinateReferenceSystems.html">plusieurs milliers</a>.
-      Cette base de données est offerte par des compagnies pétrolières qui ont vu leur intérêt à ce que leurs prospections se fassent
-      bien à l’endroit voulu, sachant qu’elles ne contrôlent pas toujours la production des cartes sur lesquelles elles se positionnent.
-      D’autres exemples de standards de fait sont les formats
-      <a href="http://geotiff.osgeo.org">GeoTIFF</a> pour les données réparties sur une grille (les images), et
-      <a href="http://fr.wikipedia.org/wiki/Shapefile">Shapefile</a> pour les données vectorielles (les géométries).
-    </p><p>
-      Les standards <abbr>OGC</abbr> sont spécifiés dans plusieurs dizaines de documents.
-      Chaque document élabore un service, par exemple les transformations de coordonnées.
-      Le fonctionnement de chaque service est décrit par un ensemble de classes d’objets et leurs interactions.
-      Ces éléments sont illustrés par des diagrammes <abbr>UML</abbr> (<i>Unified Modeling Language</i>)
-      dans des spécifications dites « abstraites ».
-      Les <a href="http://www.opengeospatial.org/standards/as">spécifications abstraites</a> ne font référence à aucun langage informatique concret.
-      Leurs concepts peuvent se concrétiser dans un langage de programmation, une base de données ou un schéma <abbr>XML</abbr> de manière plus ou moins directe.
-      Il existe toutefois une part d’arbitraire dans la façon de concrétiser une spécification abstraite, étant donné que des ajustements sont souvent nécessaires
-      pour tenir compte des contraintes ou des conventions du langage ciblé.
-      Certaines structures de données n’existent que dans quelques langages, par exemple les unions qui existent en C/C++ mais pas en Java.
-    </p>
-
-
-
-    <details>
-      <summary>Pour en savoir plus sur les « spécifications d’implémentation »</summary>
-      <article id="implementation-standard">
-        <header>
-          <h2>Note historique</h2>
-        </header>
-        <p>
-          Au tournant du millénaire, les spécifications abstraites étaient explicitement concrétisées dans des <i>spécifications d’implémentations</i>.
-          Le terme « implémentation » était ici à prendre au sens de tout type d’interfaces (Java ou autres) dérivées des diagrammes
-          <abbr title="Unified Modeling Language">UML</abbr> — et non pas d’implémentations au sens du Java.
-          Des telles spécifications existaient pour les langages <abbr title="Structured Query Language">SQL</abbr>,
-          <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr> et Java.
-          Ces langages étant capables d’exécuter des procédures, les spécifications de cette époque définissaient
-          non seulement des structures de données, mais aussi des opérations s’appliquant sur ces structures.
-        </p><p>
-          Par la suite, l’engouement pour le « web 2.0 » a fait grimper l’intérêt pour le <abbr>XML</abbr> au détriment des autres langages.
-          Les anciennes spécifications d’implémentations ont été dépréciées, et les schémas <abbr title="XML Schema Definition">XSD</abbr>
-          sont devenus la principale concrétisation des spécifications abstraites.
-          Même la façon de concevoir les spécifications abstraites a évoluée: les opérations y sont plus rarement définies,
-          par conséquence ce qui reste ressemble davantage à des descriptions de schémas de base de données.
-          Certaines opérations qui étaient définies dans les anciennes normes apparaissent maintenant, sous une autre forme, dans les spécifications des services web.
-          Enfin le terme « spécification d’implémentation » a été abandonné, pour être englobé dans « standard <abbr title="Open Geospatial Consortium">OGC</abbr> ».
-          Mais malgré leur dépréciation, les <a href="http://www.opengeospatial.org/docs/retired">anciennes spécifications d’implémentation</a>
-          restent utiles aux programmes en langage Java car:
-        </p>
-        <ul>
-          <li>
-            Leurs modèles plus simples, appliqués aux mêmes concepts, aident à comprendre les nouvelles spécifications.
-          </li>
-          <li>
-            Ils définissent parfois des façons simples d’effectuer des tâches courantes
-            là où les nouvelles spécifications se limitent au cas général.
-          </li>
-          <li>
-            Les opérations étant plus souvent omises dans les nouvelles spécifications,
-            les anciennes spécifications restent un complément utile pour définir des <abbr>API</abbr>.
-          </li>
-        </ul>
-        <p>
-          Le projet Apache <abbr title="Spatial Information System">SIS</abbr> se base sur les spécifications les plus récentes,
-          tout en puisant dans les archives de l’<abbr title="Open Geospatial Consortium">OGC</abbr>
-          pour compléter certains standards abstraits ou les rendre un peu plus facile d’utilisation.
-          Certaines anciennes définitions sont conservées comme « méthodes de commodités »,
-          n’apportant pas toujours de nouvelles fonctionnalités mais facilitant l’usage pratique d’une bibliothèque.
-        </p>
-      </article>
-    </details>
-    <p>
-      Le tableau suivant liste les principales normes utilisées par le projet.
-      Plusieurs normes sont publiées à la fois comme standard <abbr>ISO</abbr> et comme standard <abbr>OGC</abbr>,
-      d’où la disposition côte-à-côte des deux premières colonnes.
-      La section des « spécifications d’implémentation » liste des spécifications qui apportent peu de concepts nouveaux
-      comparativement aux spécifications abstraites, mais précisent comment les représenter dans des contextes précis
-      tels qu’un document <abbr>XML</abbr>.
-      Les normes dépréciées mais malgré tout partiellement utilisées apparaissent <s>barrées</s>.
-      Enfin, les paquets GeoAPI seront introduits dans le chapitre suivant.
-    </p>
-    <table>
-      <caption>Principaux standards en relation avec le projet Apache <abbr>SIS</abbr></caption>
-      <tr>
-        <th>Norme <abbr>ISO</abbr></th>
-        <th>Norme <abbr>OGC</abbr></th>
-        <th>Titre</th>
-        <th>Paquet de GeoAPI</th>
-        <th>Paquet de Apache SIS</th>
-      </tr><tr>
-        <td class="separator" colspan="5">Spécifications abstraites</td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19103</td>
-        <td></td>
-        <td><i>Conceptual schema language</i></td>
-        <td><code>org.opengis.util</code></td>
-        <td><code>org.apache.sis.util.iso</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19115-1</td>
-        <td>Topic 11</td>
-        <td><i>Metadata</i></td>
-        <td><code>org.opengis.metadata</code></td>
-        <td><code>org.apache.sis.metadata.iso</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19115-2</td>
-        <td></td>
-        <td><i>Metadata — extensions for imagery and gridded data</i></td>
-        <td><code>org.opengis.metadata</code></td>
-        <td><code>org.apache.sis.metadata.iso</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19111</td>
-        <td>Topic 2</td>
-        <td><i>Spatial referencing by coordinates</i></td>
-        <td><code>org.opengis.referencing</code></td>
-        <td><code>org.apache.sis.referencing</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19111-2</td>
-        <td></td>
-        <td><i>Referencing — extension for parametric values</i></td>
-        <td><code>org.opengis.referencing</code></td>
-        <td><code>org.apache.sis.referencing</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19112</td>
-        <td></td>
-        <td><i>Spatial referencing by geographic identifier</i></td>
-        <td><code>org.opengis.referencing.gazetteer</code></td>
-        <td><code>org.apache.sis.referencing.gazetteer</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19108</td>
-        <td></td>
-        <td><i>Temporal Schema</i></td>
-        <td><code>org.opengis.temporal</code></td>
-        <td></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19107</td>
-        <td>Topic 1</td>
-        <td><i>Feature geometry</i></td>
-        <td><code>org.opengis.geometry</code></td>
-        <td><code>org.apache.sis.geometry</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19109</td>
-        <td>Topic 5</td>
-        <td><i>Rules for application schema</i></td>
-        <td><code>org.opengis.feature</code></td>
-        <td><code>org.apache.sis.feature</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19123</td>
-        <td>Topic 6</td>
-        <td><i>Schema for coverage geometry and functions</i></td>
-        <td><code>org.opengis.coverage</code></td>
-        <td><code>org.apache.sis.coverage</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19156</td>
-        <td>Topic 20</td>
-        <td><i>Observations and measurements</i></td>
-        <td><code>org.opengis.observation</code></td>
-        <td></td>
-      </tr><tr>
-        <td class="separator" colspan="5">Spécifications d’implémentation</td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19139</td>
-        <td></td>
-        <td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
-        <td></td>
-        <td><code>org.apache.sis.xml</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19136</td>
-        <td>OGC 07-036</td>
-        <td><i>Geography Markup Language (<abbr>GML</abbr>) Encoding Standard</i></td>
-        <td></td>
-        <td><code>org.apache.sis.xml</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19162</td>
-        <td>OGC 12-063</td>
-        <td><i>Well-known text representation of coordinate reference systems</i></td>
-        <td></td>
-        <td><code>org.apache.sis.io.wkt</code></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 13249</td>
-        <td></td>
-        <td><i><abbr>SQL</abbr> spatial</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td></td>
-        <td><s><abbr>OGC</abbr> 01-009</s></td>
-        <td><s><i>Coordinate Transformation Services</i></s></td>
-        <td><code>org.opengis.referencing</code></td>
-        <td><code>org.apache.sis.referencing</code></td>
-      </tr><tr>
-        <td></td>
-        <td><s><abbr>OGC</abbr> 01-004</s></td>
-        <td><s><i>Grid Coverage</i></s></td>
-        <td><code>org.opengis.coverage</code></td>
-        <td><code>org.apache.sis.coverage</code></td>
-      </tr><tr>
-        <td></td>
-        <td><abbr>SLD</abbr></td>
-        <td><i>Styled Layer Descriptor</i></td>
-        <td><code>org.opengis.style</code></td>
-        <td></td>
-      </tr><tr>
-        <td class="separator" colspan="5">Services web</td>
-      </tr><tr>
-        <td></td>
-        <td><abbr>CSW</abbr></td>
-        <td><i>Catalog Services</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19128</td>
-        <td><abbr>WMS</abbr></td>
-        <td><i>Web Map Service</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td></td>
-        <td><abbr>WMTS</abbr></td>
-        <td><i>Web Map Tile Service</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td><abbr>ISO</abbr> 19142</td>
-        <td><abbr>WFS</abbr></td>
-        <td><i>Web Feature Service</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td></td>
-        <td><abbr>WCS</abbr></td>
-        <td><i>Web Coverage Service</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td></td>
-        <td><abbr>WPS</abbr></td>
-        <td><i>Web Processing Service</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td></td>
-        <td>Open<abbr>LS</abbr></td>
-        <td><i>Location Services</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td></td>
-        <td><abbr>SWE</abbr></td>
-        <td><i>Sensor Web Enablement</i></td>
-        <td></td>
-        <td></td>
-      </tr><tr>
-        <td></td>
-        <td><abbr>SOS</abbr></td>
-        <td><i>Sensor Observation Service</i></td>
-        <td></td>
-        <td></td>
-      </tr>
-    </table>
-
-
-
-    <h2 id="GeoAPI">Des modèles conceptuels vers des interfaces Java: GeoAPI</h2>
-    <p>
-      Le projet <a href="http://www.geoapi.org">GeoAPI</a> offre un ensemble d’interfaces Java pour les applications géo-spatiales.
-      Dans une séries de paquets <code>org.opengis.*</code>, GeoAPI définit des structures représentant des méta-données,
-      des systèmes de référence des coordonnées, ainsi que des opérations effectuant des projections cartographiques.
-      Dans une partie qui n’est pas encore standardisée — dénommée <i>pending</i> — GeoAPI définit des structures
-      représentant des images géo-référencées, des géométries, des filtres pouvant s’appliquer à des requêtes, et d’autres fonctionnalités.
-      Ces interfaces suivent de très près les spécifications de l’<abbr>OGC</abbr>, tout en les interprétant et en les adaptant
-      de manière à répondre aux attentes des développeurs Java — par exemple en se conformant aux conventions de nommage.
-      Ces interfaces bénéficient à la fois aux applications clientes et aux bibliothèques:
-    </p>
-    <ul>
-      <li><p>
-        Les développeurs des applications clientes bénéficient d’une plus grande base de connaissances disponible sur internet
-        (due aux nombreuses publications en lien avec les standards de l’<abbr>OGC</abbr>), ainsi que d’une interopérabilité accrue.
-        L’interopérabilité est facilitée par une meilleure séparation entre les applications qui <em>appellent</em> les fonctions de GeoAPI,
-        et les bibliothèques qui <em>implémentent</em> GeoAPI. Il s’agit d’une séparation similaire à celle qu’offrent les interfaces
-        <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/"><abbr>JDBC</abbr></a> (<i>Java Database Connectivity</i>) du Java standard.
-        En utilisant l’<abbr>API</abbr> des interfaces, les développeurs peuvent faire abstraction de l’implémentation sous-jacente.
-        Par exemple ils peuvent effectuer des projections cartographiques à l’aide des bibliothèques
-        <a href="http://www.geoapi.org/geoapi-proj4/index.html">Proj.4</a> ou Apache <abbr>SIS</abbr>,
-        sans changer leurs programmes lorsqu’ils changent de bibliothèque.
-      </p></li>
-      <li><p>
-        Les développeurs des bibliothèques héritent de l’expertise des auteurs des spécifications, via les modèles que représentent les interfaces.
-        GeoAPI fournit aussi un cadre dans lequel les développeurs peuvent implémenter en priorité les fonctionnalité qui leurs sont le plus nécessaires,
-        tout en ayant des points où raccrocher les développements futurs.
-        Par exemple les clients peuvent appeler une fonction de GeoAPI même si elle n’est pas encore supportée par la bibliothèque,
-        quitte à obtenir une valeur nulle en attendant qu’une nouvelle version de la bibliothèque retourne une valeur intéressante.
-      </p></li>
-    </ul>
-
-    <details>
-      <summary>Pour en savoir plus sur les origines du projet GeoAPI</summary>
-      <article>
-        <header>
-          <h2>Historique du projet GeoAPI</h2>
-        </header>
-        <p>
-          En 2001, le consortium <i>Open GIS</i> (l’ancien nom du consortium <i>Open Geospatial</i>) publia la spécification d’implémentation
-          <a href="http://www.opengeospatial.org/standards/ct"><abbr>OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
-          Cette spécification, élaborée par <i>Computer Aided Development Corporation</i> (Cadcorp),
-          était accompagnée d’interfaces <abbr>COM</abbr>, <abbr>CORBA</abbr> et Java.
-          À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques.
-          Les interfaces de l’<abbr>OGC</abbr> anticipaient tout de même un monde connecté en réseau,
-          mais misaient plutôt — dans le cas du Java — sur la technologie <abbr>RMI</abbr> (<i>Remote Method Invocation</i>).
-          Bien que le projet GeoAPI n’existait pas encore, nous désignons rétrospectivement ces interfaces historiques sous le nom de
-          « <a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a> ».
-          Ces interfaces utilisaient déjà le nom de paquet <code>org.opengis</code>, qui sera adopté par GeoAPI.
-        </p><p>
-          En 2002, des développeurs de projets libres ont lancé un
-          <a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr>API</abbr> géo-spatial</a>.
-          La proposition initiale suscita l’intérêt d’au moins cinq projets libres.
-          Le projet fut créé sur <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
-          qui héberge depuis lors le code source dans un <a href="http://www.geoapi.org/source-repository.html">dépôt Subversion</a>.
-          Le projet pris le nom de « GeoAPI » à ce moment là, et utilisa les interfaces de la spécification <abbr>OGC</abbr> 01-009 comme point de départ.
-        </p><p>
-          Quelques mois plus tard, l’<abbr>OGC</abbr> lança le projet
-          <a href="http://www.opengeospatial.org/standards/go"><abbr>GO-1</abbr>: <i>Geographic Objects</i></a>,
-          qui poursuivait des buts similaires à ceux de GeoAPI.
-          Entre-temps, l’<abbr>OGC</abbr> avait abandonné certaines de leur spécifications en faveur des normes <abbr>ISO</abbr>.
-          GeoAPI et <abbr>GO-1</abbr> ont joint leurs efforts pour une refonte des interfaces de GeoAPI en les basant sur ces nouvelles normes <abbr>ISO</abbr>.
-          La première mouture, <a href="http://www.geoapi.org/1.0/index.html">GeoAPI 1.0</a>, a servit de point de départ
-          aux premières ébauches de la spécification <abbr>OGC</abbr> 03-064 du groupe de travail <abbr>GO</abbr>-1.
-          La version finale de cette spécification est devenue un standard <abbr>OGC</abbr> en 2005, et
-          <a href="http://www.geoapi.org/2.0/index.html">GeoAPI 2.0</a> a été publiée à cette occasion.
-        </p><p>
-          Le projet <abbr>GO</abbr>-1 était porté essentiellement par une compagnie nommée <i>Polexis</i>.
-          Son rachat par <i>Sys Technology</i> et le changement de priorité des nouveaux propriétaires
-          ont causé l’arrêt des travaux de <abbr>GO</abbr>-1, et par ricochet un ralentissement des développements de GeoAPI.
-          Afin de reprendre les développements, un nouveau groupe de travail « GeoAPI 3.0 » a été créé à l’<abbr>OGC</abbr>.
-          Ce groupe a réduit les ambitions par rapport à GeoAPI 2.0 en se concentrant sur les interfaces les plus stables,
-          et en plaçant les autres — notamment les géométries — dans un module nommé « <a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a> »,
-          pour considérations futures. <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> est devenu un
-          <a href="http://www.opengeospatial.org/standards/geoapi">standard <abbr>OGC</abbr></a> en 2011.
-          Cette version a été la première à être déployée dans le <a href="http://search.maven.org/#search|ga|1|geoapi">dépôt central de Maven</a>.
-        </p>
-      </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>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>@UML</code>
-      et des fichiers de propriétés, décrits dans la section suivante.
-    </p>
-
-    <details>
-      <summary>Pour en savoir plus sur les raisons d’une définition manuelle des interfaces Java</summary>
-      <article id="SpecificationToInterfaces">
-        <header>
-          <h2>Des spécifications de l’<abbr>OGC</abbr> aux interfaces Java</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>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>UML</abbr> plutôt que <abbr>XSD</abbr>.
-        </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:
-        </p>
-        <ul>
-          <li>
-            <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>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.
-            </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>&lt;gmd:CI_Citation&gt;</code> à l’intérieur de <code>&lt;gmd:citation&gt;</code>,
-              un élément <code>&lt;gmd:CI_OnlineResource&gt;</code> à l’intérieur de <code>&lt;gmd:onlineResource&gt;</code>,
-              et ainsi de suite pour la centaine de classes définies dans le standard <abbr>ISO</abbr> 19115.
-              Cette redondance n’est absolument pas nécessaire à un programme Java.
-            </p></div>
-          </li>
-          <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>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>MD_Identifier</code> de l’<abbr>OGC</abbr> devient
-              l’interface <code>Identifier</code> dans le paquet <code>org.opengis.metadata</code>.
-              La classe <code>SC_CRS</code> de l’<abbr>OGC</abbr> devient l’interface <code>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>
-          </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>CS_ImageCS</code>,
-              ne contient que <code>CS_CartesianCS</code> et <code>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>CartesianCS</code> comme une spécialisation de <code>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>
-          </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>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>
-          </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>MI_Band</code> qui étend la
-              classe <code>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>
-          </li>
-        </ul>
-      </article>
-    </details>
+    <section>
+      <header>
+        <h1 id="Standards">Standards et normes</h1>
+      </header>
+      <p>
+        Une communauté d’informations géospatiales est un ensemble de systèmes ou d’individus capables d’échanger
+        leurs données géospatiales grâce à des définitions et des standards communs ainsi qu’une reconnaissance réciproque.
+        Comme il existe une multitude de façons de représenter des informations géospatiales,
+        chaque communauté est amenée à les structurer en fonction de ses centres d’intérêts.
+        Cette diversité complique la tâche des utilisateurs de systèmes d’information géographiques (<abbr>SIG</abbr>)
+        en les plaçant devant une variété apparemment chaotique de formats et de structures de données.
+        Les caractéristiques de ces structures varient en fonction des phénomènes observés et des méthodes de mesure,
+        ainsi que des habitudes des organisations produisant les données.
+        Une telle variété agit comme un frein aux études qui requièrent des combinaisons de données hétérogènes,
+        surtout lorsqu’elles proviennent de communautés traditionnellement distinctes.
+        Par exemple, un chercheur étudiant le choléra peut s’intéresser aux populations de crevettes comme vecteur de propagation de la maladie.
+        Mais les médecins et les océanographes n’ayant pas forcement l’habitude de partager leurs travaux,
+        les participants à une telle étude peuvent être limités par les efforts qu’ils sont disposés à fournir pour convertir les données.
+      </p><p>
+        Nous ne pouvons pas imposer un format uniforme à l’ensemble des données, car la diversité des formats tient
+        à des facteurs tels que les contraintes des appareils de mesure et la distribution statistique des valeurs.
+        Une solution plus flexible consiste à assurer l’interopérabilité des données à travers une interface de programmation
+        (<abbr title="Application Programming Interface">API</abbr>) commune.
+        Cette <abbr>API</abbr> n’est pas forcement définie dans un langage de programmation;
+        la tendance actuelle est plutôt de définir des conventions utilisant les protocoles web existants,
+        que l’on peut transposer dans des langages de programmation.
+        Mais pour que cette démarche puisse être pérennisée, l’<abbr>API</abbr> doit être largement accepté par des développeurs indépendants.
+        Autrement dit, l’<abbr>API</abbr> doit s’approcher autant que possible des standards industriels.
+      </p><p>
+        Les accès aux bases de données relationnelles sont un exemple de tâche ayant bénéficié d’une standardisation relativement bien réussie.
+        L’industrie a établie un langage commun — le standard <abbr title="Structured Query Language">SQL</abbr> — que les concepteurs du Java
+        ont enrobé dans des interfaces de programmation formant le standard <abbr title="Java DataBase Connectivity">JDBC</abbr>.
+        Ces interfaces sont aujourd’hui implementées par de nombreux logiciels libres et commerciaux.
+        Comme pour les bases de données, des méthodes d’accès aux informations géographiques ont été standardisées.
+        Mais les efforts en ce sens sont plus récents et leurs intégrations dans les logiciels, surtout les plus anciens,
+        sont incomplètes et pas toujours cohérentes.
+        Au moment d’écrire ces lignes, aucun produit de notre connaissance n’implémente la totalité des spécifications.
+        Mais on trouve de nombreuses implémentations couvrant un spectre plus ou moins large.
+        La bibliothèque Apache <abbr>SIS</abbr>® décrite dans ce document en est une.
+      </p><p>
+        Apache <abbr title="Spatial Information System">SIS</abbr> se caractérise par un effort soutenu de respect des standards.
+        De manière générale, le respect des standards exige un effort plus grand que ce qu’aurait requis un développement isolé,
+        mais se rentabilise par un double avantage: en plus d’accroître l’interopérabilité des données avec celles des projets externes,
+        il nous indique aussi une voie robuste à suivre pour l’élaboration du modèle conceptuel qui sera reflété par l’<abbr>API</abbr>.
+        En effet, les groupes d’experts qui conçoivent les standards anticipent des difficultés qui échappent parfois à l’ingénieur en début de projet,
+        mais qui risquent de le rattraper avant la fin.
+      </p>
 
-    <p id="GeoAPI-core">
-      GeoAPI est constitué de plusieurs modules.
-      Les modules <code>geoapi</code> et <code>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>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>
-
-    <details>
-      <summary>Pour en savoir plus sur les modules de GeoAPI</summary>
-      <article id="GeoAPI-modules">
-        <h2>Les modules de GeoAPI</h2>
-        <p>
-          Le projet GeoAPI est composé d’une partie standardisée (<code>geoapi</code>) et
-          d’une partie expérimentale (<code>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>SIS</abbr>),
-          car le module <code>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>geoapi-pending</code>.
-        </p><p>
-          Les modules de GeoAPI sont:
-        </p>
-        <ul>
-          <li><p>
-            <b><code>geoapi</code></b> — contient les interfaces couvertes par le
-            <a href="http://www.opengeospatial.org/standards/geoapi">standard GeoAPI de l’<abbr>OGC</abbr></a>.
-            Les versions finales de Apache <abbr>SIS</abbr> dépendent de ce module.
-          </p></li>
-          <li><p>
-            <b><code>geoapi-pending</code></b> — contient une
-            <em>copie</em> de toutes les interfaces du module <code>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>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>geoapi</code>
-            standard au moment de fusionner les branches avec le tronc.
-          </p></li>
-          <li><p>
-            <b><code>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>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>geoapi-proj4</code></b> — contient une
-            implémentation partielle des paquets <code>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>sis-referencing</code>
-            pour certaines fonctions.
-          </p></li>
-          <li><p>
-            <b><code>geoapi-netcdf</code></b> — contient une implémentation partielle des paquets
-            <code>org.opengis.referencing</code> et <code>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>sis-netcdf</code>.
-          </p></li>
-          <li><p>
-            <b><code>geoapi-openoffice</code></b> — contient
-            un <i>add-in</i> pour les suites bureautiques Libre/OpenOffice.org.
-            <!--
-            Apache <abbr>SIS</abbr> offre son propre <i>add-in</i> dans le module <code>sis-openoffice</code>,
-            mais utilise les mêmes noms de fonctions que le module de GeoAPI afin d’assurer une certaine compatibilité.
-            -->
-          </p></li>
-        </ul>
-      </article>
-    </details>
 
 
+      <h2 id="ConceptualModels">Sources des modèles conceptuels de Apache SIS</h2>
+      <p>
+        La majorité des standards utilisés par Apache <abbr>SIS</abbr> ont été élaborés
+        par le <a href="http://www.opengeospatial.org">consortium <i>Open Geospatial</i></a> (<abbr>OGC</abbr>),
+        parfois en collaboration avec l’<a href="http://www.iso.org">organisation internationale de normalisation</a> (<abbr>ISO</abbr>).
+        Certains standards de l’<abbr>ISO</abbr> deviennent eux-mêmes des standards Européens via la
+        <a href="http://inspire.jrc.ec.europa.eu">directive INSPIRE</a>, ou des standards français via l’<abbr>AFNOR</abbr>.
+        Ces standards offrent deux technologies clés:
+      </p>
+      <ul>
+        <li>
+          Permettre à une communauté d’annoncer leurs informations,
+          de manière à ce que des individus ou des systèmes en dehors de cette communauté puissent les découvrir.
+        </li>
+        <li>
+          Transférer des informations d’une communauté vers une autre en préservant leurs sémantiques,
+          même si les deux communautés utilisent des représentations internes très différentes.
+        </li>
+      </ul>
+      <p>
+        Ces standards sont fournis gratuitement à la communauté internationale sous la forme de
+        <a href="http://www.opengeospatial.org/standards/is">spécifications (fichiers <abbr title="Portable Document Format">PDF</abbr>)</a> ou de
+        <a href="http://schemas.opengis.net/gml/3.3/">schémas (fichiers <abbr title="XML Schema Definition">XSD</abbr>)</a>.
+        Les organismes de normalisation ne fabriquent pas de logiciel; pour obtenir une implémentation de ces spécifications,
+        les utilisateurs doivent choisir un des produits conformes disponibles sur le marché ou développer leur propres solutions.
+        C’est le respect volontaire de ces spécifications qui permet à des communautés à priori indépendantes d’échanger
+        plus facilement des informations géographiques.
+      </p>
+
+
+
+      <details>
+        <summary>Pour en savoir plus sur le processus de standardisation</summary>
+        <article id="OGC-process">
+          <header>
+            <h2>Processus de standardisation à l’<abbr>OGC</abbr></h2>
+          </header>
+          <p>
+            Les travaux de l’<abbr title="Open Geospatial Consortium">OGC</abbr> se font par courriers électroniques,
+            par conférences téléphoniques et par <a href="http://www.opengeospatial.org/event?category=ogctcpc">réunions réelles</a>.
+            L’<abbr>OGC</abbr> organise quatre réunions par années, chacune d’une durée de cinq jours,
+            hébergées par des organisations membres sponsorisant l’événement (compagnies, universités, centres de recherches, <i>etc.</i>).
+            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.
+            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>,
+            tandis que les <abbr>SWG</abbr> nécessitent de la part des participants un engagement à ne pas entraver
+            la diffusion du standard par des réclamations de propriétés intellectuelles.
+          </p>
+
+          <h2 id="OGC-SWG">Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</h2>
+          <p>
+            Pour être accepté, un projet de standardisation doit être supporté par un nombre minimal de membres appartement à des organisations distinctes.
+            Ces membres fondateurs rédigent une charte définissant les objectifs du <abbr>SWG</abbr>,
+            qui doit être approuvée par le comité technique de l’<abbr>OGC</abbr>.
+            Chaque membre fondateur est doté d’un droit de vote, dans les limites d’un membre votant par organisation.
+            Tout nouveau membre qui souhaite joindre le <abbr>SWG</abbr> après sa création se verra attribué un rôle d’observateur,
+            avec attribution sur demande d’un droit de vote après quelques mois d’observation.
+          </p><p>
+            Un <abbr>SWG</abbr> peut contenir plusieurs dizaines de membres,
+            mais les volontaires effectuant l’essentiel du travail sont habituellement moins nombreux.
+            Leurs propositions sont soumises à l’ensemble des membres du groupe, qui peuvent les accepter par consentement unanime.
+            Les objections, s’il y en a, doivent être argumentées et une alternative proposée.
+            Les <abbr>SWG</abbr> essaient généralement de débattre d’un problème jusqu’à ce qu’un consensus se forme
+            plutôt que d’avancer malgré des votes négatifs, même s’ils sont minoritaires.
+            Les décisions du groupes sont alors intégrées dans la spécification par un membre assumant le rôle d’éditeur.
+          </p><p>
+            Le groupe de travail doit autant que possible structurer la spécification sous forme d’un noyau autour duquel gravite diverses extensions.
+            Une suite de tests doit accompagner le standard, et permettre de classer les implémentations en fonction du niveau des tests passés.
+            Au moins une <i>implémentation de référence</i> passant les tests doit exister pour démontrer que le standard est utilisable.
+          </p><p>
+            Lorsque le standard est jugé prêt, le <abbr>SWG</abbr> vote une motion
+            proposant de le soumettre au vote des instances supérieures de l’<abbr>OGC</abbr>.
+            Cette procédure nécessite plusieurs mois.
+            Il existe une procédure plus rapide pour entériner des standards de fait, mais elle n’est appliquée qu’avec parcimonie.
+          </p>
+
+          <h2 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</h2>
+          <p>
+            Toute proposition de standard est d’abord examinée par le conseil d’architecture (<i><abbr>OGC</abbr> Architecture Board</i> — <abbr>OAB</abbr>).
+            Ce conseil vérifie que le standard répond aux exigences de l’<abbr>OGC</abbr> sur la forme,
+            sur la modularisation, et en termes d’intégration avec les autres standards.
+            Si l’<abbr>OAB</abbr> donne son aval, le standard est alors soumis au vote des membres du comité technique (<abbr>TC</abbr>).
+            Ce comité regroupe les principaux membres de l’<abbr>OGC</abbr> qui sont seuls habilités à donner le vote final.
+            En cas d’approbation, le standard est diffusé publiquement pour commentaires pendant une période de quelques mois.
+            Au terme de cette période, le <abbr title="Standard Working Group">SWG</abbr> doit examiner et répondre à chacun des commentaires.
+            Les éventuelles modifications au standard sous soumises à l’<abbr>OAB</abbr>, puis le standard est définitivement publié.
+            Cette diffusion est alors annoncée par un communiqué de presse de l’<abbr>OGC</abbr>.
+          </p><p>
+            Certains membres de l’<abbr title="Open Geospatial Consortium">OGC</abbr> et du <abbr title="Technical Committe">TC</abbr>
+            assurent aussi la liaison avec l’organisation internationale de normalisation (<abbr title="International Organization for Standardization">ISO</abbr>).
+            La coopération entre les deux organismes va dans les deux sens: l’<abbr>OGC</abbr> adopte les standards <abbr>ISO</abbr> comme base sur
+            laquelle développer de nouveaux standards, et certains de ces nouveaux standards <abbr>OGC</abbr> deviennent des standards <abbr>ISO</abbr>.
+          </p>
+
+          <h2 id="OGC-RFC">Procédure de soumission de propositions de modifications</h2>
+          <p>
+            Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications à des standards <abbr>OGC</abbr>.
+            Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles,
+            sont <a href="http://www.opengeospatial.org/standards/cr">disponibles en ligne</a>.
+            Chaque proposition est revue par le <abbr title="Standard Working Group">SWG</abbr>.
+          </p><p>
+            Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle, par exemple GitHub,
+            hébergés en dehors des structures de l’<abbr>OGC</abbr>.
+          </p>
+        </article>
+      </details>
+
+
+
+      <p>
+        Outre ces organisations formelles de normalisation, il existe aussi des organisations qui ne sont pas officiellement
+        dédiées à l’élaboration de normes mais dont les travaux ont été largement adoptés comme standards de fait.
+        En particulier, la base de données <a href="http://www.epsg.org">EPSG</a> fournit des codes numériques permettant d’identifier
+        facilement un système de référence des coordonnées parmi <a href="../../tables/CoordinateReferenceSystems.html">plusieurs milliers</a>.
+        Cette base de données est offerte par des compagnies pétrolières qui ont vu leur intérêt à ce que leurs prospections se fassent
+        bien à l’endroit voulu, sachant qu’elles ne contrôlent pas toujours la production des cartes sur lesquelles elles se positionnent.
+        D’autres exemples de standards de fait sont les formats
+        <a href="http://geotiff.osgeo.org">GeoTIFF</a> pour les données réparties sur une grille (les images), et
+        <a href="http://fr.wikipedia.org/wiki/Shapefile">Shapefile</a> pour les données vectorielles (les géométries).
+      </p><p>
+        Les standards <abbr>OGC</abbr> sont spécifiés dans plusieurs dizaines de documents.
+        Chaque document élabore un service, par exemple les transformations de coordonnées.
+        Le fonctionnement de chaque service est décrit par un ensemble de classes d’objets et leurs interactions.
+        Ces éléments sont illustrés par des diagrammes <abbr>UML</abbr> (<i>Unified Modeling Language</i>)
+        dans des spécifications dites « abstraites ».
+        Les <a href="http://www.opengeospatial.org/standards/as">spécifications abstraites</a> ne font référence à aucun langage informatique concret.
+        Leurs concepts peuvent se concrétiser dans un langage de programmation, une base de données ou un schéma <abbr>XML</abbr> de manière plus ou moins directe.
+        Il existe toutefois une part d’arbitraire dans la façon de concrétiser une spécification abstraite, étant donné que des ajustements sont souvent nécessaires
+        pour tenir compte des contraintes ou des conventions du langage ciblé.
+        Certaines structures de données n’existent que dans quelques langages, par exemple les unions qui existent en C/C++ mais pas en Java.
+      </p>
+
+
+
+      <details>
+        <summary>Pour en savoir plus sur les « spécifications d’implémentation »</summary>
+        <article id="implementation-standard">
+          <header>
+            <h2>Note historique</h2>
+          </header>
+          <p>
+            Au tournant du millénaire, les spécifications abstraites étaient explicitement concrétisées dans des <i>spécifications d’implémentations</i>.
+            Le terme « implémentation » était ici à prendre au sens de tout type d’interfaces (Java ou autres) dérivées des diagrammes
+            <abbr title="Unified Modeling Language">UML</abbr> — et non pas d’implémentations au sens du Java.
+            Des telles spécifications existaient pour les langages <abbr title="Structured Query Language">SQL</abbr>,
+            <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr> et Java.
+            Ces langages étant capables d’exécuter des procédures, les spécifications de cette époque définissaient
+            non seulement des structures de données, mais aussi des opérations s’appliquant sur ces structures.
+          </p><p>
+            Par la suite, l’engouement pour le « web 2.0 » a fait grimper l’intérêt pour le <abbr>XML</abbr> au détriment des autres langages.
+            Les anciennes spécifications d’implémentations ont été dépréciées, et les schémas <abbr title="XML Schema Definition">XSD</abbr>
+            sont devenus la principale concrétisation des spécifications abstraites.
+            Même la façon de concevoir les spécifications abstraites a évoluée: les opérations y sont plus rarement définies,
+            par conséquence ce qui reste ressemble davantage à des descriptions de schémas de base de données.
+            Certaines opérations qui étaient définies dans les anciennes normes apparaissent maintenant, sous une autre forme, dans les spécifications des services web.
+            Enfin le terme « spécification d’implémentation » a été abandonné, pour être englobé dans « standard <abbr title="Open Geospatial Consortium">OGC</abbr> ».
+            Mais malgré leur dépréciation, les <a href="http://www.opengeospatial.org/docs/retired">anciennes spécifications d’implémentation</a>
+            restent utiles aux programmes en langage Java car:
+          </p>
+          <ul>
+            <li>
+              Leurs modèles plus simples, appliqués aux mêmes concepts, aident à comprendre les nouvelles spécifications.
+            </li>
+            <li>
+              Ils définissent parfois des façons simples d’effectuer des tâches courantes
+              là où les nouvelles spécifications se limitent au cas général.
+            </li>
+            <li>
+              Les opérations étant plus souvent omises dans les nouvelles spécifications,
+              les anciennes spécifications restent un complément utile pour définir des <abbr>API</abbr>.
+            </li>
+          </ul>
+          <p>
+            Le projet Apache <abbr title="Spatial Information System">SIS</abbr> se base sur les spécifications les plus récentes,
+            tout en puisant dans les archives de l’<abbr title="Open Geospatial Consortium">OGC</abbr>
+            pour compléter certains standards abstraits ou les rendre un peu plus facile d’utilisation.
+            Certaines anciennes définitions sont conservées comme « méthodes de commodités »,
+            n’apportant pas toujours de nouvelles fonctionnalités mais facilitant l’usage pratique d’une bibliothèque.
+          </p>
+        </article>
+      </details>
+      <p>
+        Le tableau suivant liste les principales normes utilisées par le projet.
+        Plusieurs normes sont publiées à la fois comme standard <abbr>ISO</abbr> et comme standard <abbr>OGC</abbr>,
+        d’où la disposition côte-à-côte des deux premières colonnes.
+        La section des « spécifications d’implémentation » liste des spécifications qui apportent peu de concepts nouveaux
+        comparativement aux spécifications abstraites, mais précisent comment les représenter dans des contextes précis
+        tels qu’un document <abbr>XML</abbr>.
+        Les normes dépréciées mais malgré tout partiellement utilisées apparaissent <s>barrées</s>.
+        Enfin, les paquets GeoAPI seront introduits dans le chapitre suivant.
+      </p>
+      <table>
+        <caption>Principaux standards en relation avec le projet Apache <abbr>SIS</abbr></caption>
+        <tr>
+          <th>Norme <abbr>ISO</abbr></th>
+          <th>Norme <abbr>OGC</abbr></th>
+          <th>Titre</th>
+          <th>Paquet de GeoAPI</th>
+          <th>Paquet de Apache SIS</th>
+        </tr><tr>
+          <td class="separator" colspan="5">Spécifications abstraites</td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19103</td>
+          <td></td>
+          <td><i>Conceptual schema language</i></td>
+          <td><code>org.opengis.util</code></td>
+          <td><code>org.apache.sis.util.iso</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19115-1</td>
+          <td>Topic 11</td>
+          <td><i>Metadata</i></td>
+          <td><code>org.opengis.metadata</code></td>
+          <td><code>org.apache.sis.metadata.iso</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19115-2</td>
+          <td></td>
+          <td><i>Metadata — extensions for imagery and gridded data</i></td>
+          <td><code>org.opengis.metadata</code></td>
+          <td><code>org.apache.sis.metadata.iso</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19111</td>
+          <td>Topic 2</td>
+          <td><i>Spatial referencing by coordinates</i></td>
+          <td><code>org.opengis.referencing</code></td>
+          <td><code>org.apache.sis.referencing</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19111-2</td>
+          <td></td>
+          <td><i>Referencing — extension for parametric values</i></td>
+          <td><code>org.opengis.referencing</code></td>
+          <td><code>org.apache.sis.referencing</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19112</td>
+          <td></td>
+          <td><i>Spatial referencing by geographic identifier</i></td>
+          <td><code>org.opengis.referencing.gazetteer</code></td>
+          <td><code>org.apache.sis.referencing.gazetteer</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19108</td>
+          <td></td>
+          <td><i>Temporal Schema</i></td>
+          <td><code>org.opengis.temporal</code></td>
+          <td></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19107</td>
+          <td>Topic 1</td>
+          <td><i>Feature geometry</i></td>
+          <td><code>org.opengis.geometry</code></td>
+          <td><code>org.apache.sis.geometry</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19109</td>
+          <td>Topic 5</td>
+          <td><i>Rules for application schema</i></td>
+          <td><code>org.opengis.feature</code></td>
+          <td><code>org.apache.sis.feature</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19123</td>
+          <td>Topic 6</td>
+          <td><i>Schema for coverage geometry and functions</i></td>
+          <td><code>org.opengis.coverage</code></td>
+          <td><code>org.apache.sis.coverage</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19156</td>
+          <td>Topic 20</td>
+          <td><i>Observations and measurements</i></td>
+          <td><code>org.opengis.observation</code></td>
+          <td></td>
+        </tr><tr>
+          <td class="separator" colspan="5">Spécifications d’implémentation</td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19139</td>
+          <td></td>
+          <td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
+          <td></td>
+          <td><code>org.apache.sis.xml</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19136</td>
+          <td>OGC 07-036</td>
+          <td><i>Geography Markup Language (<abbr>GML</abbr>) Encoding Standard</i></td>
+          <td></td>
+          <td><code>org.apache.sis.xml</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19162</td>
+          <td>OGC 12-063</td>
+          <td><i>Well-known text representation of coordinate reference systems</i></td>
+          <td></td>
+          <td><code>org.apache.sis.io.wkt</code></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 13249</td>
+          <td></td>
+          <td><i><abbr>SQL</abbr> spatial</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td></td>
+          <td><s><abbr>OGC</abbr> 01-009</s></td>
+          <td><s><i>Coordinate Transformation Services</i></s></td>
+          <td><code>org.opengis.referencing</code></td>
+          <td><code>org.apache.sis.referencing</code></td>
+        </tr><tr>
+          <td></td>
+          <td><s><abbr>OGC</abbr> 01-004</s></td>
+          <td><s><i>Grid Coverage</i></s></td>
+          <td><code>org.opengis.coverage</code></td>
+          <td><code>org.apache.sis.coverage</code></td>
+        </tr><tr>
+          <td></td>
+          <td><abbr>SLD</abbr></td>
+          <td><i>Styled Layer Descriptor</i></td>
+          <td><code>org.opengis.style</code></td>
+          <td></td>
+        </tr><tr>
+          <td class="separator" colspan="5">Services web</td>
+        </tr><tr>
+          <td></td>
+          <td><abbr>CSW</abbr></td>
+          <td><i>Catalog Services</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19128</td>
+          <td><abbr>WMS</abbr></td>
+          <td><i>Web Map Service</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td></td>
+          <td><abbr>WMTS</abbr></td>
+          <td><i>Web Map Tile Service</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td><abbr>ISO</abbr> 19142</td>
+          <td><abbr>WFS</abbr></td>
+          <td><i>Web Feature Service</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td></td>
+          <td><abbr>WCS</abbr></td>
+          <td><i>Web Coverage Service</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td></td>
+          <td><abbr>WPS</abbr></td>
+          <td><i>Web Processing Service</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td></td>
+          <td>Open<abbr>LS</abbr></td>
+          <td><i>Location Services</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td></td>
+          <td><abbr>SWE</abbr></td>
+          <td><i>Sensor Web Enablement</i></td>
+          <td></td>
+          <td></td>
+        </tr><tr>
+          <td></td>
+          <td><abbr>SOS</abbr></td>
+          <td><i>Sensor Observation Service</i></td>
+          <td></td>
+          <td></td>
+        </tr>
+      </table>
+
+
+
+      <h2 id="GeoAPI">Des modèles conceptuels vers des interfaces Java: GeoAPI</h2>
+      <p>
+        Le projet <a href="http://www.geoapi.org">GeoAPI</a> offre un ensemble d’interfaces Java pour les applications géo-spatiales.
+        Dans une séries de paquets <code>org.opengis.*</code>, GeoAPI définit des structures représentant des méta-données,
+        des systèmes de référence des coordonnées, ainsi que des opérations effectuant des projections cartographiques.
+        Dans une partie qui n’est pas encore standardisée — dénommée <i>pending</i> — GeoAPI définit des structures
+        représentant des images géo-référencées, des géométries, des filtres pouvant s’appliquer à des requêtes, et d’autres fonctionnalités.
+        Ces interfaces suivent de très près les spécifications de l’<abbr>OGC</abbr>, tout en les interprétant et en les adaptant
+        de manière à répondre aux attentes des développeurs Java — par exemple en se conformant aux conventions de nommage.
+        Ces interfaces bénéficient à la fois aux applications clientes et aux bibliothèques:
+      </p>
+      <ul>
+        <li><p>
+          Les développeurs des applications clientes bénéficient d’une plus grande base de connaissances disponible sur internet
+          (due aux nombreuses publications en lien avec les standards de l’<abbr>OGC</abbr>), ainsi que d’une interopérabilité accrue.
+          L’interopérabilité est facilitée par une meilleure séparation entre les applications qui <em>appellent</em> les fonctions de GeoAPI,
+          et les bibliothèques qui <em>implémentent</em> GeoAPI. Il s’agit d’une séparation similaire à celle qu’offrent les interfaces
+          <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/"><abbr>JDBC</abbr></a> (<i>Java Database Connectivity</i>) du Java standard.
+          En utilisant l’<abbr>API</abbr> des interfaces, les développeurs peuvent faire abstraction de l’implémentation sous-jacente.
+          Par exemple ils peuvent effectuer des projections cartographiques à l’aide des bibliothèques
+          <a href="http://www.geoapi.org/geoapi-proj4/index.html">Proj.4</a> ou Apache <abbr>SIS</abbr>,
+          sans changer leurs programmes lorsqu’ils changent de bibliothèque.
+        </p></li>
+        <li><p>
+          Les développeurs des bibliothèques héritent de l’expertise des auteurs des spécifications, via les modèles que représentent les interfaces.
+          GeoAPI fournit aussi un cadre dans lequel les développeurs peuvent implémenter en priorité les fonctionnalité qui leurs sont le plus nécessaires,
+          tout en ayant des points où raccrocher les développements futurs.
+          Par exemple les clients peuvent appeler une fonction de GeoAPI même si elle n’est pas encore supportée par la bibliothèque,
+          quitte à obtenir une valeur nulle en attendant qu’une nouvelle version de la bibliothèque retourne une valeur intéressante.
+        </p></li>
+      </ul>
 
-    <h3 id="UML-annotation">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>OGC</abbr> ou <abbr>ISO</abbr>,
-      GeoAPI indique sa provenance à l’aide d’annotations définies dans le paquet <code>org.opengis.annotation</code>.
-      En particulier l’annotation <code>@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>@UML</code> indique
-      que l’interface Java qui la suit (<code>ProjectedCRS</code>) est définie à partir du type
-      <code>SC_ProjectedCRS</code> du standard <abbr>ISO</abbr> 19111.
-      La seconde annotation <code>@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>.
-    </p>
+      <details>
+        <summary>Pour en savoir plus sur les origines du projet GeoAPI</summary>
+        <article>
+          <header>
+            <h2>Historique du projet GeoAPI</h2>
+          </header>
+          <p>
+            En 2001, le consortium <i>Open GIS</i> (l’ancien nom du consortium <i>Open Geospatial</i>) publia la spécification d’implémentation
+            <a href="http://www.opengeospatial.org/standards/ct"><abbr>OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
+            Cette spécification, élaborée par <i>Computer Aided Development Corporation</i> (Cadcorp),
+            était accompagnée d’interfaces <abbr>COM</abbr>, <abbr>CORBA</abbr> et Java.
+            À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques.
+            Les interfaces de l’<abbr>OGC</abbr> anticipaient tout de même un monde connecté en réseau,
+            mais misaient plutôt — dans le cas du Java — sur la technologie <abbr>RMI</abbr> (<i>Remote Method Invocation</i>).
+            Bien que le projet GeoAPI n’existait pas encore, nous désignons rétrospectivement ces interfaces historiques sous le nom de
+            « <a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a> ».
+            Ces interfaces utilisaient déjà le nom de paquet <code>org.opengis</code>, qui sera adopté par GeoAPI.
+          </p><p>
+            En 2002, des développeurs de projets libres ont lancé un
+            <a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr>API</abbr> géo-spatial</a>.
+            La proposition initiale suscita l’intérêt d’au moins cinq projets libres.
+            Le projet fut créé sur <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
+            qui héberge depuis lors le code source dans un <a href="http://www.geoapi.org/source-repository.html">dépôt Subversion</a>.
+            Le projet pris le nom de « GeoAPI » à ce moment là, et utilisa les interfaces de la spécification <abbr>OGC</abbr> 01-009 comme point de départ.
+          </p><p>
+            Quelques mois plus tard, l’<abbr>OGC</abbr> lança le projet
+            <a href="http://www.opengeospatial.org/standards/go"><abbr>GO-1</abbr>: <i>Geographic Objects</i></a>,
+            qui poursuivait des buts similaires à ceux de GeoAPI.
+            Entre-temps, l’<abbr>OGC</abbr> avait abandonné certaines de leur spécifications en faveur des normes <abbr>ISO</abbr>.
+            GeoAPI et <abbr>GO-1</abbr> ont joint leurs efforts pour une refonte des interfaces de GeoAPI en les basant sur ces nouvelles normes <abbr>ISO</abbr>.
+            La première mouture, <a href="http://www.geoapi.org/1.0/index.html">GeoAPI 1.0</a>, a servit de point de départ
+            aux premières ébauches de la spécification <abbr>OGC</abbr> 03-064 du groupe de travail <abbr>GO</abbr>-1.
+            La version finale de cette spécification est devenue un standard <abbr>OGC</abbr> en 2005, et
+            <a href="http://www.geoapi.org/2.0/index.html">GeoAPI 2.0</a> a été publiée à cette occasion.
+          </p><p>
+            Le projet <abbr>GO</abbr>-1 était porté essentiellement par une compagnie nommée <i>Polexis</i>.
+            Son rachat par <i>Sys Technology</i> et le changement de priorité des nouveaux propriétaires
+            ont causé l’arrêt des travaux de <abbr>GO</abbr>-1, et par ricochet un ralentissement des développements de GeoAPI.
+            Afin de reprendre les développements, un nouveau groupe de travail « GeoAPI 3.0 » a été créé à l’<abbr>OGC</abbr>.
+            Ce groupe a réduit les ambitions par rapport à GeoAPI 2.0 en se concentrant sur les interfaces les plus stables,
+            et en plaçant les autres — notamment les géométries — dans un module nommé « <a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a> »,
+            pour considérations futures. <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> est devenu un
+            <a href="http://www.opengeospatial.org/standards/geoapi">standard <abbr>OGC</abbr></a> en 2011.
+            Cette version a été la première à être déployée dans le <a href="http://search.maven.org/#search|ga|1|geoapi">dépôt central de Maven</a>.
+          </p>
+        </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>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>@UML</code>
+        et des fichiers de propriétés, décrits dans la section suivante.
+      </p>
+
+      <details>
+        <summary>Pour en savoir plus sur les raisons d’une définition manuelle des interfaces Java</summary>
+        <article id="SpecificationToInterfaces">
+          <header>
+            <h2>Des spécifications de l’<abbr>OGC</abbr> aux interfaces Java</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>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>UML</abbr> plutôt que <abbr>XSD</abbr>.
+          </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:
+          </p>
+          <ul>
+            <li>
+              <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>API</abbr> Java.

[... 806 lines stripped ...]


Mime
View raw message