sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1615943 [2/3] - /sis/site/trunk/content/book/fr/developer-guide.html
Date Tue, 05 Aug 2014 15:15:14 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=1615943&r1=1615942&r2=1615943&view=diff
==============================================================================
--- sis/site/trunk/content/book/fr/developer-guide.html [iso-8859-1] (original)
+++ sis/site/trunk/content/book/fr/developer-guide.html [UTF-8] Tue Aug  5 15:15:13 2014
@@ -22,86 +22,86 @@
 
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
   <head>
-    <title>Introduction à Apache SIS</title>
+    <title>Introduction à Apache SIS</title>
     <link rel="stylesheet" type="text/css" href="../book.css"/>
   </head>
   <body>
     <!-- From this point, shift indentation 4 spaces to the left for saving space. -->
 
-<p style="font-size: 30pt; font-weight: 900">Introduction à Apache SIS®</p>
+<p style="font-size: 30pt; font-weight: 900">Introduction à Apache SIS®</p>
 
 
-<h1 id="Foreword">Préface</h1>
+<h1 id="Foreword">Préface</h1>
 <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.
+  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
+  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.
+  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.
+  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,
-  allant jusqu’à une participation à certains travaux de l’<abbr title="Open Geospatial Consortium">OGC</abbr>.
-  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 title="Application Programming Interface">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,
+  Apache <abbr title="Spatial Information System">SIS</abbr> se caractérise par un effort soutenu de respect des standards,
+  allant jusqu’à une participation à certains travaux de l’<abbr title="Open Geospatial Consortium">OGC</abbr>.
+  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 title="Application Programming Interface">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="About">Conventions utilisées dans ce guide</h2>
+<h2 id="About">Conventions utilisées dans ce guide</h2>
 <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>SIS</abbr> et les standards,
-  ces éléments sont en outre représentés en utilisant les codes de couleurs suivants:
+  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>SIS</abbr> et les standards,
+  ces éléments sont en outre représentés en utilisant les codes de couleurs suivants:
 </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.
+    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.
+    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.
+    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>
-    Les autres éléments, notamment ceux du Java standard, sont laissés en noir.
+    Les autres éléments, notamment ceux du Java standard, sont laissés en noir.
     Exemple: <code>String</code>.
   </li>
 </ul>
@@ -110,209 +110,209 @@
 
 <h1 id="Standards">Standards et normes</h1>
 <p>
-  La majorité des standards utilisés par Apache <abbr title="Spatial Information System">SIS</abbr> ont été élaborés
+  La majorité des standards utilisés par Apache <abbr title="Spatial Information System">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:
+  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.
+    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.
+    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.
+  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><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="../sis-referencing/supported-codes.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).
+  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="../sis-referencing/supported-codes.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>
 
 
 
-<h2 id="OGC-process">Processus de standardisation à l’<abbr>OGC</abbr></h2>
-<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.
+<h2 id="OGC-process">Processus de standardisation à l’<abbr>OGC</abbr></h2>
+<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 title="Open Geospatial Consortium">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>Discussion Working Group</i> (<abbr>DWG</abbr>) si le travail est au stade exploratoire,
+  Les réunions de l’<abbr title="Open Geospatial Consortium">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>Discussion Working Group</i> (<abbr>DWG</abbr>) si le travail est au stade exploratoire,
   ou <i>Standard Working Group</i> (<abbr>SWG</abbr>) si le travail de normalisation peut commencer.
-  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.
+  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>
 
 
 
 <h3 id="OGC-SWG">Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</h3>
 <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 title="Standard Working Group">SWG</abbr>,
-  qui doit être approuvée par le comité technique de l’<abbr title="Open Geospatial Consortium">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.
+  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 title="Standard Working Group">SWG</abbr>,
+  qui doit être approuvée par le comité technique de l’<abbr title="Open Geospatial Consortium">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 title="Standard Working Group">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.
+  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.
+  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 title="Standard Working Group">SWG</abbr> vote une motion
-  proposant de le soumettre au vote des instances supérieures de l’<abbr title="Open Geospatial Consortium">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.
+  Lorsque le standard est jugé prêt, le <abbr title="Standard Working Group">SWG</abbr> vote une motion
+  proposant de le soumettre au vote des instances supérieures de l’<abbr title="Open Geospatial Consortium">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>
 
 
 
-<h3 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</h3>
+<h3 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</h3>
 <p>
-  Toute proposition de standard est d’abord examinée par le conseil d’architecture
+  Toute proposition de standard est d’abord examinée par le conseil d’architecture
   (<i><abbr title="Open Geospatial Consortium">OGC</abbr> Architecture Board</i> - <abbr>OAB</abbr>).
