sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1014217 - in /websites/staging/sis/trunk/content: ./ faq_fr.html
Date Mon, 19 Jun 2017 13:26:24 GMT
Author: buildbot
Date: Mon Jun 19 13:26:24 2017
New Revision: 1014217

Log:
Staging update by buildbot for sis

Modified:
    websites/staging/sis/trunk/content/   (props changed)
    websites/staging/sis/trunk/content/faq_fr.html

Propchange: websites/staging/sis/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Jun 19 13:26:24 2017
@@ -1 +1 @@
-1796999
+1799207

Modified: websites/staging/sis/trunk/content/faq_fr.html
==============================================================================
--- websites/staging/sis/trunk/content/faq_fr.html (original)
+++ websites/staging/sis/trunk/content/faq_fr.html Mon Jun 19 13:26:24 2017
@@ -134,7 +134,6 @@ Son contenu est traduit de la <a href="f
 </li>
 </ul>
 </li>
-<li><a href="#abreviations-utilisees-dans-ce-faq">Abréviations utilisées
dans ce FAQ</a></li>
 </ul>
 </div>
 <h1 id="referencing">Géoréférencement<a class="headerlink" href="#referencing"
title="Permanent link">&para;</a></h1>
@@ -186,22 +185,22 @@ Une source bien connue de ces définit
 Les systèmes de coordonnées prédéfinis dans Apache SIS sont listés à la
page
 <a href="tables/CoordinateReferenceSystems.html">Coordinate Reference Systems</a>.</p>
 <h3 id="axisOrder">Qu’est ce que le problème d’ordre des axes et comment
est il abordé ?<a class="headerlink" href="#axisOrder" title="Permanent link">&para;</a></h3>
-<p>L’ordre des axes est spécifié par l’autorité (typiquement un
organisme public) qui défini les Systèmes de Référence des Coordonnées (CRS).
-L’ordre dépend du type de CRS et du pays qui définit le CRS.
-Dans le cas d’un CRS géographique, l’ordre des axes (<em>latitude</em>,
<em>longitude</em>) est largement répandu chez les géographes et les pilotes
depuis des siècles.
-Toutefois certains développeurs de logiciels ont tendance à toujours utiliser l’ordre
(<em>x</em>, <em>y</em>) pour tous les CRS.
-Ces pratiques différentes ont conduit à des définitions contradictoires d’ordre
des axes pour presque tous les CRS de type <code>GeographicCRS</code>,
+<p>L’ordre des axes est spécifié par l’autorité (typiquement un
organisme public) qui défini les Systèmes de Référence des Coordonnées (<abbr
title="Coordinate Reference System">CRS</abbr>).
+L’ordre dépend du type de <abbr title="Coordinate Reference System">CRS</abbr>
et du pays qui définit le <abbr title="Coordinate Reference System">CRS</abbr>.
+Dans le cas d’un <abbr title="Coordinate Reference System">CRS</abbr> géographique,
l’ordre des axes (<em>latitude</em>, <em>longitude</em>) est
largement répandu chez les géographes et les pilotes depuis des siècles.
+Toutefois certains développeurs de logiciels ont tendance à toujours utiliser l’ordre
(<em>x</em>, <em>y</em>) pour tous les <abbr title="Coordinate
Reference System">CRS</abbr>.
+Ces pratiques différentes ont conduit à des définitions contradictoires d’ordre
des axes pour presque tous les <abbr title="Coordinate Reference System">CRS</abbr>
de type <code>GeographicCRS</code>,
 pour certains <code>ProjectedCRS</code> de l’hémisphère sud (Afrique
de sud, Australie, <em>etc.</em>) et pour certaines projections polaires entre
autre.</p>
-<p>Pour chaque CRS identifié par un code EPSG, l’ordre officiel des axes peut
être vérifié avec
+<p>Pour chaque <abbr title="Coordinate Reference System">CRS</abbr> identifié
par un code EPSG, l’ordre officiel des axes peut être vérifié avec
 le registre EPSG à l’adresse <a href="http://www.epsg-registry.org">http://www.epsg-registry.org</a>
 (à ne pas confondre avec d’autres sites ayant « epsg » dans leur nom
 mais qui sont sans aucune relation avec l’organisme en charge des définitions EPSG) :
 Cliquez sur le lien <em>« Retrieve by code »</em> et entrez le code
numérique.
 Cliquez ensuite sur le lien <em>« View »</em> de la partie droite
 et cliquez sur le symbole <em>« + »</em> à gauche de <em>« Axes »</em>.</p>
