sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1796896 - in /sis/site/trunk/content: faq.mdtext faq_fr.mdtext fr/
Date Tue, 30 May 2017 17:15:10 GMT
Author: desruisseaux
Date: Tue May 30 17:15:10 2017
New Revision: 1796896

URL: http://svn.apache.org/viewvc?rev=1796896&view=rev
Log:
Minor formatting and edition in FAQ_fr (e.g. quote characters).
Add link in FAQ.

Removed:
    sis/site/trunk/content/fr/
Modified:
    sis/site/trunk/content/faq.mdtext
    sis/site/trunk/content/faq_fr.mdtext   (contents, props changed)

Modified: sis/site/trunk/content/faq.mdtext
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/faq.mdtext?rev=1796896&r1=1796895&r2=1796896&view=diff
==============================================================================
--- sis/site/trunk/content/faq.mdtext (original)
+++ sis/site/trunk/content/faq.mdtext Tue May 30 17:15:10 2017
@@ -18,6 +18,7 @@ Notice: Licensed to the Apache Software
 
 
 This page lists some Frequently Asked Questions (FAQ) when using Apache SIS.
+This FAQ is also [available in French](FAQ_fr.html).
 
 [TOC]
 

Modified: sis/site/trunk/content/faq_fr.mdtext
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/faq_fr.mdtext?rev=1796896&r1=1796895&r2=1796896&view=diff
==============================================================================
--- sis/site/trunk/content/faq_fr.mdtext [iso-8859-1] (original)
+++ sis/site/trunk/content/faq_fr.mdtext [UTF-8] Tue May 30 17:15:10 2017
@@ -1,20 +1,41 @@
-[TOC]
+Title:  Questions fréquentes (FAQ)
+Notice: Licensed to the Apache Software Foundation (ASF) under one
+        or more contributor license agreements.  See the NOTICE file
+        distributed with this work for additional information
+        regarding copyright ownership.  The ASF licenses this file
+        to you under the Apache License, Version 2.0 (the
+        "License"); you may not use this file except in compliance
+        with the License.  You may obtain a copy of the License at
+        .
+          http://www.apache.org/licenses/LICENSE-2.0
+        .
+        Unless required by applicable law or agreed to in writing,
+        software distributed under the License is distributed on an
+        "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+        KIND, either express or implied.  See the License for the
+        specific language governing permissions and limitations
+        under the License.
 
 
-Géoréférencement    {#referencing}
-=============================
+Cette page liste quelques questions fréquemment posées à propos de Apache SIS.
+Son contenu est traduit de la [page de FAQ en anglais](faq.html).
 
-Pour bien commencer    {#referencing-intro}
----------------------------------------
+[TOC]
 
-### Comment transformer une coordonnée ?    {#transform-point}
 
-Le code java suivant projète une coordonnée de _World Geodetic System 1984_ (WGS84) vers _WGS 84 / UTM zone 33N_.
 
-Afin de rendre cet exemple un peu plus simple, le code utilise des constantes prédéfinies dans la classe `CommonCRS`
-mais les applications plus avancées utilisent habituellement des codes EPSG à la place.
+Géoréférencement    {#referencing}
+==================================
+
+Pour bien commencer    {#referencing-intro}
+-------------------------------------------
+
+### Comment transformer une coordonnée ?    {#transform-point}
 
-Note : les coordonnées ci-dessous sont en latitude puis longitude.
+Le code java suivant projète une coordonnée de _World Geodetic System 1984_ (WGS84) vers _WGS 84 / UTM zone 33N_.
+Afin de rendre cet exemple un peu plus simple, le code utilise des constantes prédéfinies dans la classe `CommonCRS`.
+Mais les applications plus avancées utilisent habituellement des codes EPSG à la place.
+Notez que les coordonnées ci-dessous sont en latitude puis longitude.
 
     :::java
     import org.opengis.geometry.DirectPosition;
@@ -29,14 +50,14 @@ Note : les coordonnées ci-dessou
     public class MyApp {
         public static void main(String[] args) throws FactoryException, TransformException {
             CoordinateReferenceSystem sourceCRS = CommonCRS.WGS84.geographic();
-            CoordinateReferenceSystem targetCRS = CommonCRS.WGS84.UTM(40, 14);  // Get whatever zone is valid for 14°E.
+            CoordinateReferenceSystem targetCRS = CommonCRS.WGS84.UTM(40, 14);      // Obtient la zone valide pour 14°E.
             CoordinateOperation operation = CRS.findOperation(sourceCRS, targetCRS, null);
 
-            // Les lignes ci-dessus sont coûteuses et ne devraient être appelées qu’une fois pour un ensemble de points.
-            // Dans cet exemple, l’opération que l’on obtient est valide pour la zone géographique allant
-            // de 12°E à 18°E (UTM zone 33) et de 0°N à 84°N.
+            // Les lignes ci-dessus sont coûteuses et ne devraient être appelées qu’une fois pour un ensemble de points.
+            // Dans cet exemple, l’opération que l’on obtient est valide pour la zone géographique allant
+            // de 12°E à 18°E (UTM zone 33) et de 0°N à 84°N.
 
-            DirectPosition ptSrc = new DirectPosition2D(40, 14);           // 40°N 14°E
+            DirectPosition ptSrc = new DirectPosition2D(40, 14);           // 40°N 14°E
             DirectPosition ptDst = operation.getMathTransform().transform(ptSrc, null);
 
             System.out.println("Source: " + ptSrc);
@@ -46,209 +67,207 @@ Note : les coordonnées ci-dessou
 
 
 
-### Quelles projections sont supportées ?    {#operation-methods}
+### Quelles projections sont supportées ?    {#operation-methods}
 
-Les formules supportées par Apache SIS (incluant les projections cartographiques, mais pas uniquement)
-sont listées sur la page [Coordinate Operation Methods](tables/CoordinateOperationMethods.html).
-La quantité de formules de projection est relativement faible,
-mais la quantité de _Systèmes de Coordonées projetés_ que l’on peut construire avec est considérable.
+Les formules supportées par Apache SIS (incluant les projections cartographiques, mais pas uniquement)
+sont listées sur la page [Coordinate Operation Methods](tables/CoordinateOperationMethods.html).
+La quantité de formules de projection est relativement faible,
+mais la quantité de _Systèmes de Coordonées projetés_ que l’on peut construire avec est considérable.
 Par exemple, avec seulement trois familles de formules (_Mercator Cylindrique_, _Mercator Transverse_ et _Lambert Conforme Conique_),
-utilisées avec différents paramètres, on peut couvrir des milliers de projections listées dans la base EPSG.
+utilisées avec différents paramètres, on peut couvrir des milliers de projections listées dans la base EPSG.
 
-Afin d’utiliser une formule de projection, il est nécessaire de connaître les paramètres de la projection.
-Par soucis de facilité d’utilisation, des milliers de projections avec des paramètres pré-définis ont un identifiant unique.
-Une source bien connue de ces définitions est la base de données EPSG, mais il existe d’autres autorités.
-Les systèmes de coordonnées prédéfinis dans Apache SIS sont listés à la page
+Afin d’utiliser une formule de projection, il est nécessaire de connaître les paramètres de la projection.
+Par soucis de facilité d’utilisation, des milliers de projections avec des paramètres pré-définis ont un identifiant unique.
+Une source bien connue de ces définitions est la base de données EPSG, mais il existe d’autres autorités.
+Les systèmes de coordonnées prédéfinis dans Apache SIS sont listés à la page
 [Coordinate Reference Systems](tables/CoordinateReferenceSystems.html).
 
 
 
-### Qu’est ce que le problème d’ordre des axes et comment est il abordé ?    {#axisOrder}
+### Qu’est ce que le problème d’ordre des axes et comment est il abordé ?    {#axisOrder}
 
-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 (_latitude_, _longitude_) 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 (_x_, _y_) 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 `GeographicCRS`,
-pour certains `ProjectedCRS` de l’hémisphère sud (Afrique de sud, Australie, _etc._) et pour certaines projections polaires entre autre.
-
-Pour chaque CRS identifié par un code EPSG, l’ordre officiel des axes peut être vérifié avec
-le registre EPSG à l’adresse [http://www.epsg-registry.org](http://www.epsg-registry.org)
-(à 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 _"Retrieve by code"_ et entrez le code numérique.
-Cliquez ensuite sur le lien _"View"_ de la partie droite
-et cliquez sur le symbole _"+"_ à gauche de _"Axes"_.
-
-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 (_x_, _y_), ignorant la définition de l’autorité.
-Parmi les standards OGC obsolètes qui utilisent un ordre des axes non-conforme,
-l’un des plus influent est la version 1 de la spécification _Well Known Text_ (WKT).
-Selon ce format très utilisé, les définitions WKT sans éléments `AXIS[…]`
-doivent par défaut être dans l’ordre (_longitude_, _latitude_) ou (_x_, _y_).
-Dans la version 2 du format WKT, les éléments `AXIS[…]` ne sont plus optionnels
-et doivent contenir explicitement le sous-élément `ORDER[…]` pour appuyer l’ordre des axes à appliquer.
-
-Beaucoup de logiciels utilisent toujours l’ancien ordre des axes (_x_, _y_), parfois parce qu’il est plus simple à implémenter.
-Mais Apache SIS suit l’ordre des axes _tel que défini par l’autorité_ (à 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.
-Ce changement se fait avec le code suivant :
+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 (_latitude_, _longitude_) 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 (_x_, _y_) 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 `GeographicCRS`,
+pour certains `ProjectedCRS` de l’hémisphère sud (Afrique de sud, Australie, _etc._) et pour certaines projections polaires entre autre.
+
+Pour chaque CRS identifié par un code EPSG, l’ordre officiel des axes peut être vérifié avec
+le registre EPSG à l’adresse [http://www.epsg-registry.org](http://www.epsg-registry.org)
+(à 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 _« Retrieve by code »_ et entrez le code numérique.
+Cliquez ensuite sur le lien _« View »_ de la partie droite
+et cliquez sur le symbole _« + »_ à gauche de _« Axes »_.
+
+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 (_x_, _y_), ignorant la définition de l’autorité.
+Parmi les standards OGC obsolètes qui utilisent un ordre des axes non-conforme,
+l’un des plus influent est la version 1 de la spécification _Well Known Text_ (WKT).
+Selon ce format très utilisé, les définitions WKT sans éléments `AXIS[…]`
+doivent par défaut être dans l’ordre (_longitude_, _latitude_) ou (_x_, _y_).
+Dans la version 2 du format WKT, les éléments `AXIS[…]` ne sont plus optionnels
+et doivent contenir explicitement le sous-élément `ORDER[…]` pour appuyer l’ordre des axes à appliquer.
+
+Beaucoup de logiciels utilisent toujours l’ancien ordre des axes (_x_, _y_), parfois parce qu’il est plus simple à implémenter.
+Mais Apache SIS suit l’ordre des axes _tel que défini par l’autorité_ (à 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.
+Ce changement se fait avec le code suivant :
 
     :::java
-    CoordinateReferenceSystem crs = …;             // CRS obtenu de n’importe quelle façon.
+    CoordinateReferenceSystem crs = …;             // CRS obtenu de n’importe quelle façon.
     crs = AbstractCRS.castOrCopy(crs).forConvention(AxesConvention.RIGHT_HANDED)
 
 
 
 
-Systèmes de Référence des Coordonnées    {#crs}
+Systèmes de Référence des Coordonnées    {#crs}
 -----------------------------------------------
 
-### Comment créer une projection de type Universal Transverse universelle de Mercator (UTM) ?    {#UTM}
+### Comment créer une projection de type Transverse Universelle de Mercator (UTM) ?    {#UTM}
 
-Si la zone UTM n’est pas connue, une façon simple est d’utiliser la méthode `universal(…)` sur l’une des constantes de `CommonCRS`.
-Cette méthode prend en argument une coordonnées géographique en (_latitude_, _longitude_) et en calcule la zone UTM correspondante.
+Si la zone UTM n’est pas connue, une façon simple est d’utiliser la méthode `universal(…)` sur l’une des constantes de `CommonCRS`.
+Cette méthode prend en argument une coordonnées géographique en (_latitude_, _longitude_) et en calcule la zone UTM correspondante.
 Voir [le code java ci-dessus](#transform-point).
 
-Si la zone UTM est connue, une solution est d’utiliser la fabrique des autorités "EPSG" ou "AUTO".
-Le code EPSG de certaines projections UTM peut être déterminé comme suit,
-où _zone_ est un nombre de 1 à 60 inclusif (sauf spécifié autrement) :
-
-  * WGS 84 (northern hemisphère nord): 32600 + _zone_
-  * WGS 84 (hemisphère sud): 32700 + _zone_
-  * WGS 72 (hemisphère nord): 32200 + _zone_
-  * WGS 72 (hemisphère sud): 32300 + _zone_
-  * NAD 83 (hemisphère nord): 26900 + _zone_ (zone de 1 à 23)
-  * NAD 27 (hemisphère nord): 26700 + _zone_ (zone de 1 à 22)
-
-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, _etc._, 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:
+Si la zone UTM est connue, une solution est d’utiliser la fabrique des autorités « EPSG » ou « AUTO ».
+Le code EPSG de certaines projections UTM peut être déterminé comme suit,
+où _zone_ est un nombre de 1 à 60 inclusif (sauf spécifié autrement) :
+
+  * WGS 84 (northern hemisphère nord): 32600 + _zone_
+  * WGS 84 (hemisphère sud): 32700 + _zone_
+  * WGS 72 (hemisphère nord): 32200 + _zone_
+  * WGS 72 (hemisphère sud): 32300 + _zone_
+  * NAD 83 (hemisphère nord): 26900 + _zone_ (zone de 1 à 23)
+  * NAD 27 (hemisphère nord): 26700 + _zone_ (zone de 1 à 22)
+
+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, _etc._, 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:
 
     :::java
-    int code = 32600 + zone;    // Pour l’hémisphère nord WGS84
+    int code = 32600 + zone;    // Pour l’hémisphère nord WGS84
     CoordinateReferenceSystem crs = CRS.forCode("EPSG:" + code);
 
 
 
-### Comment instancier une projection Google ?    {#google}
+### Comment instancier une projection Google ?    {#google}
 
-La projection Google est une projection de Mercator qui prétend utiliser un référentiel WGS84
-mais qui ignore la nature ellipsoïdale de ce référentiel et utilise un forme sphérique des formules à la place.
-Depuis la version 6.15 de la base EPSG, la façon privilégiée d’obtenir cette projection est d’utiliser la méthode `CRS.forCode("EPSG:3857")`.
-Il faut noter que l’usage de cette projection **n’est pas** recommandé, sauf pour des raisons de compatibilité.
+La projection Google est une projection de Mercator qui prétend utiliser un référentiel WGS84
+mais qui ignore la nature ellipsoïdale de ce référentiel et utilise un forme sphérique des formules à la place.
+Depuis la version 6.15 de la base EPSG, la façon privilégiée d’obtenir cette projection est d’utiliser la méthode `CRS.forCode("EPSG:3857")`.
+Il faut noter que l’usage de cette projection **n’est pas** recommandé, sauf pour des raisons de compatibilité.
 
-La définition de EPSG:3857 utilise une formule de projection nommée _"Popular Visualisation Pseudo Mercator"_.
-La base EPSG propose aussi d’autres projections qui utilisent des formules sphériques.
-Ces méthodes ont le mot "(Spherical)" dans leur nom, par exemple _"Mercator (Spherical)"_
-(qui diffère de _"Popular Visualisation Pseudo Mercator"_ par l’utilisation d’une sphère de rayon plus approprié).
-Ces formules de projections peuvent être utilisées dans les définitions Well Known Text (WKT).
+La définition de EPSG:3857 utilise une formule de projection nommée _« Popular Visualisation Pseudo Mercator »_.
+La base EPSG propose aussi d’autres projections qui utilisent des formules sphériques.
+Ces méthodes ont le mot « (Spherical) » dans leur nom, par exemple _« Mercator (Spherical) »_
+(qui diffère de _« Popular Visualisation Pseudo Mercator »_ par l’utilisation d’une sphère de rayon plus approprié).
+Ces formules de projections peuvent être utilisées dans les définitions _Well Known Text_ (WKT).
 
-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 `"semi_major"` et `"semi_minor"` 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.
+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 `"semi_major"` et `"semi_minor"` 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.
 
 
 
-### Comment puis-je identifier le type de projection d’un CRS ?    {#projectionKind}
+### Comment puis-je identifier le type de projection d’un CRS ?    {#projectionKind}
 
-Le terme "type de projection" (Mercator, Lambert Conformal, _etc._) est appelé _Operation Method_ dans la terminologie ISO 19111.
-Une approche possible est de vérifier la valeur de `OperationMethod.getName()` et de comparer avec les noms OGC et EPSG
-listés à la page [Coordinate Operation Methods](tables/CoordinateOperationMethods.html).
+Le terme « type de projection » (Mercator, Lambert Conformal, _etc._) est appelé _Operation Method_ dans la terminologie ISO 19111.
+Une approche possible est de vérifier la valeur de `OperationMethod.getName()` et de comparer avec les noms OGC et EPSG
+listés à la page [Coordinate Operation Methods](tables/CoordinateOperationMethods.html).
 
 
 
-### Comment obtenir le code EPSG d’un CRS existant ?    {#lookupEPSG}
+### Comment obtenir le code EPSG d’un CRS existant ?    {#lookupEPSG}
 
-La propriété _identifiant_ d’un CRS peut être obtenue par la méthode `getIdentifiers()`
-qui retourne une collection de zéro ou un élément.
-Si le CRS a été créé à partir d’un _Well Known Text_ (WKT)
-et que le WKT se termine avec un élément `AUTHORITY["EPSG", "xxxx"]` (WKT version 1) ou `ID["EPSG", xxxx]` (WKT version 2,
-alors l’identifiant (un code numérique EPSG dans cet exemple) sera le _xxxx_ de cet élément.
-Si le CRS a été créé à partir de la base EPSG (par exemple avec l’appelle à `CRS.forCode("EPSG:xxxx")`),
-alors l’identifiant est le code _xxxx_ donné à la méthode.
-Si le CRS a été créé d’une autre façon, alors la collection retournée par la méthode `getIdentifiers()`
-pourra être vide dans le cas où le programme qui a créé le CRS a aussi pris la responsabilité de fournir les identifiants.
+La propriété _identifiant_ d’un CRS peut être obtenue par la méthode `getIdentifiers()`
+qui retourne une collection de zéro ou un élément.
+Si le CRS a été créé à partir d’un _Well Known Text_ (WKT)
+et que le WKT se termine avec un élément `AUTHORITY["EPSG", "xxxx"]` (WKT version 1) ou `ID["EPSG", xxxx]` (WKT version 2,
+alors l’identifiant (un code numérique EPSG dans cet exemple) sera le _xxxx_ de cet élément.
+Si le CRS a été créé à partir de la base EPSG (par exemple avec l’appelle à `CRS.forCode("EPSG:xxxx")`),
+alors l’identifiant est le code _xxxx_ donné à la méthode.
+Si le CRS a été créé d’une autre façon, alors la collection retournée par la méthode `getIdentifiers()`
+pourra être vide dans le cas où le programme qui a créé le CRS a aussi pris la responsabilité de fournir les identifiants.
 
-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 `AUTHORITY` ou `ID` (en supposant que le CRS vient d’un WKT).
-Si ce n’est pas possible, alors la classe `org.​apache.​sis.​referencing.​IdentifiedObjects` contient des méthodes utilitaires qui peuvent aider
-Dans l’exemple suivant, l’appel à `lookupEPSG(…)` va parcourir la base EPSG pour un CRS équivalent (en ignorant les métadonnées).
-*Attention, cette recherche est sensible à l’ordre des axes.*
-La plupart des CRS géographiques de la base EPSG sont déclarés avec l’ordre des axes (_latitude_, _longitude_).
-En conséquence, si le CRS possède un ordre des axes (_longitude_, _latitude_), la recherche a toutes les chances de ne pas trouver de résultats.
+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 `AUTHORITY` ou `ID` (en supposant que le CRS vient d’un WKT).
+Si ce n’est pas possible, alors la classe `org.​apache.​sis.​referencing.​IdentifiedObjects` contient des méthodes utilitaires qui peuvent aider
+Dans l’exemple suivant, l’appel à `lookupEPSG(…)` va parcourir la base EPSG pour un CRS équivalent (en ignorant les métadonnées).
+*Attention, cette recherche est sensible à l’ordre des axes.*
+La plupart des CRS géographiques de la base EPSG sont déclarés avec l’ordre des axes (_latitude_, _longitude_).
+En conséquence, si le CRS possède un ordre des axes (_longitude_, _latitude_), la recherche a toutes les chances de ne pas trouver de résultats.
 
     :::java
-    CoordinateReferenceSystem myCRS = …;
+    CoordinateReferenceSystem myCRS = …;
     Integer identifier = IdentifiedObjects.lookupEPSG(myCRS);
     if (identifier != null) {
-        System.out.println("The EPSG code has been found: " + identifier);
+        System.out.println("Le code EPSG a été trouvé : " + identifier);
     }
 
 
 
-### Comment obtenir l’URN "urn:ogc:def:crs:…" d’un CRS existant ?    {#lookupURN}
+### Comment obtenir l’URN « urn:ogc:def:crs:… » d’un CRS existant ?    {#lookupURN}
 
-L’OGC définit les URN pour les identifiants de CRS, par exemple `"urn:​ogc:​def:​crs:​epsg:​7.1:​4326"`
-avec `"7.1"` comme version de la base EPSG utilisée.
-Les URN peuvent ou non être présentes dans la collection d’identifiants retournée par `crs.getIdentifiers()`.
-Dans beaucoup de cas (principalement quand le CRS provient d’un Well Known Text), seul des identifiants simples comme `"EPSG:​4326"` 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 `myCRS`.
+L’OGC définit les URN pour les identifiants de CRS, par exemple `"urn:​ogc:​def:​crs:​epsg:​7.1:​4326"`
+avec `"7.1"` comme version de la base EPSG utilisée.
+Les URN peuvent ou non être présentes dans la collection d’identifiants retournée par `crs.getIdentifiers()`.
+Dans beaucoup de cas (principalement quand le CRS provient d’un _Well Known Text_), seul des identifiants simples comme `"EPSG:​4326"` 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 `myCRS`.
 
     :::java
-    CoordinateReferenceSystem myCRS = …;
+    CoordinateReferenceSystem myCRS = …;
     String urn = IdentifiedObjects.lookupURN(myCRS);
 
 
 
-### Puis-je m’appuyer sur IdentifiedObjects.lookupEPSG(…) comme inverse de CRS.forCode(…) ?   {#lookupReliability}
-
-Pour les CRS créés avec la base EPSG, en général oui.
-À noter toutefois que `IdentifiedObjects.getIdentifier(…)` 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 _Well Known Text_ (WKT) avec un élément `AUTHORITY` ou `ID`.
-La méthode `lookupEPSG(…)` à l’inverse est plus robuste contre les erreurs de déclaration de code car elle compare toujours le CRS 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.
+### Puis-je m’appuyer sur IdentifiedObjects.lookupEPSG(…) comme inverse de CRS.forCode(…) ?   {#lookupReliability}
 
+Pour les CRS créés avec la base EPSG, en général oui.
+À noter toutefois que `IdentifiedObjects.getIdentifier(…)` 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 _Well Known Text_ (WKT) avec un élément `AUTHORITY` ou `ID`.
+La méthode `lookupEPSG(…)` à l’inverse est plus robuste contre les erreurs de déclaration de code car elle compare toujours le CRS 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.
 
-### Comment déterminer si deux CRS sont "fonctionnellement" égaux ?  {#equalsIgnoreMetadata}
 
-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.
+### Comment déterminer si deux CRS sont « fonctionnellement » égaux ?  {#equalsIgnoreMetadata}
 
-Afin de tester si deux CRS sont fonctionnellement équivalents, utilisez la méthode `Utilities.equalsIgnoreMetadata(myFirstCRS, mySecondCRS)`.
+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 `Utilities.equalsIgnoreMetadata(myFirstCRS, mySecondCRS)`.
 
 
 
-### Est-ce que les CRS sont utilisables comme clé dans un HashMap ?    {#crsHashCode}
+### Est-ce que les CRS sont utilisables comme clé dans un HashMap ?    {#crsHashCode}
 
-Oui, toutes les classes définies dans les paquets `org.apache.sis.referencing.crs`, `cs` et `datum`
-définissent leurs propres méthodes `equals(Object)` et `hashCode()`.
-La bibliothèque Apache SIS utilise elle-même les objets CRS dans des `Map` à des fins de cache.
+Oui, toutes les classes définies dans les paquets `org.apache.sis.referencing.crs`, `cs` et `datum`
+définissent leurs propres méthodes `equals(Object)` et `hashCode()`.
+La bibliothèque Apache SIS utilise elle-même les objets CRS dans des `Map` à des fins de cache.
 
 
 
-Transformation de coordonnées   {#transforms}
+Transformation de coordonnées   {#transforms}
 -------------------------------------------
 
-### Mes coordonnées transformées sont totalement fausses !    {#axisOrderInTransforms}
+### Mes coordonnées transformées sont totalement fausses !    {#axisOrderInTransforms}
 
-Ce cas se produit principalement à cause des ordonnées données dans le mauvais ordre.
-Les développeurs ont tendance à présumer que l’ordre des  axes est (_x_, _y_) ou (_longitude_, _latitude_)
-mais les géographes et pilotes utilisent l’ordre (_latitude_, _longitude_) 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 :
+Ce cas se produit principalement à cause des ordonnées données dans le mauvais ordre.
+Les développeurs ont tendance à présumer que l’ordre des  axes est (_x_, _y_) ou (_longitude_, _latitude_)
+mais les géographes et pilotes utilisent l’ordre (_latitude_, _longitude_) 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 :
 
     :::java
     System.out.println(sourceCRS);
     System.out.println(targetCRS);
 
-Une attention particulière doit être portée à l’ordre des éléments `AXIS`.
-Dans l’exemple ci-dessous, le CRS stipule clairement l’ordre (_latitude_, _longitude_) :
+Une attention particulière doit être portée à l’ordre des éléments `AXIS`.
+Dans l’exemple ci-dessous, le CRS stipule clairement l’ordre (_latitude_, _longitude_) :
 
     :::text
     GeodeticCRS["WGS 84",
@@ -259,114 +278,113 @@ Dans l’exemple ci-dessous, le CRS s
         Axis["Geodetic longitude (Lon)", east],
         Unit["degree", 0.017453292519943295]]
 
-Si l’ordre (_longitude_, _latitude_) est voulu, Apache SIS est capable de le forcer comme décrit [ci-dessus](#axisOrder).
+Si l’ordre (_longitude_, _latitude_) est voulu, Apache SIS est capable de le forcer comme décrit [ci-dessus](#axisOrder).
 
 
 
-### Les ordres des axes sont corrects mais les coordonnées transformées sont encore fausses.  {#projectionName}
+### Les ordres des axes sont corrects mais les coordonnées transformées sont encore fausses.  {#projectionName}
 
-Vérifiez que se sont les bonnes projections qui sont utilisées. Certains noms sont déroutants.
-Par exemple _"Oblique Mercator"_ et _"Hotine Oblique Mercator"_ (dans l’autorité EPSG) sont deux projections différentes.
-Mais _"Oblique Mercator"_ (sans le Hotine) de l’autorité EPSG est aussi appelée _"Hotine Oblique Mercator Azimuth Center"_ par ESRI.
-tandis que _"Hotine Oblique Mercator"_ (de l’autorité EPSG) est appelée _"Hotine Oblique Mercator Azimuth Natural Origin"_ par ESRI.
+Vérifiez que se sont les bonnes projections qui sont utilisées. Certains noms sont déroutants.
+Par exemple _« Oblique Mercator »_ et _« Hotine Oblique Mercator »_ (dans l’autorité EPSG) sont deux projections différentes.
+Mais _« Oblique Mercator »_ (sans le Hotine) de l’autorité EPSG est aussi appelée _« Hotine Oblique Mercator Azimuth Center »_ par ESRI.
+tandis que _« Hotine Oblique Mercator »_ (de l’autorité EPSG) est appelée _« Hotine Oblique Mercator Azimuth Natural Origin »_ par ESRI.
 
-La projection _"Oblique Stereographic"_ (de l’autorité EPSG) est appelée _"Double Stereographic"_ par ESRI.
-ESRI définit aussi une projection _"Stereographic"_ qui est en réalité une projection oblique comme la précédente mais avec des formules différentes.
+La projection _« Oblique Stereographic »_ (de l’autorité EPSG) est appelée _« Double Stereographic »_ par ESRI.
+ESRI définit aussi une projection _« Stereographic »_ qui est en réalité une projection oblique comme la précédente mais avec des formules différentes.
 
 
 
-### J’ai juste utilisé le WKT d’une autorité connue et mes coordonnées transformées sont toujours fausses !    {#parameterUnits}
+### J’ai juste utilisé le WKT d’une autorité connue et mes coordonnées transformées sont toujours fausses !    {#parameterUnits}
 
-La spécification _Well Known Text_ (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 : _"Si l’élément `PRIMEM` apparaît dans `GEOGCS`,
-alors l’unité des longitudes doit correspondre à celle du système de coordonnées géographiques"_ (traduction libre de OGC 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 :
+La spécification _Well Known Text_ (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 : _« Si l’élément `PRIMEM` apparaît dans `GEOGCS`,
+alors l’unité des longitudes doit correspondre à celle du système de coordonnées géographiques »_ (traduction libre de OGC 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 :
 
     :::text
-    PROJCS["Lambert II étendu",
-      GEOGCS["Nouvelle Triangulation Française", …,
+    PROJCS["Lambert II étendu",
+      GEOGCS["Nouvelle Triangulation Française", …,
         PRIMEM["Paris", 2.337229167],
         UNIT["grad", 0.01570796326794897]]
       PROJECTION["Lambert_Conformal_Conic_1SP"],
-      PARAMETER["latitude_of_origin", 46.8], …]
+      PARAMETER["latitude_of_origin", 46.8], …]
 
-Le méridien d’origine de Paris est situé à approximativement 2,597 gradians de Greenwich, ce qui correspond à 2,337 degrés.
-À partir de ce fait, on peut voir que le WKT ci-dessus utilise des degrés malgré la déclaration de l’unité `UNIT["grad"]`.
-Cette erreur s’applique aussi aux valeurs des paramètres, qui déclarent 46,8° dans l’exemple ci-dessus alors que la valeur officielle est de 52 gradians.
-Par défaut, Apache SIS interprète ces valeurs angulaires en gradians quand il lit ce type de WKT, ce qui produit de grandes erreurs.
-Afin d’obtenir le résultat attendu, il est possible de :
+Le méridien d’origine de Paris est situé à approximativement 2,597 gradians de Greenwich, ce qui correspond à 2,337 degrés.
+À partir de ce fait, on peut voir que le WKT ci-dessus utilise des degrés malgré la déclaration de l’unité `UNIT["grad"]`.
+Cette erreur s’applique aussi aux valeurs des paramètres, qui déclarent 46,8° dans l’exemple ci-dessus alors que la valeur officielle est de 52 gradians.
+Par défaut, Apache SIS interprète ces valeurs angulaires en gradians quand il lit ce type de WKT, ce qui produit de grandes erreurs.
+Afin d’obtenir le résultat attendu, il est possible de :
 
   * Remplacer `UNIT["grad", 0.01570796326794897]` par `UNIT["degree", 0.017453292519943295]`,
-    ce qui va assurer que Apache SIS, GDAL et ESRI comprennent ce WKT de la même manière.
-
-  * Ou demander explicitement à Apache SIS de lire le WKT en utilisant les conventions ESRI ou GDAL,
-    avec l’énumération `Convention.​WKT1_COMMON_UNITS` pour la valeur de `WKTFormat` dans le paquet `org.​apache.​sis.​io.​wkt`.
+    ce qui va assurer que Apache SIS, GDAL et ESRI comprennent ce WKT de la même manière.
 
-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.
-Le comportement par défaut de Apache SIS est cohérent avec ces deux standards.
+  * Ou demander explicitement à Apache SIS de lire le WKT en utilisant les conventions ESRI ou GDAL,
+    avec l’énumération `Convention.​WKT1_COMMON_UNITS` pour la valeur de `WKTFormat` dans le paquet `org.​apache.​sis.​io.​wkt`.
 
+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.
+Le comportement par défaut de Apache SIS est cohérent avec ces deux standards.
 
 
-### J’ai vérifié tous ce qui est ci-dessus et j’ai toujours une erreur d’environ un kilomètre. {#BursaWolf}
 
-Les systèmes de coordonnées (CRS) font une approximation de la forme de la terre avec une ellipsoïde.
-Différentes ellipsoïdes (en réalité différents _référentiels_) 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.
-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.
+### J’ai vérifié tous ce qui est ci-dessus et j’ai toujours une erreur d’environ un kilomètre. {#BursaWolf}
 
-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 `TOWGS84` de la version 1 du format _Well Known Text_ (WKT),
-ou dans l’élément `BOUNDCRS` 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é.
+Les systèmes de coordonnées (CRS) font une approximation de la forme de la terre avec une ellipsoïde.
+Différentes ellipsoïdes (en réalité différents _référentiels_) 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.
+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.
 
+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 `TOWGS84` de la version 1 du format _Well Known Text_ (WKT),
+ou dans l’élément `BOUNDCRS` 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é.
 
 
-### J’obtiens des résultats légèrement différents d’un environnement d’exécution à l’autre.   {#slightDifferences}
 
-Les résultats de transformations de coordonnées quand on lance l’application dans un conteneur web (type JBoss, _etc._)
-peuvent avoir quelques mètres de différence avec la transformation exécutée dans un IDE (NetBeans, Eclipse, _etc._).
-Les résultats dépendent de la présence de la fabrique EPSG dans le chemin de classes (classpath),
-**peu importe comment le CRS a été créé**, parce-que la fabrique EPSG spécifie explicitement l’opération à appliquer pour certaines paires de CRS.
-Dans ces cas, l’opération spécifiée par EPSG a priorité par rapport aux paramètres de Bursa-Wolf
-(l’element `TOWGS84` de la version 1 du format Well Known Text).
+### J’obtiens des résultats légèrement différents d’un environnement d’exécution à l’autre.   {#slightDifferences}
 
-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.
-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 [paramètres de connexion à la base EPSG](epsg.html) sont les mêmes.
+Les résultats de transformations de coordonnées quand on lance l’application dans un conteneur web (type JBoss, _etc._)
+peuvent avoir quelques mètres de différence avec la transformation exécutée dans un IDE (NetBeans, Eclipse, _etc._).
+Les résultats dépendent de la présence de la fabrique EPSG dans le chemin de classes (classpath),
+**peu importe comment le CRS a été créé**, parce-que la fabrique EPSG spécifie explicitement l’opération à appliquer pour certaines paires de CRS.
+Dans ces cas, l’opération spécifiée par EPSG a priorité par rapport aux paramètres de Bursa-Wolf
+(l’element `TOWGS84` de la version 1 du format _Well Known Text_).
 
+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.
+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 [paramètres de connexion à la base EPSG](epsg.html) sont les mêmes.
 
 
-### Puis-je présumer qu’il est toujours possible de transformer un CRS arbitraire vers WGS84 ?    {#toWGS84}
 
-Pour les CRS 2D horizontaux créés avec la base de données EPSG, l’appel à `CRS.findOperation(…)` 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 `EngineeringCRS`, la méthode peu échouer.
+### Puis-je présumer qu’il est toujours possible de transformer un CRS arbitraire vers WGS84 ?    {#toWGS84}
 
-Il reste à noter que dans le cas ou la méthode `CRS.findOperation(…)` ne lève pas d’erreur, l’appel à `MathTransform.transform(…)` peut
-produire des valeurs `NaN` or `Infinity`si la coordonnée transformée est éloignée de la zone de validité.
+Pour les CRS 2D horizontaux créés avec la base de données EPSG, l’appel à `CRS.findOperation(…)` 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 `EngineeringCRS`, la méthode peu échouer.
+Il reste à noter que dans le cas ou la méthode `CRS.findOperation(…)` ne lève pas d’erreur, l’appel à `MathTransform.transform(…)` peut
+produire des valeurs `NaN` or `Infinity`si la coordonnée transformée est éloignée de la zone de validité.
 
 
 
-Métadonnées    {#metadata}
+Métadonnées    {#metadata}
 ===========================
 
 Implementations sur mesures   {#metadata-implementation}
 ----------------------------------------------------
 
-### Mes metadonnées sont stockées dans une forme de base de données. Implémenter toute les interfaces de GeoAPI est infaisable.    {#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.    {#metadata-proxy}
 
-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
-et de laisser la Machine Virtuelle Java implémenter les interfaces GeoAPI à la volée, en utilisant la classe `java.lang.reflect.Proxy`.
-Pour plus de détails voir la javadoc de la classe `Proxy`, en gardant à l’esprit que le nom ISO/OGC d’une `java.lang.Class` ou
-`java.lang.reflect.Method` peut être obtenu comme suit :
+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
+et de laisser la Machine Virtuelle Java implémenter les interfaces GeoAPI à la volée, en utilisant la classe `java.lang.reflect.Proxy`.
+Pour plus de détails voir la javadoc de la classe `Proxy`, en gardant à l’esprit que le nom ISO/OGC d’une `java.lang.Class` ou
+`java.lang.reflect.Method` peut être obtenu comme suit :
 
     :::java
     UML uml = method.getAnnotation(UML.class);
@@ -375,27 +393,26 @@ Pour plus de détails voir la javadoc
         // Fetch the metadata here.
     }
 
-Cette approche est utilisée dans le paquet `org.apache.sis.metadata.sql` pour fournir une implémentation
-de toutes les interfaces de metadonnées de GeoAPI à partir d’une base de données SQL.
+Cette approche est utilisée dans le paquet `org.apache.sis.metadata.sql` pour fournir une implémentation
+de toutes les interfaces de metadonnées de GeoAPI à partir d’une base de données SQL.
 
 
-### Je n’arrive pas à écrire mon implémentation de metadonnée  {#metadata-unknownClass}
+### Je n’arrive pas à écrire mon implémentation de metadonnée  {#metadata-unknownClass}
 
-Les classes données à un marshaller JAXB doivent contenir des annotations JAXB,
-sinon l’exception suivante sera lancée :
+Les classes données à un marshaller JAXB doivent contenir des annotations JAXB,
+sinon l’exception suivante sera lancée :
 
     :::text
     javax.xml.bind.JAXBException: class MyCustomClass nor any of its super class is known to this context.
 
-La solution de contournement la plus simple est de décorer l’implémentation dans une des implémentations
+La solution de contournement la plus simple est de décorer l’implémentation dans une des implémentations
 fournies dans le paquet `org.apache.metadata.iso`.
-
-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.
+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.
 
 
-Abréviations utilisées dans ce FAQ
+Abréviations utilisées dans ce FAQ
 ==================================
 
 * [CRS]:  Coordinate Reference System

Propchange: sis/site/trunk/content/faq_fr.mdtext
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: sis/site/trunk/content/faq_fr.mdtext
------------------------------------------------------------------------------
    svn:mime-type = text/plain;charset=UTF-8



Mime
View raw message