-  Ce conseil vérifie que le standard répond aux exigences de l’<abbr title="Open Geospatial Consortium">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 title="Technical Committe">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>.
+  Ce conseil vérifie que le standard répond aux exigences de l’<abbr title="Open Geospatial Consortium">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 title="Technical Committe">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>.
+  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>
 
 
 
-<h3 id="OGC-RFC">Procédure de soumission de propositions de modifications</h3>
+<h3 id="OGC-RFC">Procédure de soumission de propositions de modifications</h3>
 <p>
-  Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications
-  à des standards <abbr title="Open Geospatial Consortium">OGC</abbr>.
-  Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles,
+  Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications
+  à des standards <abbr title="Open Geospatial Consortium">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.
-  En particulier, le projet GeoAPI continue à utiliser un <a href="http://jira.codehaus.org/browse/GEO">système de tâches JIRA</a>
-  hébergé en dehors des structures de l’<abbr title="Open Geospatial Consortium">OGC</abbr>.
-  Cet état des choses existe en partie pour des raisons historiques, et en partie parce que les
-  développements du projet GeoAPI se font davantage au niveau d’un code source plutôt qu’au
+  Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle.
+  En particulier, le projet GeoAPI continue à utiliser un <a href="http://jira.codehaus.org/browse/GEO">système de tâches JIRA</a>
+  hébergé en dehors des structures de l’<abbr title="Open Geospatial Consortium">OGC</abbr>.
+  Cet état des choses existe en partie pour des raisons historiques, et en partie parce que les
+  développements du projet GeoAPI se font davantage au niveau d’un code source plutôt qu’au
   niveau de documents ou de diagrammes de classes.
 </p>
 
 
 
-<h2 id="SpecificationTypes">Les différents types de spécifications</h2>
+<h2 id="SpecificationTypes">Les différents types de spécifications</h2>
 <p>
-  Les standards <abbr title="Open Geospatial Consortium">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 standards <abbr title="Open Geospatial Consortium">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 ».
 </p><p>
-  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é. Par exemple:
+  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é. Par exemple:
 </p>
 <ul>
   <li>
-    L’approche orientée objets se concrétise par des solutions verbeuses dans certains langages
-    (notamment le <abbr>XML</abbr> défini par <abbr>ISO</abbr> 19139), par exemple pour le support du polymorphisme.
+    L’approche orientée objets se concrétise par des solutions verbeuses dans certains langages
+    (notamment le <abbr>XML</abbr> défini par <abbr>ISO</abbr> 19139), par exemple pour le support du polymorphisme.
   </li>
   <li>
-    Certaines structures de données n’existent que dans quelques langages,
+    Certaines structures de données n’existent que dans quelques langages,
     par exemple les unions qui existent en C/C++ mais pas en Java.
   </li>
   <li>
-    Certaines spécifications (surtout les plus anciennes) définissent des opérations,
-    qui se prêtent bien aux langages de programmation ou à des services mais pas à des bases de données.
+    Certaines spécifications (surtout les plus anciennes) définissent des opérations,
+    qui se prêtent bien aux langages de programmation ou à des services mais pas à des bases de données.
   </li>
 </ul>
 <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>,
+  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.
+  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/standards/retired">anciennes spécifications d’implémentations</a>
+  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/standards/retired">anciennes spécifications d’implémentations</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.
+    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.
+    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
+    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 title="Application Programming Interface">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.
+  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><p>
-  Le tableau suivant liste les principales normes utilisées par le projet.
-  Plusieurs normes sont publiées à la fois comme standard <abbr title="International Organization for Standardization">ISO</abbr>
-  et comme standard <abbr title="Open Geospatial Consortium">OGC</abbr>, d’où la disposition côte-à-côte des deux premières colonnes.
-  Les normes dépréciées mais malgré tout utilisées apparaissent <s>barrées</s>.
+  Le tableau suivant liste les principales normes utilisées par le projet.
+  Plusieurs normes sont publiées à la fois comme standard <abbr title="International Organization for Standardization">ISO</abbr>
+  et comme standard <abbr title="Open Geospatial Consortium">OGC</abbr>, d’où la disposition côte-à-côte des deux premières colonnes.
+  Les normes dépréciées mais malgré tout utilisées apparaissent <s>barrées</s>.
   Enfin, les paquets GeoAPI seront introduits dans le chapitre suivant.
 </p>
 <table>
-  <caption>Principaux standards utilisés par le projet Apache <abbr>SIS</abbr></caption>
+  <caption>Principaux standards utilisés par le projet Apache <abbr>SIS</abbr></caption>
   <tr>
     <th>Norme <abbr>ISO</abbr></th>
     <th>Norme <abbr>OGC</abbr></th>
@@ -320,7 +320,7 @@
     <th>Paquet GeoAPI</th>
   </tr>
   <tr>
-    <td class="separator" colspan="4">Spécifications abstraites</td>
+    <td class="separator" colspan="4">Spécifications abstraites</td>
   </tr>
   <tr>
     <td><abbr>ISO</abbr> 19103</td>
