You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sis.apache.org by de...@apache.org on 2017/05/09 23:04:36 UTC
svn commit: r1794656 [11/18] - in /sis/site/trunk/book: en/ en/annex/
en/coverage/ en/geometry/ en/introduction/ en/referencing/ en/utility/
en/xml/ fr/ fr/annex/ fr/coverage/ fr/geometry/ fr/introduction/
fr/referencing/ fr/utility/ fr/xml/
Copied: sis/site/trunk/book/fr/annex/ReduceDependency.html (from r1794573, sis/site/trunk/book/fr/annexes.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/annex/ReduceDependency.html?p2=sis/site/trunk/book/fr/annex/ReduceDependency.html&p1=sis/site/trunk/book/fr/annexes.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/annexes.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/annex/ReduceDependency.html [UTF-8] Tue May 9 23:04:35 2017
@@ -20,23 +20,21 @@
under the License.
-->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"
- xmlns:xi = "http://www.w3.org/2001/XInclude">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
- <title>Annexes</title>
+ <title>ReduceDependency</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+ <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
</head>
<body>
<!--
- Content below this point is copied in "../../content/book/fr/developer-guide.html"
+ Content below this point is copied in "(…)/content/book/fr/developer-guide.html" file
by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
-->
<section>
<header>
- <h1 id="Annexes">Annexes</h1>
+ <h2 id="ReduceDependency">Réduire la dépendance directe envers Apache SIS</h2>
</header>
- <h2 id="ReduceDependency">Réduire la dépendance directe envers Apache SIS</h2>
<p>
Les chapitres précédents utilisaient des méthodes statiques de Apache SIS par commodité.
Dans certains cas, il est possible de remplacer ces méthodes statiques par du code ne faisant appel qu’à des méthodes de GeoAPI.
@@ -210,437 +208,6 @@ public class MyApplication {
L’avantage de passer par ces interfaces est de disposer d’un modèle unifié pour exploiter deux <abbr>API</abbr> très différents,
tout en se gardant la possibilité de basculer plus facilement à une autre bibliothèque si désiré.
</p>
-
-
- <h2 id="Tests">Les suites de tests</h2>
- <p>
- En plus des tests propres au projet, Apache SIS utilise aussi des tests définis par GeoAPI.
- Ces tests ont l’avantage d’utiliser une source externe définissant ce que doivent être les résultats
- (par exemple les valeurs des coordonnées obtenues par une projection cartographique).
- On réduit ainsi le risque que des tests soient davantage des tests anti-régression que des tests de validité.
- Ces tests peuvent aussi être utilisés par des projets autres que Apache SIS.
- </p>
- <p id="GeoAPI-conformance">
- Le module <code>geoapi-conformance</code> fournit des <i>validateurs</i>, une <i>suite de tests</i> JUnit
- et des <i>générateurs de rapports</i> sous forme de pages <abbr title="Hypertext Markup Language">HTML</abbr>.
- Ce module peut être utilisé avec n’importe quelle implémentation de GeoAPI.
- Pour les développeurs d’une bibliothèque géospatiale, il offre les avantages suivants:
- </p>
- <ul>
- <li>Réduire la fastidieuse tâche d’écriture des tests, en réutilisant des tests existants.</li>
- <li>Accroître la confiance en la validité des tests, du fait que <code>geoapi-conformance</code>
- a lui-même sa propre suite de tests et est appliqué à d’autres implémentations.</li>
- <li>Faciliter la comparaison avec les autres implémentations.</li>
- </ul>
-
-
-
- <h3 id="GeoAPI-validators">Validations des instances</h3>
- <p>
- GeoAPI peut valider une instance de ses interfaces en vérifiant que certaines contraintes sont respectées.
- Certaines contraintes ne peuvent pas être exprimées dans la signature de la méthode. Ces contraintes sont
- généralement décrites textuellement dans les spécifications abstraites ou dans la javadoc.
- </p>
- <div class="example"><p><b>Exemple:</b>
- La conversion ou transformation d’une coordonnée (<code>CC_CoordinateOperation</code>) peut nécessiter l’enchaînement de plusieurs étapes.
- Dans une telle chaîne d’opérations (<code>CC_ConcatenatedOperation</code>),
- pour chaque étape (<code>CC_SingleOperation</code>) le nombre de dimensions
- en sortie doit être égal au nombre de dimensions attendu en entré par l’opération suivante.
- Exprimée en langage Java, cette contrainte stipule que pour tout index
- 0 < <var>i</var> < <var>n</var> où <var>n</var> est le nombre d’opérations, on a
- <code>coordOperation[i].targetDimensions == coordOperation[i-1].sourceDimensions</code>.
- </p></div>
-
- <p>
- La façon la plus simple d’effectuer ces vérifications est d’appeler les méthodes statiques
- <code class="GeoAPI">validate(…)</code> de la classe <code>org.opengis.test.Validators</code>.
- Ces méthodes portant toutes le même nom, il suffit d’écrire “<code>validate(<var>valeur</var>)</code>”
- et de laisser le compilateur choisir la méthode la plus appropriée en fonction du type d’objet donné en argument.
- Si le type d’objet n’est pas connu au moment de la compilation, alors la méthode <code class="GeoAPI">dispatch(Object)</code>
- peut se charger de rediriger le travail à la méthode <code class="GeoAPI">validate(…)</code> appropriée.
- </p>
- <p>
- Toutes les fonctions <code class="GeoAPI">validate(…)</code> suivent le fil des dépendances,
- c’est-à-dire qu’elles valideront aussi chaque composantes de l’objet à valider.
- Par exemple la validation d’un objet <code>GeographicCRS</code> impliquera
- la validation de sa composante <code>GeodeticDatum</code>, qui impliquera elle-même
- la validation de sa composante <code>Ellipsoid</code>, et ainsi de suite.
- Il est donc inutile de valider soi-même les composantes, à moins de vouloir isoler le test d’un élément souvent problématique.
- </p>
- <p>
- Par défaut, les validations sont aussi strictes que possible. Il est possible toutefois d’assouplir certaines règles.
- L’assouplissement le plus fréquent consiste à tolérer l’absence d’attributs qui étaient sensés être obligatoires.
- Cette règle et quelques autres peuvent être modifiées globalement pour tous les tests exécutés dans la
- <abbr title="Java Virtual Machine">JVM</abbr> courante comme dans l’exemple suivant:
- </p>
-
-<pre>import org.opengis.metadata.Metadata;
-import org.opengis.test.Validators;
-import org.junit.Test;
-
-public class MyTest {
- /*
- * Tolérer l’absence d’attributs obligatoires dans les paquets metadata et citation.
- * Cette modification s’appliquera à tous les tests exécutés dans la <abbr>JVM</abbr> courante.
- * S’il existe plusieurs classes de tests, cette initialisation peut être effectuée
- * dans une classe parente à toutes les classes de tests.
- */
- static {
- Validators.<code class="GeoAPI">DEFAULT.metadata.requireMandatoryAttributes</code> = false;
- Validators.<code class="GeoAPI">DEFAULT.citation.requireMandatoryAttributes</code> = false;
- }
-
- @Test
- public void testMyMetadata() {
- Metadata myObject = …; // Construisez un objet ici.
- Validators.<code class="GeoAPI">validate</code>(myObject);
- }
-}</pre>
-
- <p>
- Les règles peuvent aussi être modifiées pour une suite de tests particulière,
- sans affecter la configuration par défaut de la <abbr>JVM</abbr> courante.
- Cette approche nécessite de créer une nouvelle instance du validateur dont on souhaite modifier la configuration.
- </p>
-
-<pre>import org.opengis.metadata.Metadata;
-import org.opengis.test.ValidatorContainer;
-import org.junit.Test;
-
-public class MyTest {
- private final ValidatorContainer validators;
-
- public MyTest() {
- validators = new ValidatorContainer();
- validators.<code class="GeoAPI">metadata.requireMandatoryAttributes</code> = false;
- validators.<code class="GeoAPI">citation.requireMandatoryAttributes</code> = false;
- }
-
- @Test
- public void testMyMetadata() {
- Metadata myObject = …; // Construisez un objet ici.
- validators.<code class="GeoAPI">validate</code>(myObject);
- }
-}</pre>
-
-
-
- <h3 id="GeoAPI-tests">Exécution des tests pré-définis</h3>
- <p>
- Des classes de tests JUnit sont définies dans des sous-paquets de <code>org.opengis.test</code>.
- Toutes les classes de tests portent un nom se terminant en "<code>Test</code>".
- GeoAPI définie aussi une classe <code>org.opengis.test.TestSuite</code> englobant l’ensemble
- des tests définis dans le module <code>geoapi-conformance</code>, mais Apache <abbr>SIS</abbr> ne l’utilise pas.
- Apache <abbr>SIS</abbr> hérite plutôt des classes <code class="GeoAPI">*Test</code> de GeoAPI au cas-par-cas, dans les modules appropriés.
- L’exemple ci-dessous donne un exemple de test de GeoAPI personnalisé.
- La <a href="http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/referencing/ParameterizedTransformTest.html">Javadoc
- de la classe parente</a> documente en détails les tests effectués.
- Dans cet exemple, un seul test est modifié et tous les autres tests sont hérités tels quels
- (il n’est pas nécessaire de les répéter dans la sous-classe).
- Toutefois, cet exemple ajoute une vérification supplémentaire, annotée <code>@After</code>,
- qui sera exécutée après chacun des tests.
- </p>
-
-<pre>import org.junit.*;
-import org.junit.runner.RunWith;
-import org.junit.runners.JUnit4;
-import org.opengis.test.referencing.ParameterizedTransformTest;
-import static org.junit.Assert.*;
-
-@RunWith(JUnit4.class)
-public class MyTest extends ParameterizedTransformTest {
- /**
- * Spécifie aux tests de GeoAPI notre propre fabrique de transformations de coordonnées.
- * GeoAPI testera les objets construits par cette fabrique.
- */
- public MyTest() {
- super(new MyMathTransformFactory());
- }
-
- /**
- * Modifie le comportement d’un test. Cet exemple assouplit un peu les exigences de ce test,
- * en acceptant des erreurs jusqu’à 10 centimètres plutôt que la valeur par défaut de 1 cm.
- * Ce changement ne s’applique qu’à cette méthode est n’affecte pas les autres tests hérités.
- */
- @Test
- @Override
- public void testLambertAzimuthalEqualArea() throws FactoryException, TransformException {
- <code class="GeoAPI">tolerance</code> = 0.1; // Tolérance de 10 cm.
- super.<code class="GeoAPI">testLambertAzimuthalEqualArea()</code>;
- }
-
- /**
- * Vérification supplémentaire effectuée après chaque test, hérité ou non.
- * Dans cet exemple, nous vérifions que la transformation qui a été testée
- * travaillait bien dans des espaces bi-dimensionnels.
- */
- @After
- public void ensureAllTransformAreMath2D() {
- assertTrue(<code class="GeoAPI">transform</code> instanceof MathTransform2D);
- }
-}</pre>
-
-
-
- <h2 id="DesignNote">Notes de design</h2>
- <p>Les chapitres suivants expliquent les raisons derrières certains choix d'implémentation de Apache <abbr>SIS</abbr>.</p>
-
-
- <h3 id="AffineTransform">Utilisation des transformations affines</h3>
- <p>
- Parmi les sortes d’opérations qu’un <abbr>SIG</abbr> doit effectuer sur les coordonnées spatiales,
- les <cite>transformations affines</cite> sont à la fois relativement simples et très fréquentes.
- Les transformations affines peuvent représenter n’importe quelle combinaison d’échelles, de cisaillements,
- de retournements, de rotations ou de translations, qui sont toutes des <cite>opérations linéaires</cite>.
- Les transformations affines ne peuvent pas effectuer des opérations <cite>non-linéaires</cite>
- telles que les projections cartographiques, mais couvrent néanmoins de nombreux autres cas:
- </p>
- <ul>
- <li>Changer l’ordre des axes, par exemple de (<var>latitude</var>, <var>longitude</var>) vers (<var>longitude</var>, <var>latitude</var>).</li>
- <li>Changer la direction des axes, par exemple l’axe des <var>y</var> qui pointe habituellement vers le bas dans les images.</li>
- <li>Changer le méridien d’origine, par exemple du méridien de <cite>Paris</cite> vers celui de <cite>Greenwich</cite>.</li>
- <li>Changer le nombre de dimensions, par exemple passer des coordonnées 3D vers 2D en supprimant la hauteur.</li>
- <li>Convertir des unités de mesures, par exemple convertir des pieds en mètres.</li>
- <li>Convertir des coordonnées pixels en coordonnées géographiques,
- par exemple la conversion exprimée dans les fichiers <code>.tfw</code> qui accompagnent certaines images <abbr>TIFF</abbr>.</li>
- <li>Prendre en charge une petite partie des projections cartographiques,
- par exemple les paramètres <cite>False Easting</cite>, <cite>False Northing</cite> et <cite>Scale factor</cite>.</li>
- </ul>
- <p>
- Les transformations affines peuvent se combiner efficacement.
- Peu importe le nombre de transformations affines que l’on enchaîne, le résultat sera exprimable par une seule transformation affine.
- Cette propriété est plus facilement visible lorsque les transformations affines sont exprimées sous forme de matrices:
- pour combiner les opérations, il suffit de multiplier les matrices.
- Le cas des conversions des coordonnées pixels en coordonnées géographiques ci-dessous donne un exemple.
- </p>
-
- <div class="example">
- <p><b>Exemple:</b>
- supposons que nous disposons d’une image dont les coordonnées des pixels sont représentées par (<var>x</var>,<var>y</var>).
- Supposons aussi que les contraintes suivantes sont respectées:
- </p>
- <ul>
- <li>Il n’y a ni cisaillement, ni rotation, ni retournement de l’image.</li>
- <li>Tous les pixels ont la même largeur en degrés de longitude.</li>
- <li>Tous les pixels ont la même hauteur en degrés de latitude.</li>
- <li>Les coordonnées des pixels commencent à (0,0) inclusivement.</li>
- </ul>
- <p>Alors la conversion des coordonnées pixels (<var>x</var>,<var>y</var>)
- vers les coordonnées géographiques (<var>λ</var>,<var>φ</var>)
- peut être représentée par les équations suivantes,
- où <var>N</var><sub><var>x</var></sub> est la largeur
- et <var>N</var><sub><var>y</var></sub> la hauteur de l’image en nombre de pixels.
- </p><p>
- <xi:include href="../math/PixelToGeographicTerms.html"/>
- </p><p>
- Les équations ci-dessus peuvent être représentées sous forme de matrices comme ci-dessous:
- </p><p>
- <xi:include href="../math/PixelToGeographic.html"/>
- </p><p>
- Dans ce cas particulier, les facteurs d’échelles <var>S</var> correspondent à la taille des pixels en degrés
- et les termes de translations <var>T</var> correspondent aux coordonnées géographiques d’un coin de l’image
- (pas nécessairement le coin inférieur gauche si certains axes ont été retournés).
- Cette interprétation directe n’est possible que lorsque les contraintes énumérées plus haut sont respectées.
- Les coefficients des matrices deviennent plus complexes si l’image a un cisaillement ou une rotation,
- ou si les coordonnées des pixels ne commencent pas à (0,0).
- Toutefois il n’est pas nécessaire d’utiliser des équations plus complexes pour gérer des cas plus génériques.
- L’exemple ci-dessous prend comme point de départ la matrice d’une « conversion initiale »
- dans laquelle les coefficients <var>S</var> et <var>T</var> sont les valeurs relativement simples données ci-dessus.
- Ensuite la direction de l’axe des <var>y</var> est inversée de manière à correspondre
- à la convention habituelle des systèmes de coordonnées des images (changement 1),
- et les axes sont intervertis de manière à avoir la latitude avant la longitude (changement 2).
- Notez que les concaténations de transformations affines écrites sous forme de multiplications matricielles
- se lisent de droite à gauche:
- <var>A</var>×<var>B</var>×<var>C</var> est équivalent à d’abord appliquer l’opération <var>C</var>,
- suivit de l’opération <var>B</var> et finalement l’opération <var>A</var>.
- </p>
- <table class="hidden"><tr>
- <th>Changement 2</th><th></th>
- <th>Changement 1</th><th></th>
- <th>Conversion initiale</th><th></th>
- <th>Opérations combinées</th>
- </tr><tr>
- <td style="vertical-align: middle"><xi:include href="../math/AxisSwapping2D.html"/></td>
- <td style="vertical-align: middle; padding-left: 15px; padding-right: 15px">×</td>
- <td style="vertical-align: middle"><xi:include href="../math/InverseAxisY.html"/></td>
- <td style="vertical-align: middle; padding-left: 15px; padding-right: 15px">×</td>
- <td style="vertical-align: middle"><xi:include href="../math/PixelToGeographicSameAxisDirections.html"/></td>
- <td style="vertical-align: middle; padding-left: 15px; padding-right: 15px">=</td>
- <td style="vertical-align: middle"><xi:include href="../math/PixelToGeographicReverseOrderAndY.html"/></td>
- </tr></table>
- <p>
- Un principe clé est qu’il n’y a pas besoin d’écrire un code dédié à ce type d’opérations sur les axes.
- Ces opérations, et bien d’autres, sont prises en compte naturellement par l’algèbre matricielle.
- On y gagne en généricité du code et en performance.
- Apache <abbr>SIS</abbr> suit ce principe en utilisant les tranformations affine pour toutes les opérations
- où elles peuvent s’appliquer.
- Il n’y a par exemple aucun code dédié au changement de l’ordre des ordonnées dans une coordonnée.
- </p>
- </div>
-
- <h4 id="AffineTransformAPI">Intégration avec les bibliothèques graphiques</h4>
- <p>
- A peu près toutes les bibliothèques graphiques supportent une forme de transformation de coordonnées,
- souvent les <cite>transformations affines</cite> ou une légère généralisation.
- Chaque bibliothèque défini son propre <abbr>API</abbr>.
- Quelques exemples sont:
- </p>
- <table>
- <caption>Implémentations des transformations affines dans des bibliothèques graphiques</caption>
- <tr><th>Bibliothèque</th> <th>Implementation de la transformation</th> <th>Dimensions</th></tr>
- <tr><td>Java2D</td> <td><code>java.awt.geom.AffineTransform</code></td> <td>2</td></tr>
- <tr><td>Java3D</td> <td><code>javax.media.j3d.Transform3D</code></td> <td>3</td></tr>
- <tr><td>JavaFX</td> <td><code>javafx.scene.transform.Affine</code></td> <td>2 ou 3</td></tr>
- <tr><td>Java Advanced Imaging (<abbr>JAI</abbr>)</td> <td><code>javax.media.jai.PerspectiveTransform</code></td> <td>2</td></tr>
- <tr><td>Android</td> <td><code>android.graphics.Matrix</code></td> <td>2</td></tr>
- </table>
- <p>
- Toutefois dans plusieurs cas, les transformations affines sont les seuls types d’opérations supportées par la bibliothèque graphique.
- Apache <abbr>SIS</abbr> a besoin de gérer un plus grand nombre de type d’opérations,
- parmi lesquelles les transformations affines ne sont que des cas particuliers.
- Les projections cartographiques et les changements de référentiels notamment,
- ne peuvent pas être représentés par des transformations affines.
- <abbr>SIS</abbr> a aussi besoin de transformer des points ayant un nombre arbitraire de dimensions,
- alors que les <abbr>API</abbr> cités ci-haut restreignent leur usage à un nombre fixe de dimensions.
- Pour ces raisons, <abbr>SIS</abbr> ne peut pas utiliser directement ces <abbr>API</abbr>.
- <abbr>SIS</abbr> utilise plutôt une interface plus abstraite, <code>org.opengis.referencing.transform.MathTransform</code>.
- Mais dans le cas particulier où la transformation est réellement affine, <abbr>SIS</abbr> peut essayer d’utiliser
- une implémentation existante, surtout Java2D.
- Par exemple le code suivant peut être utilisé dans les situations où un objet Java2D est désiré:
- </p>
-
-<pre>MathTransform mt = ...; // N’importe quelle instance créée par Apache SIS.
-if (mt instanceof AffineTransform) {
- AffineTransform at = (AffineTransform) mt;
- // Utiliser l’API de Java2D API à partir d’ici.
-}</pre>
-
- <p>
- Toutefois <abbr>SIS</abbr> n’utilisera Java2D que sur une base opportuniste.
- Le forçage de type ci-haut n’est pas garantit de réussir, même si l’instance de
- <code>MathTransform</code> répond aux conditions qui devrait permettre un usage de Java2D.
- </p>
-
-
- <h3 id="MatrixLibrary">Particularités d’une bibliothèque de calculs matriciels pour un <abbr>SIG</abbr></h3>
- <p>
- Les <abbr>SIG</abbr> font un usage intensif de matrices afin d’afficher leurs cartes ou transformer des coordonnées.
- On pourrait croire que le marché est suffisamment bien pourvu en excellentes bibliothèques de calculs matriciels, libres ou commerciales.
- Pourtant, les <abbr>SIG</abbr> ont des besoins spécifiques qui divergent un peu des objectifs de plusieurs bibliothèques existantes.
- Des manipulations de matrices comme celles décrites dans <a href="#AffineTransform">le chapitre sur les transformations affines</a>
- interviennent dans quasiment toutes les opérations appliquées par Apache <abbr>SIS</abbr> sur des coordonnées.
- Mais l’analyse de ces opérations révèle quelques patterns:
- </p>
- <ul>
- <li><p>Ces matrices sont presque toujours de petites tailles, dépassant rarement 5 lignes par 5 colonnes.</p></li>
- <li><p>Les opérations matricielles « lourdes » (multiplications ou inversions de matrices) ne surviennent pas dans des endroits où la performance est importante.
- Dans la quasi-totalité des cas, elles ne sont effectuées qu’une fois pour toute, à la lecture d’un fichier,
- ou lors des étapes de préparation avant de convertir des coordonnées.
- Elles ne surviennent quasiment jamais dans la boucle convertissant chacune des coordonnées.</p></li>
- <li><p>Dans une succession de multiplications et d’inversions de matrices, les erreurs d’arrondissement s’accumulent et grandissent rapidement
- au point de se confondre avec certaines opérations légitimes, notamment les changements de référentiel.
- Ces dernières s’expriment souvent par un changement de la taille, position et orientation de l’ellipsoïde
- choisi comme approximation de la forme de la Terre.
- Or ces changements de taille s’expriment en parties par million et les rotations en arc-secondes.
- Retranscrites dans une matrice, ces valeurs sont donc assez petites.</p></li>
- <li><p>Il arrive fréquemment que des matrices s’annulent en tout ou en partie lorsqu’elles sont combinées,
- c’est-à-dire que leurs multiplications ramènent des facteurs d’échelles à 1 et des translations à 0.
- Toutefois les erreurs d’arrondissements font que les valeurs obtenues sont rarement exactes,
- mais plutôt des valeurs s’en rapprochant telles que 0,9999…97 à la place de 1.
- L’approche habituelle pour contourner ce problème est d’effectuer les comparaisons de nombres à virgule flottante en tolérant un léger écart.
- Mais il est difficile de choisir un seuil de tolérance qui gommera la plupart des erreurs d’arrondissement
- sans considérer à tord un changement de référentiel comme un artefact (voir point précédent).</p></li>
- </ul>
- <p>
- Ces points font que, pour un <abbr>SIG</abbr> comme Apache <abbr>SIS</abbr>, la précision d’une bibliothèque de calculs matriciels
- est plus importante que la performance. Paradoxalement, un bon moyen de gagner en performance est justement d’investir davantage de temps de CPU
- pour effectuer des opérations matricielles plus précises dans la phase de <em>préparation</em> (non d’<em>exécution</em>) de la transformation de coordonnées,
- car on augmente ainsi les chances de détecter correctement quelles opérations s’annulent.
- L’effort investit dans cette détection permet de sauver du temps là où ça compte: quand viendra le moment de boucler sur des millions de coordonnées à transformer.
- </p><p>
- Mais les bibliothèques dédiées aux calculs matriciels sont souvent conçues pour opérer de manière très performante
- sur des matrices de grandes tailles, ayant par exemple des milliers de lignes et colonnes.
- Elles sont ainsi conçues pour être capable de résoudre efficacement des systèmes d’équations linéaires comportant des centaines d’inconnues.
- Les problèmes qu’elles résolvent sont certes difficiles, mais assez différents de ceux qui intéressent Apache <abbr>SIS</abbr>.
- Pour cette raison, et aussi à cause d’un autre besoin spécifique détaillé dans les paragraphes suivants,
- Apache <abbr>SIS</abbr> utilise ses propres fonctions de calculs matriciels.
- Ces fonctions tentent de résoudre le problème de précision en utilisant l’arithmétique « double-double »
- (une technique permettant de simuler une précision d’environ 120 bits)
- au prix de la performance pendant une étape (la <em>préparation</em> de la transformation) où elle n’est pas jugée critique.
- </p>
-
- <h4 id="NonSquareMatrix">Que faire des matrices qui ne sont pas carrées (et pourquoi)</h4>
- <p>
- Apache <abbr>SIS</abbr> a très souvent besoin d’inverser des matrices,
- afin d’obtenir une conversion de coordonnées dans la direction inverse de la conversion originale.
- Mais on n’inverse habituellement que des matrices carrées.
- Or, <abbr>SIS</abbr> a besoin d’effectuer des inversions de matrices non-carrées.
- Selon que l’on ait plus de lignes ou plus de colonnes:
- </p>
- <ul>
- <li>Pour <abbr>SIS</abbr>, une matrice non-carrée est une conversion qui ajoute ou supprime une dimension aux coordonnées.</li>
- <li>Pour les bibliothèques d’algèbre linéaire, une matrice non-carrée est un système d’équations sous-déterminé ou surdéterminé.</li>
- </ul>
- <p>
- Pour mieux comprendre les difficultés que causerait une transposition trop directe des bibliothèques d’algèbre linéaire aux <abbr>SIG</abbr>,
- imaginons une conversion (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>) → (<var>φ₂</var>, <var>λ₂</var>)
- qui projetterait les points d’un espace 3D vers une surface 2D.
- Les termes <var>φ</var> sont des latitudes, <var>λ</var> des longitudes et
- (<var>φ₂</var>, <var>λ₂</var>) n’égale pas forcement (<var>φ₁</var>, <var>λ₁</var>) si la hauteur <var>h</var> n’est pas perpendiculaire à la surface.
- </p><p>
- <xi:include href="../math/Geographic3Dto2D.html"/>
- </p><p>
- Pour des bibliothèques d’algèbre linéaire, la matrice ci-dessus représente un système d’équations sous-déterminé, et donc insoluble.
- C’est-à-dire qu’on ne peut pas inverser cette conversion pour obtenir (<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>)
- puisqu’on ne sait pas quelle valeur donner à <var>h</var>,
- ce qui implique qu’on ne peut pas trouver (<var>φ₁</var>, <var>λ₁</var>) non-plus car ces valeurs dépendent peut-être de <var>h</var>.
- Toutefois dans le cas des <abbr>SIG</abbr>, l’axe des hauteurs ellipsoïdales <var>h</var> est perpendiculaire à la surface de l’ellipsoïde
- sur laquelle les latitudes et longitudes <em>géodésiques</em> (<var>φ</var>, <var>λ</var>) sont représentées
- (notez que cette affirmation ne s’applique pas aux latitudes et longitudes <em>géocentriques</em>).
- Cette perpendicularité rend <var>φ₁</var> et <var>λ₁</var> indépendants de <var>h</var>.
- Dans ce genre de cas, on peut encore sauver les meubles.
- </p><p>
- Apache <abbr>SIS</abbr> procède en vérifiant si les valeurs de <var>h</var> sont indépendantes des valeurs de <var>φ</var> et <var>λ</var>.
- Nous reconnaissons ce cas en vérifiant quels coefficients de la matrice ont la valeur zéro.
- Si <abbr>SIS</abbr> arrive à identifier des dimensions indépendantes,
- il peut les exclure temporairement de manière à inverser sans ambiguïté la conversion dans les dimensions restantes.
- S’il ne trouve pas de dimension indépendante, alors une exception est levée.
- Mais si une inversion a été possible, alors il reste à décider du sort des dimensions que <abbr>SIS</abbr> avait temporairement exclues.
- Par défaut, <abbr>SIS</abbr> assignera la valeur <code>NaN</code> (<cite>Not-a-Number</cite>) à ces dimensions.
- Toutefois dans le cas particulier des hauteurs ellipsoïdales <var>h</var> dans une opération (<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>),
- la valeur zéro peut aussi être appropriée dans l’hypothèse où les coordonnées sont habituellement proches de la surface de l’ellipsoïde.
- Mais dans tous les cas, le choix du coefficient à mettre à 0 ou <code>NaN</code> est basé sur la présomption que la matrice représente une transformation affine.
- Ce n’est pas une opération qui peut être effectuée sur des matrices arbitraires.
- </p><p>
- Le traitement particulier décrit ci-haut permet à Apache <abbr>SIS</abbr> de résoudre
- certains systèmes d’équations sous-déterminés que l’on rencontre couramment dans les <abbr>SIG</abbr>.
- Dans notre exemple utilisant <code>NaN</code> comme valeur par défaut, la coordonnée <var>h</var> reste inconnue
- – nous ne faisons pas surgir de l’information du néant – mais au moins les coordonnées (<var>φ</var>, <var>λ</var>) ont pu être récupérées.
- Le problème inverse, celui des systèmes surdéterminés, est plus subtil.
- Une approche classique des bibliothèques d’algèbre linéaire est de résoudre les systèmes surdéterminés par la méthode des moindres carrées.
- Transposée à notre exemple, cette approche proposerait une conversion (<var>φ₂</var>, <var>λ₂</var>, <var>h</var>) → (<var>φ₁</var>, <var>λ₁</var>)
- qui semble le meilleur compromis pour diverses valeurs de <var>φ₂</var>, <var>λ₂</var> et <var>h</var>,
- tout en n’étant (sauf cas particuliers) une solution exacte pour personne.
- De plus, les éventuelles combinaisons linéaires entre ces trois variables sont délicates compte tenu de l’hétérogénéité des unités de mesures,
- avec par exemple les <var>h</var> en mètres et (<var>φ</var>, <var>λ</var>) en degrés.
- Apache <abbr>SIS</abbr> procède plutôt comme pour les systèmes sous-déterminés: en exigeant que certaines dimensions soient indépendantes des autres,
- faute de quoi la matrice sera considérée non-inversible.
- En conséquence dans le cas des systèmes surdéterminés <abbr>SIS</abbr> refusera d’effectuer certaines opérations que les bibliothèques d’algèbre linéaire auraient faite,
- mais en cas de succès les conversions obtenues seront garanties exactes (aux erreurs d’arrondissement prêts).
- </p>
-
- <h4 id="MatrixLibrarySummary">La bibliothèque matricielle de Apache <abbr>SIS</abbr></h4>
- <p>
- En résumé, les besoins qui ont amené Apache <abbr>SIS</abbr> à fournir ses propres fonctions de calculs matriciels sont:
- </p>
- <ul>
- <li>Structure légère pour les petites matrices, particulièrement celles de taille 3×3.</li>
- <li>Précision accrue avec l’arithmétique « double-double », quitte à sacrifier un peu de performance dans des endroits où elle n’est pas critique.</li>
- <li>Traitement particulier de l’inversion des matrices non-carrées pour des conversions de coordonnées.</li>
- </ul>
- <p>
- Cette bibliothèque est fournie dans le paquet <code>org.apache.sis.matrix</code> du module <code>sis-referencing</code>.
- </p>
</section>
</body>
</html>
Copied: sis/site/trunk/book/fr/annex/Tests.html (from r1794573, sis/site/trunk/book/fr/annexes.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/annex/Tests.html?p2=sis/site/trunk/book/fr/annex/Tests.html&p1=sis/site/trunk/book/fr/annexes.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/annexes.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/annex/Tests.html [UTF-8] Tue May 9 23:04:35 2017
@@ -20,199 +20,21 @@
under the License.
-->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"
- xmlns:xi = "http://www.w3.org/2001/XInclude">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
- <title>Annexes</title>
+ <title>Tests</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+ <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
</head>
<body>
<!--
- Content below this point is copied in "../../content/book/fr/developer-guide.html"
+ Content below this point is copied in "(…)/content/book/fr/developer-guide.html" file
by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
-->
<section>
<header>
- <h1 id="Annexes">Annexes</h1>
+ <h2 id="Tests">Les suites de tests</h2>
</header>
- <h2 id="ReduceDependency">Réduire la dépendance directe envers Apache SIS</h2>
- <p>
- Les chapitres précédents utilisaient des méthodes statiques de Apache SIS par commodité.
- Dans certains cas, il est possible de remplacer ces méthodes statiques par du code ne faisant appel qu’à des méthodes de GeoAPI.
- Ces remplacements peuvent être intéressants pour les applications qui souhaiteraient limiter les dépendances directes envers Apache SIS,
- par exemple afin de faciliter d’éventuelles migrations entre SIS et d’autres implémentations de GeoAPI.
- Mais cela peut amener ces applications à écrire leur propres méthodes de commodités.
- Les sections suivantes donnent quelques pistes pour faciliter cette tâche.
- </p>
-
- <h3 id="UML-annotation-indep">Correspondances entre GeoAPI et les spécifications abstraites</h3>
- <p>
- Pour chaque classe, méthode et constante définie à partir d’un standard <abbr>OGC</abbr> ou <abbr>ISO</abbr>,
- GeoAPI indique sa provenance à l’aide d’annotations définies dans le paquet <code>org.opengis.annotation</code>.
- Cette correspondante est décrite dans le <a href="#UML-annotation">chapitre à propos de GeoAPI</a>.
- Les méthodes d’introspections du Java permettent d’accéder à ces informations pendant l’exécution d’une application.
- La classe <code>org.apache.sis.util.iso.Types</code> fournit des méthodes de commodités telles que
- <code class="SIS">getStandardName(Class)</code> à cette fin, mais on peut éviter ces méthodes.
- L’exemple suivant affiche le nom standard de la méthode <code class="GeoAPI">getTitle()</code> de l’interface <code>Citation</code>:
- </p>
-
-<pre>Class<?> type = Citation.class;
-Method method = type.getMethod("<code class="GeoAPI">getTitle</code>", (Class<?>[]) null);
-UML annot = method.getAnnotation(UML.class);
-String id = annot.identifier();
-System.out.println("Le nom standard de la méthode " + method.getName() + " est " + id);</pre>
-
- <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>org.opengis.annotation</code>. L’exemple suivant lit ce fichier juste avant
- de rechercher le nom de l’interface correspondant à <code>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>
-
-<pre>Properties isoToGeoAPI = new Properties();
-try (InputStream in = UML.class.getResourceAsStream("<code class="GeoAPI">class-index.properties</code>")) {
- isoToGeoAPI.load(in);
-}
-String isoName = "<code class="OGC">CI_Citation</code>";
-String geoName = isoToGeoAPI.getProperty(isoName);
-Class<?> type = Class.forName(geoName);
-System.out.println("L’interface GeoAPI pour le type <abbr>ISO</abbr> " + isoName + " est " + type);</pre>
-
- <p>
- La méthode de commodité de <code>org.apache.sis.util.iso.Types</code> correspondante à cette operation est
- <code class="SIS">forStandardName(String)</code>.
- </p>
-
-
-
- <h3 id="ServiceLoader">Obtenir une implémentation des interfaces de GeoAPI</h3>
- <p>
- GeoAPI définit des fabriques (<code>Factory</code>) permettant de créer des implémentations de ses interfaces.
- Par exemple <code>DatumFactory</code> fournit des méthodes permettant de créer des instances
- implémentant les interfaces du paquet <code>org.opengis.referencing.datum</code>.
- Ces <code>Factory</code> doivent être implémentées par les bibliothèques géospatiales
- et déclarées comme <i>services</i> tel que défini par la classe standard <code>java.util.ServiceLoader</code>.
- La javadoc de <code>ServiceLoader</code> explique la façon de procéder.
- Mais pour résumer, les bibliothèques doivent créer dans le répertoire <code>META-INF/services/</code>
- un fichier dont le nom correspond au nom complet de l’interface de la fabrique
- (<code>org.opengis.referencing.datum.DatumFactory</code> dans l’exemple précédent).
- Ce fichier texte doit contenir sur une ligne le nom complet de la classe implémentant cette interface.
- Il peut s’agir d’une classe cachée aux yeux des utilisateurs, car ils n’ont pas besoin de connaître son existence.
- </p>
- <p>
- Si la bibliothèque a bien déclaré ses fabriques comme des services, alors
- les utilisateurs peuvent les obtenir en utilisant <code>ServiceLoader</code> comme dans l’exemple ci-dessous.
- Cet exemple ne prend que la première fabrique trouvée; s’il existe plusieurs fabriques,
- par exemple lorsque plusieurs bibliothèques cohabitent, alors le choix est laissé à l’utilisateur.
- </p>
-
-<pre>import org.opengis.referencing.GeodeticDatum;
-import org.opengis.referencing.DatumFactory;
-import java.util.ServiceLoader;
-
-public class MyApplication {
- public void createMyDatum() {
- ServiceLoader loader = ServiceLoader.load(DatumFactory.class);
- DatumFactory factory = loader.iterator().next();
- GeodeticDatum myDatum = factory.<code class="GeoAPI">createGeodeticDatum</code>(…);
- }
-}</pre>
-
-
-
- <h4 id="GeoAPI-simple">Fournir sa propre implémentation</h4>
- <p>
- Implémenter soi-même GeoAPI n’est pas si difficile si on se contente de besoins bien précis.
- Un développeur peut se concentrer sur une poignée d’interfaces parmi les centaines de disponibles,
- tout en disposant des autres interfaces comme autant de points d’extensions à éventuellement implémenter
- au gré des besoins.
- </p>
- <p>
- Le modèle conceptuel représenté par les interfaces est complexe. Mais cette complexité peut être réduite en combinant certaines interfaces.
- Par exemple plusieurs bibliothèques, même réputées, ne font pas la distinction entre <cite>Système de coordonnées</cite> (<abbr>CS</abbr>)
- et <cite>Système de <u>référence</u> des coordonnées</cite> (<abbr>CRS</abbr>).
- Un développeur qui lui non-plus ne souhaite pas faire cette distinction peut implémenter ces deux interfaces par la même classe.
- Il peut en résulter une implémentation dont la hiérarchie de classes est plus simple que la hiérarchie des interfaces de GeoAPI.
- Le module <code>geoapi-examples</code>, discuté plus loin, fournit de telles combinaisons.
- Le tableau suivant énumère quelques combinaisons possibles:
- </p>
- <table>
- <tr>
- <th>Interface principale</th>
- <th>Interface auxiliaire</th>
- <th>Usage</th>
- </tr>
- <tr>
- <td><code>CoordinateReferenceSystem</code></td>
- <td><code>CoordinateSystem</code></td>
- <td>Description d’un système de référence spatial (<abbr>CRS</abbr>).</td>
- </tr>
- <tr>
- <td><code>GeodeticDatum</code></td>
- <td><code>Ellipsoid</code></td>
- <td>Description d’un référentiel geodétique.</td>
- </tr>
- <tr>
- <td><code>CoordinateOperation</code></td>
- <td><code>MathTransform</code></td>
- <td>Opération de transformation de coordonnées.</td>
- </tr>
- <tr>
- <td><code>IdentifiedObject</code></td>
- <td><code>ReferenceIdentifier</code></td>
- <td>Objet (typiquement un <abbr>CRS</abbr>) que l’on peut identifier par un code.</td>
- </tr>
- <tr>
- <td><code>Citation</code></td>
- <td><code>InternationalString</code></td>
- <td>Référence bibliographique composée d’un simple titre.</td>
- </tr>
- <tr>
- <td><code>GeographicBoundingBox</code></td>
- <td><code>Extent</code></td>
- <td>Étendue spatiale en degrés de longitude et de latitude.</td>
- </tr>
- <tr>
- <td><code>ParameterValue</code></td>
- <td><code>ParameterDescriptor</code></td>
- <td>Description d’un paramètre (nom, type) associée à sa valeur.</td>
- </tr>
- <tr>
- <td><code>ParameterValueGroup</code></td>
- <td><code>ParameterDescriptorGroup</code></td>
- <td>Description d’un ensemble de paramètres associés à leurs valeurs.</td>
- </tr>
- </table>
- <p id="GeoAPI-examples">
- Le module <code>geoapi-examples</code> fournit des exemples d’implémentations simples.
- Plusieurs de ces classes implémentent plus d’une interface à la fois afin de proposer un modèle conceptuel plus simple.
- La <a href="http://www.geoapi.org/geoapi-examples/apidocs/overview-summary.html">Javadoc de ce module</a>
- énumère les paquets et classes clés avec les combinaisons effectuées.
- Ce module illustre non-seulement comment GeoAPI peut-être implémenté, mais aussi comment l’implémentation
- peut être testée en utilisant <code>geoapi-conformance</code>.
- </p>
- <p>
- Bien que sa mission première soit de servir d’inspiration aux implémenteurs,
- <code>geoapi-examples</code> a tout-de-même été conçu de manière à être utilisable
- par des applications ayant des besoins très simples. Tous les exemples étant dans le domaine publique,
- les développeurs sont invités à adapter librement des copies de ces classes si nécessaires.
- Toutefois si des modifications sont apportées hors du cadre du projet GeoAPI, le bon usage veut que les copies
- modifiées soient placées dans un paquet portant un autre nom que <code>org.opengis</code>.
- </p>
- <p>
- Pour des besoins un peu plus poussés, les développeurs sont invités à examiner les modules
- <code>geoapi-proj4</code> et <code>geoapi-netcdf</code>.
- Ces deux modules fournissent des exemples d’adaptateurs permettant d’utiliser, via les interfaces de GeoAPI,
- une partie des fonctionnalités de bibliothèques externes (Proj.4 et <abbr>NetCDF</abbr>).
- L’avantage de passer par ces interfaces est de disposer d’un modèle unifié pour exploiter deux <abbr>API</abbr> très différents,
- tout en se gardant la possibilité de basculer plus facilement à une autre bibliothèque si désiré.
- </p>
-
-
- <h2 id="Tests">Les suites de tests</h2>
<p>
En plus des tests propres au projet, Apache SIS utilise aussi des tests définis par GeoAPI.
Ces tests ont l’avantage d’utiliser une source externe définissant ce que doivent être les résultats
@@ -379,268 +201,6 @@ public class MyTest extends Parameterize
assertTrue(<code class="GeoAPI">transform</code> instanceof MathTransform2D);
}
}</pre>
-
-
-
- <h2 id="DesignNote">Notes de design</h2>
- <p>Les chapitres suivants expliquent les raisons derrières certains choix d'implémentation de Apache <abbr>SIS</abbr>.</p>
-
-
- <h3 id="AffineTransform">Utilisation des transformations affines</h3>
- <p>
- Parmi les sortes d’opérations qu’un <abbr>SIG</abbr> doit effectuer sur les coordonnées spatiales,
- les <cite>transformations affines</cite> sont à la fois relativement simples et très fréquentes.
- Les transformations affines peuvent représenter n’importe quelle combinaison d’échelles, de cisaillements,
- de retournements, de rotations ou de translations, qui sont toutes des <cite>opérations linéaires</cite>.
- Les transformations affines ne peuvent pas effectuer des opérations <cite>non-linéaires</cite>
- telles que les projections cartographiques, mais couvrent néanmoins de nombreux autres cas:
- </p>
- <ul>
- <li>Changer l’ordre des axes, par exemple de (<var>latitude</var>, <var>longitude</var>) vers (<var>longitude</var>, <var>latitude</var>).</li>
- <li>Changer la direction des axes, par exemple l’axe des <var>y</var> qui pointe habituellement vers le bas dans les images.</li>
- <li>Changer le méridien d’origine, par exemple du méridien de <cite>Paris</cite> vers celui de <cite>Greenwich</cite>.</li>
- <li>Changer le nombre de dimensions, par exemple passer des coordonnées 3D vers 2D en supprimant la hauteur.</li>
- <li>Convertir des unités de mesures, par exemple convertir des pieds en mètres.</li>
- <li>Convertir des coordonnées pixels en coordonnées géographiques,
- par exemple la conversion exprimée dans les fichiers <code>.tfw</code> qui accompagnent certaines images <abbr>TIFF</abbr>.</li>
- <li>Prendre en charge une petite partie des projections cartographiques,
- par exemple les paramètres <cite>False Easting</cite>, <cite>False Northing</cite> et <cite>Scale factor</cite>.</li>
- </ul>
- <p>
- Les transformations affines peuvent se combiner efficacement.
- Peu importe le nombre de transformations affines que l’on enchaîne, le résultat sera exprimable par une seule transformation affine.
- Cette propriété est plus facilement visible lorsque les transformations affines sont exprimées sous forme de matrices:
- pour combiner les opérations, il suffit de multiplier les matrices.
- Le cas des conversions des coordonnées pixels en coordonnées géographiques ci-dessous donne un exemple.
- </p>
-
- <div class="example">
- <p><b>Exemple:</b>
- supposons que nous disposons d’une image dont les coordonnées des pixels sont représentées par (<var>x</var>,<var>y</var>).
- Supposons aussi que les contraintes suivantes sont respectées:
- </p>
- <ul>
- <li>Il n’y a ni cisaillement, ni rotation, ni retournement de l’image.</li>
- <li>Tous les pixels ont la même largeur en degrés de longitude.</li>
- <li>Tous les pixels ont la même hauteur en degrés de latitude.</li>
- <li>Les coordonnées des pixels commencent à (0,0) inclusivement.</li>
- </ul>
- <p>Alors la conversion des coordonnées pixels (<var>x</var>,<var>y</var>)
- vers les coordonnées géographiques (<var>λ</var>,<var>φ</var>)
- peut être représentée par les équations suivantes,
- où <var>N</var><sub><var>x</var></sub> est la largeur
- et <var>N</var><sub><var>y</var></sub> la hauteur de l’image en nombre de pixels.
- </p><p>
- <xi:include href="../math/PixelToGeographicTerms.html"/>
- </p><p>
- Les équations ci-dessus peuvent être représentées sous forme de matrices comme ci-dessous:
- </p><p>
- <xi:include href="../math/PixelToGeographic.html"/>
- </p><p>
- Dans ce cas particulier, les facteurs d’échelles <var>S</var> correspondent à la taille des pixels en degrés
- et les termes de translations <var>T</var> correspondent aux coordonnées géographiques d’un coin de l’image
- (pas nécessairement le coin inférieur gauche si certains axes ont été retournés).
- Cette interprétation directe n’est possible que lorsque les contraintes énumérées plus haut sont respectées.
- Les coefficients des matrices deviennent plus complexes si l’image a un cisaillement ou une rotation,
- ou si les coordonnées des pixels ne commencent pas à (0,0).
- Toutefois il n’est pas nécessaire d’utiliser des équations plus complexes pour gérer des cas plus génériques.
- L’exemple ci-dessous prend comme point de départ la matrice d’une « conversion initiale »
- dans laquelle les coefficients <var>S</var> et <var>T</var> sont les valeurs relativement simples données ci-dessus.
- Ensuite la direction de l’axe des <var>y</var> est inversée de manière à correspondre
- à la convention habituelle des systèmes de coordonnées des images (changement 1),
- et les axes sont intervertis de manière à avoir la latitude avant la longitude (changement 2).
- Notez que les concaténations de transformations affines écrites sous forme de multiplications matricielles
- se lisent de droite à gauche:
- <var>A</var>×<var>B</var>×<var>C</var> est équivalent à d’abord appliquer l’opération <var>C</var>,
- suivit de l’opération <var>B</var> et finalement l’opération <var>A</var>.
- </p>
- <table class="hidden"><tr>
- <th>Changement 2</th><th></th>
- <th>Changement 1</th><th></th>
- <th>Conversion initiale</th><th></th>
- <th>Opérations combinées</th>
- </tr><tr>
- <td style="vertical-align: middle"><xi:include href="../math/AxisSwapping2D.html"/></td>
- <td style="vertical-align: middle; padding-left: 15px; padding-right: 15px">×</td>
- <td style="vertical-align: middle"><xi:include href="../math/InverseAxisY.html"/></td>
- <td style="vertical-align: middle; padding-left: 15px; padding-right: 15px">×</td>
- <td style="vertical-align: middle"><xi:include href="../math/PixelToGeographicSameAxisDirections.html"/></td>
- <td style="vertical-align: middle; padding-left: 15px; padding-right: 15px">=</td>
- <td style="vertical-align: middle"><xi:include href="../math/PixelToGeographicReverseOrderAndY.html"/></td>
- </tr></table>
- <p>
- Un principe clé est qu’il n’y a pas besoin d’écrire un code dédié à ce type d’opérations sur les axes.
- Ces opérations, et bien d’autres, sont prises en compte naturellement par l’algèbre matricielle.
- On y gagne en généricité du code et en performance.
- Apache <abbr>SIS</abbr> suit ce principe en utilisant les tranformations affine pour toutes les opérations
- où elles peuvent s’appliquer.
- Il n’y a par exemple aucun code dédié au changement de l’ordre des ordonnées dans une coordonnée.
- </p>
- </div>
-
- <h4 id="AffineTransformAPI">Intégration avec les bibliothèques graphiques</h4>
- <p>
- A peu près toutes les bibliothèques graphiques supportent une forme de transformation de coordonnées,
- souvent les <cite>transformations affines</cite> ou une légère généralisation.
- Chaque bibliothèque défini son propre <abbr>API</abbr>.
- Quelques exemples sont:
- </p>
- <table>
- <caption>Implémentations des transformations affines dans des bibliothèques graphiques</caption>
- <tr><th>Bibliothèque</th> <th>Implementation de la transformation</th> <th>Dimensions</th></tr>
- <tr><td>Java2D</td> <td><code>java.awt.geom.AffineTransform</code></td> <td>2</td></tr>
- <tr><td>Java3D</td> <td><code>javax.media.j3d.Transform3D</code></td> <td>3</td></tr>
- <tr><td>JavaFX</td> <td><code>javafx.scene.transform.Affine</code></td> <td>2 ou 3</td></tr>
- <tr><td>Java Advanced Imaging (<abbr>JAI</abbr>)</td> <td><code>javax.media.jai.PerspectiveTransform</code></td> <td>2</td></tr>
- <tr><td>Android</td> <td><code>android.graphics.Matrix</code></td> <td>2</td></tr>
- </table>
- <p>
- Toutefois dans plusieurs cas, les transformations affines sont les seuls types d’opérations supportées par la bibliothèque graphique.
- Apache <abbr>SIS</abbr> a besoin de gérer un plus grand nombre de type d’opérations,
- parmi lesquelles les transformations affines ne sont que des cas particuliers.
- Les projections cartographiques et les changements de référentiels notamment,
- ne peuvent pas être représentés par des transformations affines.
- <abbr>SIS</abbr> a aussi besoin de transformer des points ayant un nombre arbitraire de dimensions,
- alors que les <abbr>API</abbr> cités ci-haut restreignent leur usage à un nombre fixe de dimensions.
- Pour ces raisons, <abbr>SIS</abbr> ne peut pas utiliser directement ces <abbr>API</abbr>.
- <abbr>SIS</abbr> utilise plutôt une interface plus abstraite, <code>org.opengis.referencing.transform.MathTransform</code>.
- Mais dans le cas particulier où la transformation est réellement affine, <abbr>SIS</abbr> peut essayer d’utiliser
- une implémentation existante, surtout Java2D.
- Par exemple le code suivant peut être utilisé dans les situations où un objet Java2D est désiré:
- </p>
-
-<pre>MathTransform mt = ...; // N’importe quelle instance créée par Apache SIS.
-if (mt instanceof AffineTransform) {
- AffineTransform at = (AffineTransform) mt;
- // Utiliser l’API de Java2D API à partir d’ici.
-}</pre>
-
- <p>
- Toutefois <abbr>SIS</abbr> n’utilisera Java2D que sur une base opportuniste.
- Le forçage de type ci-haut n’est pas garantit de réussir, même si l’instance de
- <code>MathTransform</code> répond aux conditions qui devrait permettre un usage de Java2D.
- </p>
-
-
- <h3 id="MatrixLibrary">Particularités d’une bibliothèque de calculs matriciels pour un <abbr>SIG</abbr></h3>
- <p>
- Les <abbr>SIG</abbr> font un usage intensif de matrices afin d’afficher leurs cartes ou transformer des coordonnées.
- On pourrait croire que le marché est suffisamment bien pourvu en excellentes bibliothèques de calculs matriciels, libres ou commerciales.
- Pourtant, les <abbr>SIG</abbr> ont des besoins spécifiques qui divergent un peu des objectifs de plusieurs bibliothèques existantes.
- Des manipulations de matrices comme celles décrites dans <a href="#AffineTransform">le chapitre sur les transformations affines</a>
- interviennent dans quasiment toutes les opérations appliquées par Apache <abbr>SIS</abbr> sur des coordonnées.
- Mais l’analyse de ces opérations révèle quelques patterns:
- </p>
- <ul>
- <li><p>Ces matrices sont presque toujours de petites tailles, dépassant rarement 5 lignes par 5 colonnes.</p></li>
- <li><p>Les opérations matricielles « lourdes » (multiplications ou inversions de matrices) ne surviennent pas dans des endroits où la performance est importante.
- Dans la quasi-totalité des cas, elles ne sont effectuées qu’une fois pour toute, à la lecture d’un fichier,
- ou lors des étapes de préparation avant de convertir des coordonnées.
- Elles ne surviennent quasiment jamais dans la boucle convertissant chacune des coordonnées.</p></li>
- <li><p>Dans une succession de multiplications et d’inversions de matrices, les erreurs d’arrondissement s’accumulent et grandissent rapidement
- au point de se confondre avec certaines opérations légitimes, notamment les changements de référentiel.
- Ces dernières s’expriment souvent par un changement de la taille, position et orientation de l’ellipsoïde
- choisi comme approximation de la forme de la Terre.
- Or ces changements de taille s’expriment en parties par million et les rotations en arc-secondes.
- Retranscrites dans une matrice, ces valeurs sont donc assez petites.</p></li>
- <li><p>Il arrive fréquemment que des matrices s’annulent en tout ou en partie lorsqu’elles sont combinées,
- c’est-à-dire que leurs multiplications ramènent des facteurs d’échelles à 1 et des translations à 0.
- Toutefois les erreurs d’arrondissements font que les valeurs obtenues sont rarement exactes,
- mais plutôt des valeurs s’en rapprochant telles que 0,9999…97 à la place de 1.
- L’approche habituelle pour contourner ce problème est d’effectuer les comparaisons de nombres à virgule flottante en tolérant un léger écart.
- Mais il est difficile de choisir un seuil de tolérance qui gommera la plupart des erreurs d’arrondissement
- sans considérer à tord un changement de référentiel comme un artefact (voir point précédent).</p></li>
- </ul>
- <p>
- Ces points font que, pour un <abbr>SIG</abbr> comme Apache <abbr>SIS</abbr>, la précision d’une bibliothèque de calculs matriciels
- est plus importante que la performance. Paradoxalement, un bon moyen de gagner en performance est justement d’investir davantage de temps de CPU
- pour effectuer des opérations matricielles plus précises dans la phase de <em>préparation</em> (non d’<em>exécution</em>) de la transformation de coordonnées,
- car on augmente ainsi les chances de détecter correctement quelles opérations s’annulent.
- L’effort investit dans cette détection permet de sauver du temps là où ça compte: quand viendra le moment de boucler sur des millions de coordonnées à transformer.
- </p><p>
- Mais les bibliothèques dédiées aux calculs matriciels sont souvent conçues pour opérer de manière très performante
- sur des matrices de grandes tailles, ayant par exemple des milliers de lignes et colonnes.
- Elles sont ainsi conçues pour être capable de résoudre efficacement des systèmes d’équations linéaires comportant des centaines d’inconnues.
- Les problèmes qu’elles résolvent sont certes difficiles, mais assez différents de ceux qui intéressent Apache <abbr>SIS</abbr>.
- Pour cette raison, et aussi à cause d’un autre besoin spécifique détaillé dans les paragraphes suivants,
- Apache <abbr>SIS</abbr> utilise ses propres fonctions de calculs matriciels.
- Ces fonctions tentent de résoudre le problème de précision en utilisant l’arithmétique « double-double »
- (une technique permettant de simuler une précision d’environ 120 bits)
- au prix de la performance pendant une étape (la <em>préparation</em> de la transformation) où elle n’est pas jugée critique.
- </p>
-
- <h4 id="NonSquareMatrix">Que faire des matrices qui ne sont pas carrées (et pourquoi)</h4>
- <p>
- Apache <abbr>SIS</abbr> a très souvent besoin d’inverser des matrices,
- afin d’obtenir une conversion de coordonnées dans la direction inverse de la conversion originale.
- Mais on n’inverse habituellement que des matrices carrées.
- Or, <abbr>SIS</abbr> a besoin d’effectuer des inversions de matrices non-carrées.
- Selon que l’on ait plus de lignes ou plus de colonnes:
- </p>
- <ul>
- <li>Pour <abbr>SIS</abbr>, une matrice non-carrée est une conversion qui ajoute ou supprime une dimension aux coordonnées.</li>
- <li>Pour les bibliothèques d’algèbre linéaire, une matrice non-carrée est un système d’équations sous-déterminé ou surdéterminé.</li>
- </ul>
- <p>
- Pour mieux comprendre les difficultés que causerait une transposition trop directe des bibliothèques d’algèbre linéaire aux <abbr>SIG</abbr>,
- imaginons une conversion (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>) → (<var>φ₂</var>, <var>λ₂</var>)
- qui projetterait les points d’un espace 3D vers une surface 2D.
- Les termes <var>φ</var> sont des latitudes, <var>λ</var> des longitudes et
- (<var>φ₂</var>, <var>λ₂</var>) n’égale pas forcement (<var>φ₁</var>, <var>λ₁</var>) si la hauteur <var>h</var> n’est pas perpendiculaire à la surface.
- </p><p>
- <xi:include href="../math/Geographic3Dto2D.html"/>
- </p><p>
- Pour des bibliothèques d’algèbre linéaire, la matrice ci-dessus représente un système d’équations sous-déterminé, et donc insoluble.
- C’est-à-dire qu’on ne peut pas inverser cette conversion pour obtenir (<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>)
- puisqu’on ne sait pas quelle valeur donner à <var>h</var>,
- ce qui implique qu’on ne peut pas trouver (<var>φ₁</var>, <var>λ₁</var>) non-plus car ces valeurs dépendent peut-être de <var>h</var>.
- Toutefois dans le cas des <abbr>SIG</abbr>, l’axe des hauteurs ellipsoïdales <var>h</var> est perpendiculaire à la surface de l’ellipsoïde
- sur laquelle les latitudes et longitudes <em>géodésiques</em> (<var>φ</var>, <var>λ</var>) sont représentées
- (notez que cette affirmation ne s’applique pas aux latitudes et longitudes <em>géocentriques</em>).
- Cette perpendicularité rend <var>φ₁</var> et <var>λ₁</var> indépendants de <var>h</var>.
- Dans ce genre de cas, on peut encore sauver les meubles.
- </p><p>
- Apache <abbr>SIS</abbr> procède en vérifiant si les valeurs de <var>h</var> sont indépendantes des valeurs de <var>φ</var> et <var>λ</var>.
- Nous reconnaissons ce cas en vérifiant quels coefficients de la matrice ont la valeur zéro.
- Si <abbr>SIS</abbr> arrive à identifier des dimensions indépendantes,
- il peut les exclure temporairement de manière à inverser sans ambiguïté la conversion dans les dimensions restantes.
- S’il ne trouve pas de dimension indépendante, alors une exception est levée.
- Mais si une inversion a été possible, alors il reste à décider du sort des dimensions que <abbr>SIS</abbr> avait temporairement exclues.
- Par défaut, <abbr>SIS</abbr> assignera la valeur <code>NaN</code> (<cite>Not-a-Number</cite>) à ces dimensions.
- Toutefois dans le cas particulier des hauteurs ellipsoïdales <var>h</var> dans une opération (<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>),
- la valeur zéro peut aussi être appropriée dans l’hypothèse où les coordonnées sont habituellement proches de la surface de l’ellipsoïde.
- Mais dans tous les cas, le choix du coefficient à mettre à 0 ou <code>NaN</code> est basé sur la présomption que la matrice représente une transformation affine.
- Ce n’est pas une opération qui peut être effectuée sur des matrices arbitraires.
- </p><p>
- Le traitement particulier décrit ci-haut permet à Apache <abbr>SIS</abbr> de résoudre
- certains systèmes d’équations sous-déterminés que l’on rencontre couramment dans les <abbr>SIG</abbr>.
- Dans notre exemple utilisant <code>NaN</code> comme valeur par défaut, la coordonnée <var>h</var> reste inconnue
- – nous ne faisons pas surgir de l’information du néant – mais au moins les coordonnées (<var>φ</var>, <var>λ</var>) ont pu être récupérées.
- Le problème inverse, celui des systèmes surdéterminés, est plus subtil.
- Une approche classique des bibliothèques d’algèbre linéaire est de résoudre les systèmes surdéterminés par la méthode des moindres carrées.
- Transposée à notre exemple, cette approche proposerait une conversion (<var>φ₂</var>, <var>λ₂</var>, <var>h</var>) → (<var>φ₁</var>, <var>λ₁</var>)
- qui semble le meilleur compromis pour diverses valeurs de <var>φ₂</var>, <var>λ₂</var> et <var>h</var>,
- tout en n’étant (sauf cas particuliers) une solution exacte pour personne.
- De plus, les éventuelles combinaisons linéaires entre ces trois variables sont délicates compte tenu de l’hétérogénéité des unités de mesures,
- avec par exemple les <var>h</var> en mètres et (<var>φ</var>, <var>λ</var>) en degrés.
- Apache <abbr>SIS</abbr> procède plutôt comme pour les systèmes sous-déterminés: en exigeant que certaines dimensions soient indépendantes des autres,
- faute de quoi la matrice sera considérée non-inversible.
- En conséquence dans le cas des systèmes surdéterminés <abbr>SIS</abbr> refusera d’effectuer certaines opérations que les bibliothèques d’algèbre linéaire auraient faite,
- mais en cas de succès les conversions obtenues seront garanties exactes (aux erreurs d’arrondissement prêts).
- </p>
-
- <h4 id="MatrixLibrarySummary">La bibliothèque matricielle de Apache <abbr>SIS</abbr></h4>
- <p>
- En résumé, les besoins qui ont amené Apache <abbr>SIS</abbr> à fournir ses propres fonctions de calculs matriciels sont:
- </p>
- <ul>
- <li>Structure légère pour les petites matrices, particulièrement celles de taille 3×3.</li>
- <li>Précision accrue avec l’arithmétique « double-double », quitte à sacrifier un peu de performance dans des endroits où elle n’est pas critique.</li>
- <li>Traitement particulier de l’inversion des matrices non-carrées pour des conversions de coordonnées.</li>
- </ul>
- <p>
- Cette bibliothèque est fournie dans le paquet <code>org.apache.sis.matrix</code> du module <code>sis-referencing</code>.
- </p>
</section>
</body>
</html>
Copied: sis/site/trunk/book/fr/coverage/Coverage.html (from r1794655, sis/site/trunk/book/fr/coverage.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/coverage/Coverage.html?p2=sis/site/trunk/book/fr/coverage/Coverage.html&p1=sis/site/trunk/book/fr/coverage.html&r1=1794655&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/coverage.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/coverage/Coverage.html [UTF-8] Tue May 9 23:04:35 2017
@@ -24,11 +24,11 @@
<head>
<title>Couvertures de données (Coverages)</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+ <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
</head>
<body>
<!--
- Content below this point is copied in "../../content/book/fr/developer-guide.html"
+ Content below this point is copied in "(…)/content/book/fr/developer-guide.html" file
by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
-->
<section>
Copied: sis/site/trunk/book/fr/geometry/Geometry.html (from r1794573, sis/site/trunk/book/fr/geometry.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/geometry/Geometry.html?p2=sis/site/trunk/book/fr/geometry/Geometry.html&p1=sis/site/trunk/book/fr/geometry.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/geometry.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/geometry/Geometry.html [UTF-8] Tue May 9 23:04:35 2017
@@ -20,11 +20,11 @@
under the License.
-->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
+<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="fr">
<head>
- <title>Géométries</title>
+ <title>Geometry</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+ <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
</head>
<body>
<!--
@@ -40,175 +40,7 @@
et les classes de Apache <abbr>SIS</abbr> qui les implémentent.
</p>
-
-
- <h2 id="Geometry-root">Classes de base</h2>
- <p>
- Chaque objet géométrique est considéré comme un ensemble infini de points.
- En tant qu’ensemble, leurs opérations les plus fondamentales sont de même nature que les opérations standards des collections du Java.
- On pourrait donc voir une géométrie comme une sorte de <code>java.util.Set</code> dont les éléments seraient des points,
- à ceci près que le nombre d’éléments contenus dans cet ensemble est infini (à l’exception des géométries représentant un simple point).
- Pour mieux représenter ce concept, la norme <abbr>ISO</abbr> et GeoAPI définissent une interface <code class="OGC">TransfiniteSet</code>
- que l’on peut voir comme un <code>Set</code> de taille infini. Bien qu’un lien de parenté existe conceptuellement entre ces interfaces,
- GeoAPI ne définit pas <code class="GeoAPI">TransfiniteSet</code> comme une sous-interface de <code>java.util.Set</code>
- car la définition de certaines méthodes telles que <code>size()</code> et <code>iterator()</code> serait problématique.
- On y retrouve toutefois des méthodes très similaires telles que <code class="GeoAPI">contains(…)</code> et <code class="GeoAPI">intersects(…)</code>.
- </p>
- <p>
- Toutes les géométries sont des spécialisations de <code>TransfiniteSet</code>.
- La classe parente de toutes ces géométries est appelée <code>GM_Object</code> dans la norme <abbr>ISO</abbr> 19107.
- Les interfaces de GeoAPI utilisent plutôt le nom <code>Geometry</code>, car l’omission du préfixe <code class="OGC">GM_</code>
- (comme le veut la convention dans GeoAPI) aurait laissé un nom trop proche de la classe <code>Object</code> du Java.
- </p>
-
-
-
- <h3 id="DirectPosition">Points et positions directes</h3>
- <p>
- <abbr>ISO</abbr> 19107 définit deux types de structures pour représenter un point:
- <code>GM_Point</code> et <code class="OGC">DirectPosition</code>.
- Le premier type est une véritable géométrie et peut donc être relativement lourd, selon les implémentations.
- Le second type n’est pas considéré formellement comme une géométrie;
- il n’étend ni <code>GM_Object</code> ni <code class="OGC">TransfiniteSet</code>.
- Il ne définit pratiquement pas d’opérations autres que le stockage d’une séquence de nombres représentant une coordonnée.
- Il peut donc être un objet plus léger.
- </p>
- <p>
- Afin de permettre à l’<abbr>API</abbr> de travailler indifféremment avec ces deux types de positions,
- <abbr>ISO</abbr> 19107 définit <code class="OGC">Position</code> comme une <cite>union</cite> de
- <code class="OGC">DirectPosition</code> et <code>GM_Point</code>.
- Il s’agit d’une union au sens du C/C++. Pour le langage Java, GeoAPI obtient le même effet en définissant
- <code>Position</code> comme l’interface parente de <code>DirectPosition</code> et <code>Point</code>.
- Dans la pratique, la grande majorité des <abbr>API</abbr> de Apache <abbr>SIS</abbr> travaillent sur des <code>DirectPosition</code>,
- ou occasionnellement des <code>Position</code> quand il semble utile d’autoriser aussi des points géométriques.
- </p>
-
-
-
- <h3 id="Envelope">Enveloppes</h3>
- <p>
- Les enveloppes stockent les valeurs minimales et maximales des coordonnées d’une géométrie.
- Les enveloppes <em>ne sont pas</em> elles-mêmes des géométries; ce ne sont pas des ensembles
- infinis de points (<code class="OGC">TransfiniteSet</code>). Il n’y a aucune garantie
- que toutes les positions contenues dans les limites d’une enveloppe soient géographiquement valides.
- Il faut voir les enveloppes comme une information sur les valeurs extrêmes que peuvent prendre les
- coordonnées d’une géométrie en faisant comme si chaque dimension était indépendante des autres,
- rien de plus. Nous assimilons néanmoins les enveloppes à des rectangles, cubes ou hyper-cubes
- (selon le nombre de dimensions) afin de faciliter la discussion, mais en gardant à l’esprit leur
- nature non-géométrique.
- </p>
- <div class="example"><p><b>Exemple:</b>
- Nous pouvons tester si une position est à l’intérieur des limites de l’enveloppe.
- Un résultat positif ne garantie pas que la position est à l’intérieur de la géométrie délimitée par l’enveloppe,
- mais un résultat négatif garantie qu’elle est à l’extérieur. De même on peut effectuer des tests d’intersections.
- En revanche appliquer une rotation n’a pas beaucoup de sens pour une enveloppe, car le résultat peut être très différent
- de celui que nous aurions obtenu en effectuant une rotation de la géométrie originale, puis en recalculant son enveloppe.
- </p></div>
- <p>
- Une enveloppe peut être représentée par deux positions correspondant à deux coins opposés
- d’un rectangle, cube ou hyper-cube. On prend souvent comme premier coin celui dont toutes
- les ordonnées ont la valeur minimale (<code class="OGC">lowerCorner</code>), et comme second
- coin celui dont toutes les ordonnées ont la valeur maximale (<code class="OGC">upperCorner</code>).
- Lors d’un affichage utilisant un système de coordonnées classique (valeurs de l’axe des <var>y</var> augmentant vers le haut),
- ces deux positions apparaissent respectivement dans le coin inférieur gauche et dans le coin supérieur droit d’un rectangle.
- Attention toutefois aux différents systèmes de coordonnées, qui peuvent faire varier les positions de ces coins à l’écran.
- Les expressions <i>lower corner</i> et <i>upper corner</i>
- doivent être comprises au sens mathématique plutôt que visuel.
- </p>
-
-
-
- <h4 id="AntiMeridian">Enveloppes traversant l’antiméridien</h4>
- <p>
- Les minimums et maximums sont les valeurs les plus souvent assignées aux <code class="OGC">lowerCorner</code>
- et <code class="OGC">upperCorner</code>. Mais les choses se compliquent dans le cas d’une enveloppe traversant
- l’antiméridien (-180° ou 180° de longitude). Par exemple, une enveloppe de 10° de largeur peut commencer à 175° de longitude et
- se terminer à -175°. Dans ce cas, la valeur de longitude assignée au <code class="OGC">lowerCorner</code> est
- supérieure à celle qui est assignée à l’<code class="OGC">upperCorner</code>.
- Apache <abbr>SIS</abbr> emploie donc une définition légèrement différente de ces deux coins:
- </p>
- <ul>
- <li><b><code class="SIS">lowerCorner</code>:</b>
- le point de départ lorsque l’on parcourt l’intérieur de l’enveloppe dans la direction des valeurs croissantes.
- </li>
- <li><b><code class="SIS">upperCorner</code>:</b>
- le point d’arrivé lorsque l’on a parcouru l’intérieur de l’enveloppe dans la direction des valeurs croissantes.
- </li>
- </ul>
- <p>
- Lorsque l’enveloppe ne traverse par l’antiméridien, ces deux définitions sont équivalentes à la sélection
- des valeurs minimales et maximales respectivement. C’est le cas du rectangle vert dans la figure ci-dessous.
- Lorsque l’enveloppe traverse l’antiméridien, les coins <code class="SIS">lowerCorner</code>
- et <code class="SIS">upperCorner</code> apparaissent encore en bas et en haut du rectangle
- (en supposant un système de coordonnées classique), donc leurs noms restent appropriés d’un point de vue visuel.
- Mais les positions gauche et droite sont interchangées.
- Ce cas est représenté par le rectangle rouge dans la figure ci-dessous.
- </p>
- <p style="text-align:center">
- <img src="../../apidocs/org/apache/sis/geometry/doc-files/AntiMeridian.png"
- alt="Exemples d’enveloppes avec et sans croisement de l’antiméridien."/>
- </p>
- <p>
- Les notions d’inclusion et d’intersection s’interprètent toutefois de manière légèrement différente dans ces deux cas.
- Dans le cas habituel où l’on ne traverse pas l’antiméridien, le rectangle vert délimite bien une région d’inclusion.
- Les régions exclues de ce rectangle se propagent à l’infini dans toutes les directions.
- En d’autres mots, la région d’inclusion n’est pas répétée tous les 360°.
- Mais dans le cas du rectangle rouge, l’information fournie par l’enveloppe délimite plutôt la région d’exclusion qui
- se trouve entre les deux bords du rectangle. La région d’inclusion se propage à l’infini des côtés gauche et droit.
- Nous pourrions stipuler que toute longitude inférieure à -180° ou supérieure à 180° est considérée exclue,
- mais ça serait une décision arbitraire qui ne serait pas un reflet symétrique du cas habituel (rectangle vert).
- Un développeur pourrait vouloir utiliser ces valeurs, par exemple dans une mosaïque où la carte du monde
- est répétée plusieurs fois horizontalement tout en considérant chaque répétition comme distincte des autres.
- Si un développeur souhaite effectuer des opérations comme si les régions d’inclusions ou d’exclusions étaient
- répétées tous les 360°, alors il doit lui-même ramener ses valeurs de longitudes entre -180° et 180° au préalable.
- Toutes les fonctions <code class="SIS">add(…)</code>, <code class="SIS">contains(…)</code>,
- <code class="SIS">intersect(…)</code>, <i>etc.</i> de toutes les enveloppes
- définies dans le paquet <code>org.apache.sis.geometry</code> effectuent leurs calculs selon cette convention.
- </p>
- <aside>
- <h5>Généralisation à d’autres types d’axes</h5>
- <p>
- Cette section nomme spécifiquement la longitude car il constitue le cas le plus courant d’axe cyclique.
- Mais dans les enveloppes de Apache <abbr>SIS</abbr>, il n’est fait nul part mention explicite du cas de la longitude, ni de son cycle de 360°.
- Les caractéristiques de la plage de valeurs de chaque axe (ses extremums, unités, type de cycle, <i>etc.</i>)
- sont des attributs des objets <code>CoordinateSystemAxis</code>, indirectement associés aux enveloppes via le système de référence des coordonnées.
- Apache <abbr>SIS</abbr> inspecte ces attributs pour déterminer de quelle façon il doit effectuer ses opérations.
- Ainsi, tout axe associé au code <code>RangeMeaning.WRAPAROUND</code> bénéficiera du même traitement que la longitude.
- Cela pourrait être par exemple un axe du temps dans des données climatologiques
- (une “année” représentant la température moyenne de tous les mois de janvier, suivit de la moyenne de tous les mois de février,
- <i>etc.</i>).
- Cette généralisation s’applique aussi aux axes de longitudes définis par une plage de 0° à 360° plutôt que de -180° à 180°.
- </p>
- </aside>
- <p>
- Pour que les fonctions telles que <code class="SIS">add(…)</code> fonctionnent correctement,
- tous les objets impliqués doivent utiliser le même système de référence des coordonnées, y compris
- la même plage de valeurs. Ainsi, une enveloppe exprimant les longitudes dans la plage [-180 … +180]°
- n’est pas compatible avec une enveloppe exprimant les longitudes dans la plage [0 … 360]°.
- Les conversions, si nécessaires, sont à la charge de l’utilisateur
- (la classe <code>Envelopes</code> fournit des méthodes de commodités pour ce faire).
- En outre, les coordonnées de l’enveloppe doivent être comprises dans les limites du système de coordonnées,
- sauf si le développeur souhaite volontairement considérer (par exemple) 300° de longitude
- comme un position distincte de -60°. La classe <code>GeneralEnvelope</code>
- fournit une méthode <code class="SIS">normalize()</code> pour ramener les coordonnées
- dans les limites attendues, au prix parfois de valeurs <cite><i>lower</i></cite>
- supérieures à la valeur <cite><i>upper</i></cite>.
- </p>
- <aside>
- <h5>Le cas particulier de la plage [+0 … -0]</h5>
- <p>
- le Java (ou de manière plus générale, la norme IEEE 754) définit deux valeurs distinctes de zéro:
- un zéro positif et un zéro négatif. Ces deux valeurs sont considérées égales lorsqu’on les compares avec l’opérateur <code>==</code> du Java.
- Mais dans les enveloppes de <abbr>SIS</abbr>, ils peuvent mener à des résultats opposés pour les axes ayant <code>RangeMeaning.WRAPAROUND</code>.
- Une enveloppe dont la plage est [0 … 0], [-0 … -0] ou [-0 … +0] sera bien considérée comme une enveloppe vide,
- mais la page [+0 … -0] sera au contraire considérée comme incluant la totalité des valeurs, jusqu’à l’infini.
- Ce comportement est conforme à la définition de <code class="SIS">lowerCorner</code> et <code class="SIS">upperCorner</code>
- qui considère +0 comme le point de départ, et -0 comme le point d’arrivé après avoir fait le tour des valeurs possibles.
- Un tel comportement ne se produit que pour la paire de valeurs +0 et -0, et seulement dans cet ordre.
- Pour toutes les autres valeurs réelles, si la condition <code>lower</code> <code>==</code> <code>upper</code>
- est vrai, alors il est garanti que l’enveloppe est vide.
- </p>
- </aside>
+ <xi:include href="GeometryBase.html"/>
</section>
</body>
</html>
Copied: sis/site/trunk/book/fr/geometry/GeometryBase.html (from r1794655, sis/site/trunk/book/fr/geometry.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/geometry/GeometryBase.html?p2=sis/site/trunk/book/fr/geometry/GeometryBase.html&p1=sis/site/trunk/book/fr/geometry.html&r1=1794655&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/geometry.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/geometry/GeometryBase.html [UTF-8] Tue May 9 23:04:35 2017
@@ -22,9 +22,9 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
- <title>Géométries</title>
+ <title>GeometryBase</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+ <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
</head>
<body>
<!--
@@ -33,17 +33,9 @@
-->
<section>
<header>
- <h1 id="Geometry">Géométries</h1>
+ <h2 id="GeometryBase">Classes de base</h2>
</header>
<p>
- Ce chapitre introduit quelques aspects de la norme <abbr>ISO</abbr> 19107 (<i>Spatial schema</i>)
- et les classes de Apache <abbr>SIS</abbr> qui les implémentent.
- </p>
-
-
-
- <h2 id="Geometry-root">Classes de base</h2>
- <p>
Chaque objet géométrique est considéré comme un ensemble infini de points.
En tant qu’ensemble, leurs opérations les plus fondamentales sont de même nature que les opérations standards des collections du Java.
On pourrait donc voir une géométrie comme une sorte de <code>java.util.Set</code> dont les éléments seraient des points,
Modified: sis/site/trunk/book/fr/index.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/index.html?rev=1794656&r1=1794655&r2=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/index.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/index.html [UTF-8] Tue May 9 23:04:35 2017
@@ -22,12 +22,12 @@
<html xmlns = "http://www.w3.org/1999/xhtml"
xmlns:xi = "http://www.w3.org/2001/XInclude"
- xml:lang = "en">
+ xml:lang = "fr">
<head>
<title>Introduction à Apache SIS</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+ <link rel="stylesheet" type="text/css" href="../book.css"/>
</head>
<body>
<p style="margin-top: 30pt"><span style="font-size: 30pt; font-weight: 900">Introduction à Apache SIS®</span></p>
@@ -43,13 +43,13 @@
</nav>
<main>
- <xi:include href="introduction.html"/>
- <xi:include href="referencing.html"/>
- <xi:include href="geometry.html"/>
- <xi:include href="coverage.html"/>
- <xi:include href="utility.html"/>
- <xi:include href="xml.html"/>
- <xi:include href="annexes.html"/>
+ <xi:include href="introduction/Standards.html"/>
+ <xi:include href="referencing/Referencing.html"/>
+ <xi:include href="Geometry/geometry.html"/>
+ <xi:include href="Coverage/coverage.html"/>
+ <xi:include href="utility/Utilities.html"/>
+ <xi:include href="xml/XML-ISO.html"/>
+ <xi:include href="annex/Annexes.html"/>
</main>
</body>
</html>