-<p>Les standards OGC récents stipulent que l’ordre des axes est celui défini
par l’autorité.
-Les standards OGC plus anciens utilisaient l’ordre des axes (<em>x</em>,
<em>y</em>), ignorant la définition de l’autorité.
-Parmi les standards OGC obsolètes qui utilisent un ordre des axes non-conforme,
+<p>Les standards <abbr title="Open Geospatial Consortium">OGC</abbr> récents
stipulent que l’ordre des axes est celui défini par l’autorité.
+Les standards <abbr title="Open Geospatial Consortium">OGC</abbr> plus anciens
utilisaient l’ordre des axes (<em>x</em>, <em>y</em>), ignorant
la définition de l’autorité.
+Parmi les standards <abbr title="Open Geospatial Consortium">OGC</abbr> obsolètes
qui utilisent un ordre des axes non-conforme,
 l’un des plus influent est la version 1 de la spécification <em>Well Known
Text</em> (WKT).
 Selon ce format très utilisé, les définitions WKT sans éléments <code>AXIS[…]</code>
 doivent par défaut être dans l’ordre (<em>longitude</em>, <em>latitude</em>)
ou (<em>x</em>, <em>y</em>).
@@ -209,7 +208,7 @@ Dans la version 2 du format WKT, les �
 et doivent contenir explicitement le sous-élément <code>ORDER[…]</code>
pour appuyer l’ordre des axes à appliquer.</p>
 <p>Beaucoup de logiciels utilisent toujours l’ancien ordre des axes (<em>x</em>,
<em>y</em>), parfois parce qu’il est plus simple à implémenter.
 Mais Apache SIS suit l’ordre des axes <em>tel que défini par l’autorité</em>
(à l’exception de la lecture de fichier WKT 1).
-Il permet toutefois de changer l’ordre des axes après la création d’un CRS.
+Il permet toutefois de changer l’ordre des axes après la création d’un <abbr
title="Coordinate Reference System">CRS</abbr>.
 Ce changement se fait avec le code suivant :</p>
 <div class="codehilite"><pre><span class="n">CoordinateReferenceSystem</span>
<span class="n">crs</span> <span class="o">=</span> <span class="err">…</span><span
class="o">;</span>             <span class="c1">// CRS obtenu de n’importe
quelle façon.</span>
 <span class="n">crs</span> <span class="o">=</span> <span class="n">AbstractCRS</span><span
class="o">.</span><span class="na">castOrCopy</span><span class="o">(</span><span
class="n">crs</span><span class="o">).</span><span class="na">forConvention</span><span
class="o">(</span><span class="n">AxesConvention</span><span class="o">.</span><span
class="na">RIGHT_HANDED</span><span class="o">)</span>
@@ -234,7 +233,7 @@ où <em>zone</em> est un nombre de 1 �
 </ul>
 <p>Notez que la liste ci-dessus est incomplète. Voir la base EPSG pour d’avantages
de définitions UTM
 (WGS 72BE, SIRGAS 2000, SIRGAS 1995, SAD 69, ETRS 89, <em>etc.</em>, la plupart
définissent quelques zones).
-Une fois que le code EPSG de la projection UTM est déterminé, le CRS peut être obtenu
comme dans l’exemple ci-dessous:</p>
+Une fois que le code EPSG de la projection UTM est déterminé, le <abbr title="Coordinate
Reference System">CRS</abbr> peut être obtenu comme dans l’exemple ci-dessous:</p>
 <div class="codehilite"><pre><span class="kt">int</span> <span
class="n">code</span> <span class="o">=</span> <span class="mi">32600</span>
<span class="o">+</span> <span class="n">zone</span><span class="o">;</span>
   <span class="c1">// Pour l’hémisphère nord WGS84</span>
 <span class="n">CoordinateReferenceSystem</span> <span class="n">crs</span>
<span class="o">=</span> <span class="n">CRS</span><span class="o">.</span><span
class="na">forCode</span><span class="o">(</span><span class="s">&quot;EPSG:&quot;</span>
<span class="o">+</span> <span class="n">code</span><span class="o">);</span>
 </pre></div>
@@ -253,27 +252,27 @@ Ces formules de projections peuvent ê
 <p>Il est possible d’utiliser une formule sphérique avec une projection qui
n’a pas de contrepartie sphérique
 en déclarant explicitement les paramètres <code>"semi_major"</code> et
<code>"semi_minor"</code> dans la définition WKT.
 Ces paramètres sont généralement déduit du référentiel, mais Apache SIS