@@ -371,7 +371,7 @@
     <td><code>org.opengis.observation</code></td>
   </tr>
   <tr>
-    <td class="separator" colspan="4">Spécifications d’implémentation</td>
+    <td class="separator" colspan="4">Spécifications d’implémentation</td>
   </tr>
   <tr>
     <td><abbr>ISO</abbr> 19139</td>
@@ -458,240 +458,240 @@
 
 
 
-<h2 id="DefinitionOfTerms">Définitions des termes</h2>
+<h2 id="DefinitionOfTerms">Définitions des termes</h2>
 <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.
+  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.
+  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.
+  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
+  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 title="International Organization for Standardization">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.
+  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>
 
 
 
 <h1 id="GeoAPI">GeoAPI</h1>
 <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 class="GeoAPI">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 title="Open Geospatial Consortium">OGC</abbr>,
-  tout en les interprétant et en les adaptant de manière à répondre aux attentes des développeurs Java — par exemple
+  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 class="GeoAPI">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 title="Open Geospatial Consortium">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:
+  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 title="Open Geospatial Consortium">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
+    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 title="Open Geospatial Consortium">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 title="Application Programming Interface">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
+    En utilisant l’<abbr title="Application Programming Interface">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 title="Spatial Information System">SIS</abbr>,
-    sans changer leurs programmes lorsqu’ils changent de bibliothèque.
+    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.
+    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>
 
 <aside>
   <p><b>Historique</b></p>
   <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
+    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
+    Cette spécification, élaborée par <i>Computer Aided Development Corporation</i> (Cadcorp), était accompagnée d’interfaces
     <abbr title="Component Object Model">COM</abbr>, <abbr title="Common Object Request Broker Architecture">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 title="Open Geospatial Consortium">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 class="GeoAPI">org.opengis</code>, qui sera adopté par GeoAPI.
+    À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques.
+    Les interfaces de l’<abbr title="Open Geospatial Consortium">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 class="GeoAPI">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 title="Application Programming Interface">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.
+    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 title="Application Programming Interface">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 title="Open Geospatial Consortium">OGC</abbr> lança le projet
+    Quelques mois plus tard, l’<abbr title="Open Geospatial Consortium">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 title="International Organization for Standardization">ISO</abbr>.
+    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 title="International Organization for Standardization">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.
+    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 title="Open Geospatial Consortium">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
+    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 title="Open Geospatial Consortium">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>.
+    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>
 </aside>
 
 
-<h2 id="SpecificationToInterfaces">Des spécifications aux interfaces</h2>
+<h2 id="SpecificationToInterfaces">Des spécifications aux interfaces</h2>
 <p>
-  Les standards de l’<abbr title="Open Geospatial Consortium">OGC</abbr> étant définis par des moyens bien éprouvés en génie logiciel,
-  il est possible de générer automatiquement des interfaces Java à l’aide d’outils relativement répandus.
-  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 title="Unified Modeling Language">UML</abbr>
-  plutôt que <abbr title="XML Schema Definition">XSD</abbr>.
+  Les standards de l’<abbr title="Open Geospatial Consortium">OGC</abbr> étant définis par des moyens bien éprouvés en génie logiciel,
+  il est possible de générer automatiquement des interfaces Java à l’aide d’outils relativement répandus.
+  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 title="Unified Modeling Language">UML</abbr>
+  plutôt que <abbr title="XML Schema Definition">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:
+  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 title="XML Schema Definition">XSD</abbr> sont beaucoup plus verbeux
-      que les schémas <abbr title="Unified Modeling Language">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>
+      Certains schémas <abbr title="XML Schema Definition">XSD</abbr> sont beaucoup plus verbeux
+      que les schémas <abbr title="Unified Modeling Language">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
+      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.
+      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 title="XML Schema Definition">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>ISO</abbr> 19115.
-      Cette redondance n’est absolument pas nécessaire à un programme Java.
+      Les schémas <abbr title="XML Schema Definition">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>ISO</abbr> 19115.
+      Cette redondance n’est absolument pas nécessaire à un programme Java.
     </p></div>
   </li>
   <li>
     <p>
-      Les standards de l’<abbr title="Open Geospatial Consortium">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>.
+      Les standards de l’<abbr title="Open Geospatial Consortium">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 title="Open Geospatial Consortium">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.
+      la classe <code class="OGC">MD_Identifier</code> de l’<abbr title="Open Geospatial Consortium">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>
   </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.
+      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>,
+      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.
+      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>
   </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.
+      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.
+      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>
   </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.
+      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
+      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.
+      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>
 <p>
-  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.
+  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>
 
 
 