autorise les déclarations à surcharger ces valeurs.</p>
-<h3 id="projectionKind">Comment puis-je identifier le type de projection d’un
CRS ?<a class="headerlink" href="#projectionKind" title="Permanent link">&para;</a></h3>
-<p>Le terme « type de projection » (Mercator, Lambert Conformal, <em>etc.</em>)
est appelé <em>Operation Method</em> dans la terminologie ISO 19111.
-Une approche possible est de vérifier la valeur de <code>OperationMethod.getName()</code>
et de comparer avec les noms OGC et EPSG
+<h3 id="projectionKind">Comment puis-je identifier le type de projection d’un
<abbr title="Coordinate Reference System">CRS</abbr> ?<a class="headerlink"
href="#projectionKind" title="Permanent link">&para;</a></h3>
+<p>Le terme « type de projection » (Mercator, Lambert Conformal, <em>etc.</em>)
est appelé <em>Operation Method</em> dans la terminologie <abbr title="International
Organization for Standardization">ISO</abbr> 19111.
+Une approche possible est de vérifier la valeur de <code>OperationMethod.getName()</code>
et de comparer avec les noms <abbr title="Open Geospatial Consortium">OGC</abbr>
et EPSG
 listés à la page <a href="tables/CoordinateOperationMethods.html">Coordinate
Operation Methods</a>.</p>
-<h3 id="lookupEPSG">Comment obtenir le code EPSG d’un CRS existant ?<a
class="headerlink" href="#lookupEPSG" title="Permanent link">&para;</a></h3>
-<p>La propriété <em>identifiant</em> d’un CRS peut être obtenue
par la méthode <code>getIdentifiers()</code>
+<h3 id="lookupEPSG">Comment obtenir le code EPSG d’un <abbr title="Coordinate
Reference System">CRS</abbr> existant ?<a class="headerlink" href="#lookupEPSG"
title="Permanent link">&para;</a></h3>
+<p>La propriété <em>identifiant</em> d’un <abbr title="Coordinate
Reference System">CRS</abbr> peut être obtenue par la méthode <code>getIdentifiers()</code>
 qui retourne une collection de zéro ou un élément.
-Si le CRS a été créé à partir d’un <em>Well Known Text</em>
(WKT)
+Si le <abbr title="Coordinate Reference System">CRS</abbr> a été créé
à partir d’un <em>Well Known Text</em> (WKT)
 et que le WKT se termine avec un élément <code>AUTHORITY["EPSG", "xxxx"]</code>