-<h3 id="UML-annotation">Correspondances explicitées par l’annotation <code>@UML</code></h3>
+<h3 id="UML-annotation">Correspondances explicitées par l’annotation <code>@UML</code></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
+  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>.
+  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>.
 </p>
 
 <pre><b>package</b> <code class="GeoAPI">org.opengis.referencing.crs</code>;
@@ -712,29 +712,29 @@
 }</pre>
 
 <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 title="Open Geospatial Consortium">OGC</abbr>,
-  ou pour écrire des éléments dans un document <abbr>XML</abbr>. L’exemple suivant affiche le nom standard de la
-  méthode <code class="GeoAPI">getTitle()</code> de l’interface <code class="GeoAPI">Citation</code>:
+  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 title="Open Geospatial Consortium">OGC</abbr>,
+  ou pour écrire des éléments dans un document <abbr>XML</abbr>. L’exemple suivant affiche le nom standard de la
+  méthode <code class="GeoAPI">getTitle()</code> de l’interface <code class="GeoAPI">Citation</code>:
 </p>
 
 <pre>Class&lt;?&gt; <var>type</var>   = <code class="GeoAPI">Citation</code>.class;
 Method   <var>method</var> = <var>type</var>.getMethod("<code class="GeoAPI">getTitle</code>", (Class&lt;?&gt;[]) null);
 <code class="GeoAPI">UML</code>      <var>annot</var>  = <var>method</var>.getAnnotation(<code class="GeoAPI">UML</code>.class);
 String   <var>ident</var>  = <var>annot</var>.identifier();
-System.out.println("Le nom standard de la méthode " + <var>method</var>.getName() + " est " + <var>ident</var>);</pre>
+System.out.println("Le nom standard de la méthode " + <var>method</var>.getName() + " est " + <var>ident</var>);</pre>
 
 <p>
-  La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
-  <code class="SIS">getStandardName(Class)</code> pour effectuer cette opération.
+  La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
+  <code class="SIS">getStandardName(Class)</code> pour effectuer cette opération.
 </p>
 
 <p>
-  L’opération inverse — obtenir la classe et méthode Java d’un nom standard — est un peu plus lourde.
-  Elle nécessite la lecture du fichier <code class="GeoAPI">class-index.properties</code> fournit dans le
-  paquet <code class="GeoAPI">org.opengis.annotation</code>. L’exemple suivant lit ce fichier juste avant
-  de rechercher le nom de l’interface correspondant à <code class="OGC">CI_Citation</code>.
-  Toutefois les utilisateurs sont encouragés à ne lire ce fichier qu’une fois et de conserver son contenu dans
+  L’opération inverse — obtenir la classe et méthode Java d’un nom standard — est un peu plus lourde.
+  Elle nécessite la lecture du fichier <code class="GeoAPI">class-index.properties</code> fournit dans le
+  paquet <code class="GeoAPI">org.opengis.annotation</code>. L’exemple suivant lit ce fichier juste avant
+  de rechercher le nom de l’interface correspondant à <code class="OGC">CI_Citation</code>.
+  Toutefois les utilisateurs sont encouragés à ne lire ce fichier qu’une fois et de conserver son contenu dans
   une cache de leur application.
 </p>
 
@@ -745,25 +745,25 @@ System.out.println("Le nom standard de l
 String <var>isoName</var> = "<code class="OGC">CI_Citation</code>";
 String <var>geoName</var> = getProperty(<var>isoName</var>);
 Class&lt;?&gt;  <var>type</var> = Class.forName(<var>geoName</var>);
-System.out.println("L’interface GeoAPI du type <abbr>ISO</abbr> " + <var>isoName</var> + " est " + <var>type</var>);</pre>
+System.out.println("L’interface GeoAPI du type <abbr>ISO</abbr> " + <var>isoName</var> + " est " + <var>type</var>);</pre>
 
 <p>
-  La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
-  <code class="SIS">forStandardName(String)</code> pour effectuer cette opération.
+  La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
+  <code class="SIS">forStandardName(String)</code> pour effectuer cette opération.
 </p>
 
 
 
 <h3 id="MappingToJDK">Correspondances implicites avec le <abbr>JDK</abbr> standard</h3>
 <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,
+  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.
+  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.
 </p>
 <table>
   <caption>Correspondances entre <abbr>ISO</abbr> 19103 et <abbr>JDK</abbr></caption>
@@ -807,7 +807,7 @@ System.out.println("L’interface Geo
   </tr>
   <tr>
     <td><code class="OGC">FreeText</code></td>
-    <td>(pas d’équivalent)</td>
+    <td>(pas d’équivalent)</td>
     <td class="leftBorder">Voir <code class="GeoAPI">org.opengis.util.InternationalString</code> ci-dessous.</td>
   </tr>
   <tr>
@@ -861,8 +861,8 @@ System.out.println("L’interface Geo
   <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>
+    <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>

[... 1825 lines stripped ...]


Mime
View raw message