(WKT version 1) ou <code>ID["EPSG", xxxx]</code> (WKT version 2,
 alors l’identifiant (un code numérique EPSG dans cet exemple) sera le <em>xxxx</em>
de cet élément.
-Si le CRS a été créé à partir de la base EPSG (par exemple avec l’appelle
à <code>CRS.forCode("EPSG:xxxx")</code>),
+Si le <abbr title="Coordinate Reference System">CRS</abbr> a été créé
à partir de la base EPSG (par exemple avec l’appelle à <code>CRS.forCode("EPSG:xxxx")</code>),
 alors l’identifiant est le code <em>xxxx</em> donné à la méthode.
-Si le CRS a été créé d’une autre façon, alors la collection retournée
par la méthode <code>getIdentifiers()</code>
-pourra être vide dans le cas où le programme qui a créé le CRS a aussi pris la
responsabilité de fournir les identifiants.</p>
+Si le <abbr title="Coordinate Reference System">CRS</abbr> a été créé
d’une autre façon, alors la collection retournée par la méthode <code>getIdentifiers()</code>
+pourra être vide dans le cas où le programme qui a créé le <abbr title="Coordinate
Reference System">CRS</abbr> a aussi pris la responsabilité de fournir les identifiants.</p>
 <p>Si la collection d’identifiants est vide, la méthode la plus efficace de
le corriger est de s’assurer que le WKT
-contient un élément <code>AUTHORITY</code> ou <code>ID</code>
(en supposant que le CRS vient d’un WKT).
+contient un élément <code>AUTHORITY</code> ou <code>ID</code>
(en supposant que le <abbr title="Coordinate Reference System">CRS</abbr> vient
d’un WKT).
 Si ce n’est pas possible, alors la classe <code>org.​apache.​sis.​referencing.​IdentifiedObjects</code>
contient des méthodes utilitaires qui peuvent aider
-Dans l’exemple suivant, l’appel à <code>lookupEPSG(…)</code>
va parcourir la base EPSG pour un CRS équivalent (en ignorant les métadonnées).
+Dans l’exemple suivant, l’appel à <code>lookupEPSG(…)</code>
va parcourir la base EPSG pour un <abbr title="Coordinate Reference System">CRS</abbr>
équivalent (en ignorant les métadonnées).
 <em>Attention, cette recherche est sensible à l’ordre des axes.</em>
-La plupart des CRS géographiques de la base EPSG sont déclarés avec l’ordre
des axes (<em>latitude</em>, <em>longitude</em>).
-En conséquence, si le CRS possède un ordre des axes (<em>longitude</em>,
<em>latitude</em>), la recherche a toutes les chances de ne pas trouver de résultats.</p>
+La plupart des <abbr title="Coordinate Reference System">CRS</abbr> géographiques
de la base EPSG sont déclarés avec l’ordre des axes (<em>latitude</em>,
<em>longitude</em>).
+En conséquence, si le <abbr title="Coordinate Reference System">CRS</abbr>
possède un ordre des axes (<em>longitude</em>, <em>latitude</em>),
la recherche a toutes les chances de ne pas trouver de résultats.</p>
 <div class="codehilite"><pre><span class="n">CoordinateReferenceSystem</span>
<span class="n">myCRS</span> <span class="o">=</span> <span class="err">…</span><span
class="o">;</span>
 <span class="n">Integer</span> <span class="n">identifier</span>
<span class="o">=</span> <span class="n">IdentifiedObjects</span><span
class="o">.</span><span class="na">lookupEPSG</span><span class="o">(</span><span
class="n">myCRS</span><span class="o">);</span>
 <span class="k">if</span> <span class="o">(</span><span class="n">identifier</span>
<span class="o">!=</span> <span class="kc">null</span><span class="o">)</span>
<span class="o">{</span>
@@ -282,11 +281,11 @@ En conséquence, si le CRS possède
 </pre></div>
 
 
-<h3 id="lookupURN">Comment obtenir l’URN « urn:ogc:def:crs:… »
d’un CRS existant ?<a class="headerlink" href="#lookupURN" title="Permanent link">&para;</a></h3>
-<p>L’OGC définit les URN pour les identifiants de CRS, par exemple <code>"urn:​ogc:​def:​crs:​epsg:​7.1:​4326"</code>
+<h3 id="lookupURN">Comment obtenir l’URN « urn:ogc:def:crs:… »
d’un <abbr title="Coordinate Reference System">CRS</abbr> existant ?<a
class="headerlink" href="#lookupURN" title="Permanent link">&para;</a></h3>
+<p>L’<abbr title="Open Geospatial Consortium">OGC</abbr> définit
les URN pour les identifiants de <abbr title="Coordinate Reference System">CRS</abbr>,
par exemple <code>"urn:​ogc:​def:​crs:​epsg:​7.1:​4326"</code>
 avec <code>"7.1"</code> comme version de la base EPSG utilisée.
 Les URN peuvent ou non être présentes dans la collection d’identifiants retournée
par <code>crs.getIdentifiers()</code>.
-Dans beaucoup de cas (principalement quand le CRS provient d’un <em>Well Known
Text</em>), seul des identifiants simples comme <code>"EPSG:​4326"</code>
sont présents.
+Dans beaucoup de cas (principalement quand le <abbr title="Coordinate Reference System">CRS</abbr>
provient d’un <em>Well Known Text</em>), seul des identifiants simples comme
<code>"EPSG:​4326"</code> sont présents.
 Une façon simple de construire une URN complète est d’utiliser le code ci-dessous.
 Cet exemple peut avoir à parcourir la base EPSG afin de trouver les informations qui n’apparaissent
pas explicitement dans <code>myCRS</code>.</p>
 <div class="codehilite"><pre><span class="n">CoordinateReferenceSystem</span>
<span class="n">myCRS</span> <span class="o">=</span> <span class="err">…</span><span
class="o">;</span>
@@ -294,22 +293,22 @@ Cet exemple peut avoir à parcourir la
 </pre></div>
 
 
-<h3 id="lookupReliability">Puis-je m’appuyer sur IdentifiedObjects.lookupEPSG(…)
comme inverse de CRS.forCode(…) ?<a class="headerlink" href="#lookupReliability"
title="Permanent link">&para;</a></h3>
-<p>Pour les CRS créés avec la base EPSG, en général oui.
-À noter toutefois que <code>IdentifiedObjects.getIdentifier(…)</code>
est moins riche et insensible aux détails de la définition du CRS
-car il n’interroge pas la base de données EPSG. Il marche uniquement si le CRS déclare
explicitement son code
-ce qui est le cas des CRS créés à partir de la base EPSG ou lus à partir d’un
<em>Well Known Text</em> (WKT) avec un élément <code>AUTHORITY</code>
ou <code>ID</code>.
-La méthode <code>lookupEPSG(…)</code> à l’inverse est plus robuste
contre les erreurs de déclaration de code car elle compare toujours le CRS avec celui de
la base.
+<h3 id="lookupReliability">Puis-je m’appuyer sur IdentifiedObjects.lookupEPSG(…)
comme inverse de <abbr title="Coordinate Reference System">CRS</abbr>.forCode(…) ?<a
class="headerlink" href="#lookupReliability" title="Permanent link">&para;</a></h3>
+<p>Pour les <abbr title="Coordinate Reference System">CRS</abbr> créés
avec la base EPSG, en général oui.
+À noter toutefois que <code>IdentifiedObjects.getIdentifier(…)</code>
est moins riche et insensible aux détails de la définition du <abbr title="Coordinate
Reference System">CRS</abbr>
+car il n’interroge pas la base de données EPSG. Il marche uniquement si le <abbr
title="Coordinate Reference System">CRS</abbr> déclare explicitement son code
+ce qui est le cas des <abbr title="Coordinate Reference System">CRS</abbr> créés
à partir de la base EPSG ou lus à partir d’un <em>Well Known Text</em>
(WKT) avec un élément <code>AUTHORITY</code> ou <code>ID</code>.
+La méthode <code>lookupEPSG(…)</code> à l’inverse est plus robuste
contre les erreurs de déclaration de code car elle compare toujours le <abbr title="Coordinate
Reference System">CRS</abbr> avec celui de la base.
 Elle peut échouer s’il y a une légère différence (par exemple d’arrondie
dans les paramètres)
-entre le CRS fourni et le CRS trouvé dans la base de données.</p>
-<h3 id="equalsIgnoreMetadata">Comment déterminer si deux CRS sont « fonctionnellement »
égaux ?<a class="headerlink" href="#equalsIgnoreMetadata" title="Permanent link">&para;</a></h3>
-<p>Deux CRS peuvent ne pas être considérés égaux s’ils sont associés
à des métadonnées différentes
-(nom, identifiant, domaine d’usage, domaine de validité, remarque), même s’ils
représentent mathématiquement le même CRS.
-Afin de tester si deux CRS sont fonctionnellement équivalents, utilisez la méthode
<code>Utilities​.equalsIgnoreMetadata(myFirstCRS, mySecondCRS)</code>.</p>
-<h3 id="crsHashCode">Est-ce que les CRS sont utilisables comme clé dans un HashMap ?<a
class="headerlink" href="#crsHashCode" title="Permanent link">&para;</a></h3>
+entre le <abbr title="Coordinate Reference System">CRS</abbr> fourni et le <abbr
title="Coordinate Reference System">CRS</abbr> trouvé dans la base de données.</p>
+<h3 id="equalsIgnoreMetadata">Comment déterminer si deux <abbr title="Coordinate
Reference System">CRS</abbr> sont « fonctionnellement » égaux ?<a
class="headerlink" href="#equalsIgnoreMetadata" title="Permanent link">&para;</a></h3>
+<p>Deux <abbr title="Coordinate Reference System">CRS</abbr> peuvent ne
pas être considérés égaux s’ils sont associés à des métadonnées
différentes
+(nom, identifiant, domaine d’usage, domaine de validité, remarque), même s’ils
représentent mathématiquement le même <abbr title="Coordinate Reference System">CRS</abbr>.
+Afin de tester si deux <abbr title="Coordinate Reference System">CRS</abbr> sont
fonctionnellement équivalents, utilisez la méthode <code>Utilities​.equalsIgnoreMetadata(myFirstCRS,
mySecondCRS)</code>.</p>
+<h3 id="crsHashCode">Est-ce que les <abbr title="Coordinate Reference System">CRS</abbr>
sont utilisables comme clé dans un HashMap ?<a class="headerlink" href="#crsHashCode"
title="Permanent link">&para;</a></h3>
 <p>Oui, toutes les classes définies dans les paquets <code>org.apache.sis.referencing.crs</code>,
<code>cs</code> et <code>datum</code>
 définissent leurs propres méthodes <code>equals(Object)</code> et <code>hashCode()</code>.
-La bibliothèque Apache SIS utilise elle-même les objets CRS dans des <code>Map</code>
à des fins de cache.</p>
+La bibliothèque Apache SIS utilise elle-même les objets <abbr title="Coordinate
Reference System">CRS</abbr> dans des <code>Map</code> à des fins
de cache.</p>
 <h2 id="transforms">Transformation de coordonnées<a class="headerlink" href="#transforms"
title="Permanent link">&para;</a></h2>
 <h3 id="axisOrderInTransforms">Mes coordonnées transformées sont totalement fausses !<a
class="headerlink" href="#axisOrderInTransforms" title="Permanent link">&para;</a></h3>
 <p>Ce cas se produit principalement à cause des ordonnées données dans le
mauvais ordre.
@@ -317,14 +316,14 @@ Les développeurs ont tendance à pr
 mais les géographes et pilotes utilisent l’ordre (<em>latitude</em>,
<em>longitude</em>) depuis des siècles
 et la base de données EPSG définit les systèmes de coordonnées de cette façon.
 Si une transformation de coordonnées semble produire des valeurs complètement fausses,
-la première chose à faire est d’afficher les CRS source et cible :</p>
+la première chose à faire est d’afficher les <abbr title="Coordinate Reference
System">CRS</abbr> source et cible :</p>
 <div class="codehilite"><pre><span class="n">System</span><span
class="o">.</span><span class="na">out</span><span class="o">.</span><span
class="na">println</span><span class="o">(</span><span class="n">sourceCRS</span><span
class="o">);</span>
 <span class="n">System</span><span class="o">.</span><span class="na">out</span><span
class="o">.</span><span class="na">println</span><span class="o">(</span><span
class="n">targetCRS</span><span class="o">);</span>
 </pre></div>
 
 
 <p>Une attention particulière doit être portée à l’ordre des éléments
<code>AXIS</code>.
-Dans l’exemple ci-dessous, le CRS stipule clairement l’ordre (<em>latitude</em>,
<em>longitude</em>) :</p>
+Dans l’exemple ci-dessous, le <abbr title="Coordinate Reference System">CRS</abbr>
stipule clairement l’ordre (<em>latitude</em>, <em>longitude</em>) :</p>
 <div class="codehilite"><pre>GeodeticCRS[&quot;WGS 84&quot;,
   Datum[&quot;World Geodetic System 1984&quot;,
     Ellipsoid[&quot;WGS 84&quot;, 6378137.0, 298.257223563]],
@@ -347,7 +346,7 @@ ESRI définit aussi une projection <em
 <p>La spécification <em>Well Known Text</em> (WKT) a été interprétée
de différentes façons en fonction des implémentations logicielles.
 Un problème subtil vient des unités d’angles pour le méridien d’origine
et les paramètres de projection.
 La spécification WKT 1 stipule clairement : <em>« Si l’élément
<code>PRIMEM</code> apparaît dans <code>GEOGCS</code>,
-alors l’unité des longitudes doit correspondre à celle du système de coordonnées
géographiques »</em> (traduction libre de OGC 01-009).
+alors l’unité des longitudes doit correspondre à celle du système de coordonnées
géographiques »</em> (traduction libre de <abbr title="Open Geospatial Consortium">OGC</abbr>
01-009).
 Toutefois ESRI et GDAL entres autres utilisent inconditionnellement des degrés décimaux,
ignorant cette partie de la spécification WKT.
 Ce problème peut être identifié en inspectant l’extrait de WKT suivant :</p>
 <div class="codehilite"><pre>PROJCS[&quot;Lambert II étendu&quot;,
@@ -374,35 +373,35 @@ Afin d’obtenir le résultat atten
     avec l’énumération <code>Convention.​WKT1_COMMON_UNITS</code>
pour la valeur de <code>WKTFormat</code> dans le paquet <code>org.​apache.​sis.​io.​wkt</code>.</p>
 </li>
 </ul>
-<p>Il est à noter que le standard GeoPackage requiert explicitement la conformité
avec OGC 01-009
-et que le nouveau standard WKT 2 suit aussi l’interprétation de OGC 01-009.
+<p>Il est à noter que le standard GeoPackage requiert explicitement la conformité
avec <abbr title="Open Geospatial Consortium">OGC</abbr> 01-009
+et que le nouveau standard WKT 2 suit aussi l’interprétation de <abbr title="Open
Geospatial Consortium">OGC</abbr> 01-009.
 Le comportement par défaut de Apache SIS est cohérent avec ces deux standards.</p>
 <h3 id="BursaWolf">J’ai vérifié tous ce qui est ci-dessus et j’ai toujours
une erreur d’environ un kilomètre.<a class="headerlink" href="#BursaWolf" title="Permanent
link">&para;</a></h3>
-<p>Les systèmes de coordonnées (CRS) font une approximation de la forme de la
terre avec une ellipsoïde.
+<p>Les systèmes de coordonnées (<abbr title="Coordinate Reference System">CRS</abbr>)
font une approximation de la forme de la terre avec une ellipsoïde.
 Différentes ellipsoïdes (en réalité différents <em>référentiels</em>)
sont utilisées dans différents pays du monde et à différents moments de l’histoire.
-Quand on transforme des coordonnées entre deux CRS utilisant le même référentiel,
aucun paramètre Bursa-Wolf n’est requis.
+Quand on transforme des coordonnées entre deux <abbr title="Coordinate Reference System">CRS</abbr>
utilisant le même référentiel, aucun paramètre Bursa-Wolf n’est requis.
 Mais quand la transformation implique un changement de référentiel, le module de géoréférencement
à besoin d’informations sur la manière d’effectuer ce changement.</p>
 <p>Il y a plusieurs façon de spécifier comment appliquer un changement de référentiel,
et la plupart sont seulement approximatives.
 La méthode de Bursa-Wolf est l’une d’elle, mais pas la seule. Toutefois elle
est une des plus fréquemment utilisées.
 Les paramètres Bursa-Wolf peuvent être spécifiés à l’intérieur de
l’élément <code>TOWGS84</code> de la version 1 du format <em>Well
Known Text</em> (WKT),
 ou dans l’élément <code>BOUNDCRS</code> avec la version 2 du format
WKT.
-Si le CRS est lu à partir d’une chaine WKT, assurez-vous qu’elle contient l’élément
approprié.</p>
+Si le <abbr title="Coordinate Reference System">CRS</abbr> est lu à partir
d’une chaine WKT, assurez-vous qu’elle contient l’élément approprié.</p>
 <h3 id="slightDifferences">J’obtiens des résultats légèrement différents
d’un environnement d’exécution à l’autre.<a class="headerlink" href="#slightDifferences"
title="Permanent link">&para;</a></h3>
 <p>Les résultats de transformations de coordonnées quand on lance l’application
dans un conteneur web (type JBoss, <em>etc.</em>)
 peuvent avoir quelques mètres de différence avec la transformation exécutée dans
un IDE (NetBeans, Eclipse, <em>etc.</em>).
 Les résultats dépendent de la présence de la fabrique EPSG dans le chemin de classes
(classpath),
-<strong>peu importe comment le CRS a été créé</strong>, parce-que
la fabrique EPSG spécifie explicitement l’opération à appliquer pour certaines
paires de CRS.
+<strong>peu importe comment le <abbr title="Coordinate Reference System">CRS</abbr>
a été créé</strong>, parce-que la fabrique EPSG spécifie explicitement
l’opération à appliquer pour certaines paires de <abbr title="Coordinate Reference
System">CRS</abbr>.
 Dans ces cas, l’opération spécifiée par EPSG a priorité par rapport aux
paramètres de Bursa-Wolf
 (l’element <code>TOWGS84</code> de la version 1 du format <em>Well
Known Text</em>).</p>
 <p>Une connexion à la base EPSG peut avoir été établie dans un environnement
(typiquement celui JEE)
-et pas dans l’autre (typiquement un IDE) car uniquement le premier à un pilote JDBC.
+et pas dans l’autre (typiquement un IDE) car uniquement le premier à un pilote <abbr
title="Java DataBase Connectivity">JDBC</abbr>.
 La méthode recommandée pour uniformiser les résultats est d’ajouter dans le
second environnement (l’IDE)
 le même pilote que celui présent dans le premier environnement (JEE).
 Cela devrait être un des suivant : JavaDB (aussi nommé Derby), HSQL ou PostgreSQL.
 Assurez vous également que les <a href="epsg.html">paramètres de connexion à
la base EPSG</a> sont les mêmes.</p>
-<h3 id="toWGS84">Puis-je présumer qu’il est toujours possible de transformer
un CRS arbitraire vers WGS84 ?<a class="headerlink" href="#toWGS84" title="Permanent
link">&para;</a></h3>
-<p>Pour les CRS 2D horizontaux créés avec la base de données EPSG, l’appel
à <code>CRS.findOperation(…)</code> devrait toujours marcher.
-Pour les CRS 3D ayant n’importe quel axe de hauteur autre que la hauteur ellipsoïdale,
ou pour les CRS 2D de type <code>EngineeringCRS</code>, la méthode peu échouer.
+<h3 id="toWGS84">Puis-je présumer qu’il est toujours possible de transformer
un <abbr title="Coordinate Reference System">CRS</abbr> arbitraire vers WGS84 ?<a
class="headerlink" href="#toWGS84" title="Permanent link">&para;</a></h3>
+<p>Pour les <abbr title="Coordinate Reference System">CRS</abbr> 2D horizontaux
créés avec la base de données EPSG, l’appel à <code>CRS.findOperation(…)</code>
devrait toujours marcher.
+Pour les <abbr title="Coordinate Reference System">CRS</abbr> 3D ayant n’importe
quel axe de hauteur autre que la hauteur ellipsoïdale, ou pour les <abbr title="Coordinate
Reference System">CRS</abbr> 2D de type <code>EngineeringCRS</code>,
la méthode peu échouer.
 Il reste à noter que dans le cas ou la méthode <code>CRS.findOperation(…)</code>
ne lève pas d’erreur, l’appel à <code>MathTransform.transform(…)</code>
peut
 produire des valeurs <code>NaN</code> or <code>Infinity</code>si
la coordonnée transformée est éloignée de la zone de validité.</p>
 <h1 id="metadata">Métadonnées<a class="headerlink" href="#metadata" title="Permanent
link">&para;</a></h1>
@@ -410,9 +409,9 @@ produire des valeurs <code>NaN</code> or
 <h3 id="metadata-proxy">Mes metadonnées sont stockées dans une forme de base
de données. Implémenter toute les interfaces de GeoAPI est infaisable.<a class="headerlink"
href="#metadata-proxy" title="Permanent link">&para;</a></h3>
 <p>Les développeurs n’ont pas besoin d’implémenter directement les
interfaces de metadonnées.
 Si le système de stockage sous-jacent peut accéder aux metadonnées à partir de
leur classes et nom de propriétés
-(soit le nom java ou le nom ISO/OGC), alors il est possible d’implémenter un seul
moteur pour tous les types de metadonnées
+(soit le nom java ou le nom <abbr title="International Organization for Standardization">ISO</abbr>/<abbr
title="Open Geospatial Consortium">OGC</abbr>), alors il est possible d’implémenter
un seul moteur pour tous les types de metadonnées
 et de laisser la Machine Virtuelle Java implémenter les interfaces GeoAPI à la volée,
en utilisant la classe <code>java.lang.reflect.Proxy</code>.
-Pour plus de détails voir la javadoc de la classe <code>Proxy</code>, en gardant
à l’esprit que le nom ISO/OGC d’une <code>java.lang.Class</code>
ou
+Pour plus de détails voir la javadoc de la classe <code>Proxy</code>, en gardant
à l’esprit que le nom <abbr title="International Organization for Standardization">ISO</abbr>/<abbr
title="Open Geospatial Consortium">OGC</abbr> d’une <code>java.lang.Class</code>
ou
 <code>java.lang.reflect.Method</code> peut être obtenu comme suit :</p>
 <div class="codehilite"><pre><span class="n">UML</span> <span
class="n">uml</span> <span class="o">=</span> <span class="n">method</span><span
class="o">.</span><span class="na">getAnnotation</span><span class="o">(</span><span
class="n">UML</span><span class="o">.</span><span class="na">class</span><span
class="o">);</span>
 <span class="k">if</span> <span class="o">(</span><span class="n">uml</span>
<span class="o">!=</span> <span class="kc">null</span><span class="o">)</span>
<span class="o">{</span>
@@ -436,14 +435,6 @@ fournies dans le paquet <code>org.apache
 Toutes les implémentations du SDK fournissent des constructeurs de copies peu profondes
pour rendre cela plus simple.
 Il est uniquement nécéssaire de décorer la classes racine, pas les attributs.
 Les valeurs des attributs seront décorées automatiquement au besoin par les adaptateurs
JAXB.</p>
-<h1 id="abreviations-utilisees-dans-ce-faq">Abréviations utilisées dans ce FAQ<a
class="headerlink" href="#abreviations-utilisees-dans-ce-faq" title="Permanent link">&para;</a></h1>
-<ul>
-<li>[CRS]:  Coordinate Reference System</li>
-<li>[ISO]:  International Organization for Standardization</li>
-<li>[JDBC]: Java DataBase Connectivity</li>
-<li>[OGC]:  Open Geospatial Consortium</li>
-<li>[UTC]:  Universal Time Coordinated</li>
-</ul>
             </article>
           </section>
         </div><!--/span-->



Mime
View raw message