sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1762098 - in /sis/site/trunk: book/en/referencing.html book/fr/referencing.html content/book/book.css
Date Fri, 23 Sep 2016 22:41:58 GMT
Author: desruisseaux
Date: Fri Sep 23 22:41:58 2016
New Revision: 1762098

URL: http://svn.apache.org/viewvc?rev=1762098&view=rev
Log:
Reorganize parts of the referencing section in the developer guide, and translate part of the text about derivative.

Modified:
    sis/site/trunk/book/en/referencing.html
    sis/site/trunk/book/fr/referencing.html
    sis/site/trunk/content/book/book.css

Modified: sis/site/trunk/book/en/referencing.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/referencing.html?rev=1762098&r1=1762097&r2=1762098&view=diff
==============================================================================
--- sis/site/trunk/book/en/referencing.html (original)
+++ sis/site/trunk/book/en/referencing.html Fri Sep 23 22:41:58 2016
@@ -34,53 +34,95 @@
     <p>
       For locating a point on Earth one can use identifiers like city name or postal address
       — an approach known as <cite>spatial reference systems by identifiers</cite> —
-      or use numerical values valid in a given coordinate system
+      or use numerical values valid in a given coordinate system like latitudes and longitudes
       — an approach known as <cite>spatial reference systems by coordinates</cite>.
-      Each system implies approximations as:
-    </p>
-    <ul>
-      <li>Choice of a figure of the Earth (geoid, ellipsoid, <i>etc.</i>) used as an approximation of Earth shape.</li>
-      <li>Choice of geometric properties (angles, distances, <i>etc.</i>) to be preserved when a map is shown on plane surface.</li>
-      <li>Lost of precision when a coordinates is transformed from one referencing system to another system.</li>
-    </ul>
-    <p>
-      Unless otherwise specified, Apache SIS aims to represent coordinates on Earth with an accuracy of one centimetre or better.
+      Each reference system implies approximations like
+      the choice of a figure of the Earth (geoid, ellipsoid, <i>etc.</i>) used as an approximation of Earth shape,
+      the choice of geometric properties (angles, distances, <i>etc.</i>) to be preserved when a map is shown on plane surface, and
+      a lost of precision when coordinates are transformed to systems using a different <a href="#GeodeticDatum">datum</a>.
+    </p><p>
+      A very common misbelief is that one can avoid this complexity by using a single coordinate reference system
+      (typically <abbr title="World Geodetic System 1984">WGS84</abbr>) as a universal system for all data.
+      The next chapters will explain why the reality is not so simple.
+      Whether a universal reference system can suit an application needs or not depends on the desired positional accuracy
+      and the kind of calculations to be performed with the data.
+      Unless otherwise specified, Apache <abbr>SIS</abbr> aims to represent coordinates on Earth with an accuracy of one centimetre or better.
       But the accuracy can be altered by various situations:
     </p>
     <ul>
       <li>Points should be inside the domain of validity as given by <code>ReferenceSystem.getDomainOfValidity()</code>.</li>
       <li>Distance measurements in a given map projection are true only is some special locations,
           named for instance “standards parallels”.</li>
-      <li>Positional accuracy is reduced after coordinate transformations. The new accuracy is described by
-          <code>CoordinateOperation.getCoordinateOperationAccuracy()</code>.</li>
+      <li>Positional accuracy is altered after coordinate transformations.
+          The new accuracy is described by <code>CoordinateOperation.getCoordinateOperationAccuracy()</code>.</li>
+      <li>Finding the most appropriate coordinate transformation parameters require the use of a geodetic dataset like <abbr>EPSG</abbr>.
+          Declaring those parameters within the <abbr>CRS</abbr> (for example with a <code>TOWGS84</code> element) is often not sufficient.</li>
     </ul>
+    <article>
+      <header>
+        <h1>“Early binding” versus “late binding” implementations</h1>
+      </header>
+      <p>
+        Because of the <abbr>WGS84</abbr> ubiquity, it is tempting to use that system as a hub or a pivot system
+        for all coordinate transformations.
+        The use of an “universal” system as a pivot simplifies the design of coordinate transformations libraries.
+        For example transformations from datum <var>A</var> to datum <var>B</var> can be done by first transforming
+        from <var>A</var> to <abbr>WGS84</abbr>, then from <abbr>WGS84</abbr> to <var>B</var>.
+        With such approach, a coordinate transformations library would only need to associate each
+        <code>GeodeticDatum</code> instance with the transformation parameters from that datum to <abbr>WGS84</abbr>.
+        This approach was encouraged in version 1 of <abbr>WKT</abbr> format, since that format specified a
+        <code>TOWGS84[…]</code> element (removed in <abbr>WKT</abbr> version 2) precisely for that purpose.
+        This approach is known in <abbr>EPSG</abbr> guidance notes as “early binding” implementations
+        since information about coordinate transformations are associated early in geodetic object definitions,
+        usually right at <code>GeographicCRS</code> creation time.
+        While <abbr>EPSG</abbr> acknowledges that this approach is commonly used,
+        this is not a recommended strategy for the following reasons:
+      </p>
+      <ul>
+        <li>More than one transformation may exist from datum <var>A</var> to datum <var>B</var>,
+            where each transformation is designed for a different geographic area.</li>
+        <li>Some operations are designed specifically for transformations from <var>A</var> to <var>B</var>
+            and do not have the same accuracy than an operation using <abbr>WGS84</abbr> as an intermediate step.</li>
+        <li><abbr>WGS84</abbr> itself has been updated many times,
+            which makes it a kind of moving target (admittedly slowly) for coordinate transformations libraries.</li>
+        <li>Different systems could be used as the pivot system, for example the <cite>Galileo Reference Frame</cite>
+            (<abbr>GTRF</abbr>) created for the European <abbr>GPS</abbr> competitor.</li>
+      </ul>
+      <div class="example"><p><b>Example:</b>
+        the <abbr>EPSG</abbr> geodetic dataset defines about 50 transformations from <abbr>NAD27</abbr> to <abbr>NAD83</abbr>.
+        In an early binding approach, the same geographic <abbr>CRS</abbr> (namely “<abbr>NAD27</abbr>”) in the <abbr>WKT</abbr> 1
+        format would need to be defined with a <code>TOWGS84[-8, 160, 176]</code> element for coordinates in <abbr>USA</abbr>
+        or with a <code>TOWGS84[-10, 158, 187]</code> element for coordinates in Canada.
+        Different parameter values exist for other regions like Cuba, so it is not possible to represent such diversity
+        with a single <code>TOWGS84[…]</code> element associated to a <abbr>CRS</abbr>.
+        But even when restricting <abbr>CRS</abbr> usage to the domain of validity of its single <code>TOWGS84[…]</code> element,
+        those transformations are still approximative with a 10 metres accuracy in the <abbr>USA</abbr> case.
+        More accurate transformations exist in the form of <abbr>NADCON</abbr> grid shift files,
+        but those transformations are from <abbr>NAD27</abbr> to <abbr>NAD83</abbr> (which move together on the same continental plate),
+        not to <abbr>WGS84</abbr> (which move independently).
+        The difference was often ignored when <abbr>NAD83</abbr> and <abbr>WGS84</abbr> were considered as practically equivalent,
+        but that assumption is subject to more caution today.
+      </p></div>
+      <p>
+        <abbr>EPSG</abbr> rather recommends the use of “late binding” approach,
+        in which coordinate transformation methods and parameters are defined for
+        “<var>A</var> to <var>B</var>” pairs of systems (eventually completed with domain of validity)
+        rather than associated to standalone datums.
+        Apache <abbr>SIS</abbr> is a “late binding” implementation,
+        while some reminiscences of “early binding” approach still exist in the form of the
+        <code>DefaultGeodeticDatum.getBursaWolfParameters()</code> property.
+        The later is used only if <abbr>SIS</abbr> fails to apply the late binding approach for given reference systems.
+      </p>
+    </article>
     <p>
       The <code>sis-referencing</code> module provides a set of classes implementing
       different specializations of the <code>ReferenceSystem</code> interface, together with required components.
       Those implementations store spatial reference system descriptions, together with metadata like their domain of validity.
       However those objects do not perform any operation on coordinate values.
-      Those operations are performed by another family of types, with <code>CoordinateOperation</code> as the root interface.
-      Those types will be discussed in <a href="#CoordinateOperation">another section</a>,
-      but we mention here two sub-types related to the coordinate accuracy topic:
+      Coordinates <cite>conversions</cite> or <cite>transformations</cite> are performed by another family of types,
+      with <code>CoordinateOperation</code> as the root interface.
+      Those types will be discussed in <a href="#CoordinateOperation">another section</a>.
     </p>
-    <ul>
-      <li>
-        <p>Coordinate <strong>conversions</strong> are fully determined by mathematic formulas.
-        Those conversions would have an infinite precision if it was not for the unavoidable rounding errors
-        inherent to floating-point calculations.</p>
-        <div class="example"><p><b>Example:</b> map projections.</p></div>
-      </li><li>
-        <p>Coordinate <strong>transformations</strong> are defined empirically.
-        They usually have a few meters error which is not caused by limitation in computer accuracy.
-        Those errors exist because transformations are only approximations of a more complex reality.</p>
-
-        <div class="example"><p><b>Example:</b> datum changes from
-        <cite>North American Datum 1927</cite> (<abbr>NAD27</abbr>) to
-        <cite>North American Datum 1983</cite> (<abbr>NAD83</abbr>),
-        even if the map projection method (e.g. Lambert Conformal or Transverse Mercator) does not change.</p>
-        </div>
-      </li>
-    </ul>
 
 
 
@@ -94,7 +136,7 @@
     <ul>
       <li>A <i>datum</i>, which specifies among other things which ellipsoid to use as an Earth shape approximation.</li>
       <li>A description for each axis: name, direction, units of measurement, range of values.</li>
-      <li>Sometime a list of parameters. A well-known example is when the <abbr>CRS</abbr> uses a map projection.</li>
+      <li>Sometime a list of parameters, especially when using map projections.</li>
     </ul>
     <p>
       Those systems are described by the <abbr>ISO</abbr> 19111 standard (<i>Referencing by Coordinates</i>),
@@ -124,9 +166,13 @@
       at the expense of the rest of the world for which the datum was not designed.
       Other datums are compromises applicable to the whole world.
     </p>
-    <div class="example"><p><b>Example:</b>
-      At the beginning of XX<sup>th</sup> century in <abbr>USA</abbr>, the Michigan state used an ellipsoid based on the
-      “Clarke 1866” ellipsoid but with axis lengths expanded by 800 feet.
+    <div class="example">
+      <p><b>Example:</b>
+      the <abbr>EPSG</abbr> geodetic dataset defines among others the “<abbr>WGS</abbr> 84”, “Clarke 1866”, “Clarke 1880”,
+      “<abbr>GRS</abbr> 1980” and “<abbr>GRS</abbr> 1980 Authalic Sphere” (a sphere of same surface than the <abbr>GRS</abbr> 1980 ellipsoid).
+      Ellipsoids may be used in various places of the world or may be defined for a very specific region.
+      For example in <abbr>USA</abbr> at the beginning of XX<sup>th</sup> century,
+      the Michigan state used an ellipsoid based on the “Clarke 1866” ellipsoid but with axis lengths expanded by 800 feet.
       This modification aimed to take in account the average state height above mean sea level.</p>
     </div>
 
@@ -149,14 +195,13 @@
       The <abbr title="Global Positioning System">GPS</abbr> invention implied the creation of a
       world geodetic system named <abbr title="World Geodetic System 1984">WGS84</abbr>.
       The ellipsoid is then unique and centered at the Earth gravity center.
-      <abbr>GPS</abbr> provide at any moment the receptor absolute position on that world geodetic system.
-      But since <abbr>WGS84</abbr> is a world-wide system, it may be differ significantly from local systems.
+      <abbr>GPS</abbr> provides at any moment the receptor absolute position on that world geodetic system.
+      But since <abbr>WGS84</abbr> is a world-wide system, it may differs significantly from local systems.
       For example the difference between <abbr>WGS84</abbr> and the European system <abbr>ED50</abbr> is about 150 metres,
       and the average difference between <abbr>WGS84</abbr> and the <cite>Réunion 1947</cite> system is 1.5 kilometres.
       Consequently we shall not blindly use <abbr>GPS</abbr> coordinates on a map,
       as transformations to the local system may be required.
-      Those transformations are represented in GeoAPI by instances of the <code>Transformation</code> interface
-      (a kind of operation mentioned in <a href="#Referencing">this chapter introduction</a>).
+      Those transformations are represented in GeoAPI by instances of the <code>Transformation</code> interface.
     </p><p>
       The <abbr>WGS84</abbr> ubiquity tends to reduce the need for <code>Transformation</code> operations with recent data,
       but does not eliminate it.
@@ -172,62 +217,6 @@
       Updating data to the new datum would imply transforming some straight lines or simple geometric shapes
       into more irregular shapes, if the shapes are large enough.
     </p>
-    <article>
-      <header>
-        <h1>“Early binding” versus “late binding” implementations</h1>
-      </header>
-      <p>
-        Because of the <abbr>WGS84</abbr> ubiquity, it is tempting to use that system as a hub or a pivot system
-        for all coordinate transformations.
-        The use of an “universal” system as a pivot simplifies the design of coordinate transformations libraries.
-        For example transformations from datum <var>A</var> to datum <var>B</var> can be done by first transforming
-        from <var>A</var> to <abbr>WGS84</abbr>, then from <abbr>WGS84</abbr> to <var>B</var>.
-        With such approach, a coordinate transformations library would only need to associate each
-        <code>GeodeticDatum</code> instance with the transformation parameters from that datum to <abbr>WGS84</abbr>.
-        This approach was encouraged in version 1 of <abbr>WKT</abbr> format, since that format specified a
-        <code>TOWGS84[…]</code> element (removed in <abbr>WKT</abbr> version 2) precisely for that purpose.
-        This approach is known in <abbr>EPSG</abbr> guidance notes as “early binding” implementations
-        since information about coordinate transformations are associated early in geodetic object definitions,
-        usually right at <code>GeographicCRS</code> creation time.
-        While <abbr>EPSG</abbr> acknowledges that this approach is commonly used,
-        this is not a recommended strategy for the following reasons:
-      </p>
-      <ul>
-        <li>More than one transformation may exist from datum <var>A</var> to datum <var>B</var>,
-            where each transformation is designed for a different geographic area.</li>
-        <li>Some operations are designed specifically for transformations from <var>A</var> to <var>B</var>
-            and do not have the same accuracy than an operation using <abbr>WGS84</abbr> as an intermediate step.</li>
-        <li><abbr>WGS84</abbr> itself has been updated many times,
-            which makes it a kind of moving target (admittedly slowly) for coordinate transformations libraries.</li>
-        <li>Different systems could be used as the pivot system, for example the <cite>Galileo Reference Frame</cite>
-            (<abbr>GTRF</abbr>) created for the European <abbr>GPS</abbr> competitor.</li>
-      </ul>
-      <div class="example"><p><b>Example:</b>
-        the <abbr>EPSG</abbr> geodetic dataset defines about 50 transformations from <abbr>NAD27</abbr> to <abbr>NAD83</abbr>.
-        In an early binding approach, the same geographic <abbr>CRS</abbr> (namely “<abbr>NAD27</abbr>”) in the <abbr>WKT</abbr> 1
-        format would need to be defined with a <code>TOWGS84[-8, 160, 176]</code> element for coordinates in <abbr>USA</abbr>
-        or with a <code>TOWGS84[-10, 158, 187]</code> element for coordinates in Canada.
-        Different parameter values exist for other regions like Cuba, so it is not possible to represent such diversity
-        with a single <code>TOWGS84[…]</code> element associated to a <abbr>CRS</abbr>.
-        But even when restricting <abbr>CRS</abbr> usage to the domain of validity of its single <code>TOWGS84[…]</code> element,
-        those transformations are still approximative with a 10 metres accuracy in the <abbr>USA</abbr> case.
-        More accurate transformations exist in the form of <abbr>NADCON</abbr> grid shift files,
-        but those transformations are from <abbr>NAD27</abbr> to <abbr>NAD83</abbr> (which move together on the same continental plate),
-        not to <abbr>WGS84</abbr> (which move independently).
-        The difference was often ignored when <abbr>NAD83</abbr> and <abbr>WGS84</abbr> were considered as practically equivalent,
-        but that assumption is subject to more caution today.
-      </p></div>
-      <p>
-        <abbr>EPSG</abbr> rather recommends the use of “late binding” approach,
-        in which coordinate transformation methods and parameters are defined for
-        “<var>A</var> to <var>B</var>” pairs of systems (eventually completed with domain of validity)
-        rather than associated to standalone datums.
-        Apache <abbr>SIS</abbr> is a “late binding” implementation,
-        while some reminiscences of “early binding” approach still exist in the form of the
-        <code>DefaultGeodeticDatum.getBursaWolfParameters()</code> property.
-        The later is used only if <abbr>SIS</abbr> fails to apply the late binding approach for given reference systems.
-      </p>
-    </article>
 
     <h3 id="CoordinateSystem">Coordinate systems</h3>
     <p style="color: red">TODO</p>
@@ -356,22 +345,46 @@ crs = AbstractCRS.castOrCopy(crs).forCon
       <li>The <cite>domain of validity</cite>, either as a textual description (e.g. “Canada – onshore and offshore”)
           or with the coordinates of a geographic bounding box.</li>
       <li>The <cite>positional accuracy</cite>, which may be anything from 1 centimetre to a few kilometres.</li>
-      <li>The coordinate operation subtype. If the coordinate operation is an instance of <code>Transformation</code>,
-          then it may be one among many possibilities depending on the area of interest, and its accuracy is limited by
-          “real world” constraints (not only rounding errors).
-          If the coordinate operation is rather an instance of <code>Conversion</code>, then it does not have those limitations.</li>
+      <li>The coordinate operation subtype. Among them, two sub-types provide the same functionalities but with a significant conceptual difference:
+        <ul class="verbose">
+          <li>
+            Coordinate <strong>conversions</strong> are fully determined by mathematical formulas.
+            Those conversions would have an infinite precision if it was not for the unavoidable rounding errors
+            inherent to floating-point calculations.
+            Map projections are in this category.
+          </li><li>
+            Coordinate <strong>transformations</strong> are defined empirically.
+            They often have errors of a few metres which are not caused by limitation in computer accuracy.
+            Those errors exist because transformations are only approximations of a more complex reality.
+            Datum shifts from <abbr title="North American Datum 1927">NAD27</abbr> to <abbr title="North American Datum 1983">NAD83</abbr>
+            are in this category.
+          </li>
+        </ul>
+      </li>
     </ul>
     <p>
-      The actual mathematical work is performed by an object obtained by a call to <code>cop.getMathTransform()</code>.
-      The <code>CoordinateOperation</code> and <code>MathTransform</code> types are separated because the later is a kind of “black box”,
-      which may be implemented in a very different way than what the coordinate operation said.
-      In particular many conceptually different coordinate operations (e.g. longitude rotations,
-      change of units of measurement, conversions between two Mercator projections on the same datum, <i>etc.</i>)
-      are implemented by <code>MathTransform</code> as <a href="#AffineTransform">affine transforms</a> and concatenated for efficiency.
+      If the coordinate operation is an instance of <code>Transformation</code>,
+      then the instance selected by <abbr>SIS</abbr> may be one among many possibilities depending on the area of interest.
+      Furthermore its accuracy is certainly less than the centimetric accuracy that we can expect from a <code>Conversion</code>.
+      Consequently verifying the domain of validity and the positional accuracy declared in the transformation metadata is of particular importance.
     </p>
 
     <h3 id="MathTransform">Executing an operation on coordinate values</h3>
     <p>
+      The <code>CoordinateOperation</code> object introduced in above section provides high-level informations
+      (source and target <abbr>CRS</abbr>, domain of validity, positional accuracy, operation parameters, <i>etc</i>).
+      The actual mathematical work is performed by a separated object obtained by a call to <code>CoordinateOperation.getMathTransform()</code>.
+      At the difference of <code>CoordinateOperation</code> instances, <code>MathTransform</code> instances do not carry any metadata.
+      They are kind of black box which know nothing about the source and target <abbr>CRS</abbr>
+      (actually the same <code>MathTransform</code> can be used for different pairs of <abbr>CRS</abbr> if the mathematical work is the same), domain or accuracy.
+      Furthermore <code>MathTransform</code> may be implemented in a very different way than what <code>CoordinateOperation</code> said.
+      In particular many conceptually different coordinate operations (e.g. longitude rotations,
+      change of units of measurement, conversions between two Mercator projections on the same datum, <i>etc.</i>)
+      are implemented by <code>MathTransform</code> as <a href="#AffineTransform">affine transforms</a> and concatenated for efficiency,
+      even if <code>CoordinateOperation</code> reports them as a chain of Mercator and other operations.
+      The “<a href="#CoordinateOperationSteps">conceptual versus real chain of coordinate operations</a>” section explains the differences in more details.
+    </p>
+    <p>
       The following Java code performs a map projection from geographic coordinates on the <cite>World Geodetic System 1984</cite> (<abbr>WGS84</abbr>) datum
       coordinates in the <cite>WGS 84 / UTM zone 33N</cite> coordinate reference system.
       In order to make the example a little bit simpler, this code uses predefined constants given by the <code>CommonCRS</code> convenience class.
@@ -409,43 +422,97 @@ public class MyApp {
 
     <h3 id="TransformDerivative">Partial derivatives of coordinate operations</h3>
     <p>
-      <span style="color: red">TODO</span>
+      Previous section shows how to project a coordinate from one reference system to another one.
+      There is another, less known, operation which does not compute the projected coordinates of a given point,
+      but instead the derivative of the projection function at that point.
+      This operation was defined in an older Open Geospatial specification,
+      <a href="http://www.opengeospatial.org/standards/ct">OGC 01-009</a>, now considered obsolete but still useful.
+      Let <var>P</var> be a map projection converting degrees of latitude and longitude (<var>φ</var>, <var>λ</var>)
+      into projected coordinates (<var>x</var>, <var>y</var>) in metres.
+      The formula below represents the map projection result as a column matrix
+      (reason will become clearer soon):
     </p>
 
-    <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
-      <mi>P</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo>
-      <mo>=</mo>
-      <mfenced open="[" close="]">
-        <mtable>
-          <mtr><mtd><mi>x</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mtd></mtr>
-          <mtr><mtd><mi>y</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mtd></mtr>
-        </mtable>
-      </mfenced>
-    </math>
-
-    <p>The map projection partial derivate at this point can be represented by the Jacobian matrix:</p>
-
-    <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
-      <msup><mi>P</mi><mo>′</mo></msup><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo>
-      <mo>=</mo>
-      <msub><mi>JAC</mi><mrow><mi>P</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow></msub>
-      <mo>=</mo>
-      <mfenced open="[" close="]">
-        <mtable>
-          <mtr>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
-          </mtr>
-          <mtr>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
-          </mtr>
-        </mtable>
-      </mfenced>
-    </math>
+    <table class="hidden">
+      <tr>
+        <th>Equation</th>
+        <th>Java code</th>
+      </tr>
+      <tr>
+        <td style="vertical-align:middle; min-width:350px; padding-right:60px">
+          <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
+            <mi>P</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo>
+            <mo>=</mo>
+            <mfenced open="[" close="]">
+              <mtable>
+                <mtr><mtd><mi>x</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mtd></mtr>
+                <mtr><mtd><mi>y</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mtd></mtr>
+              </mtable>
+            </mfenced>
+          </math>
+        </td>
+        <td style="vertical-align:middle; min-width:500px; padding-left:60px">
+          <pre style="margin:0">DirectPosition geographic = new DirectPosition2D(<var>φ</var>, <var>λ</var>);
+DirectPosition projected = <var><b>P</b></var>.transform(geographic, null);
+double <var>x</var> = projected.getOrdinate(0);
+double <var>y</var> = projected.getOrdinate(1);</pre>
+        </td>
+      </tr>
+    </table>
+
+    <p>The map projection partial derivate at this point can be represented by a Jacobian matrix:</p>
+
+    <table class="hidden">
+      <tr>
+        <th>Equation</th>
+        <th>Java code</th>
+      </tr>
+      <tr>
+        <td style="vertical-align:middle; min-width:350px; padding-right:60px">
+          <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
+            <msup><mi>P</mi><mo>′</mo></msup><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo>
+            <mo>=</mo>
+            <msub><mi>JAC</mi><mrow><mi>P</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow></msub>
+            <mo>=</mo>
+            <mfenced open="[" close="]">
+              <mtable>
+                <mtr>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                </mtr>
+                <mtr>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                </mtr>
+              </mtable>
+            </mfenced>
+          </math>
+        </td>
+        <td style="vertical-align:middle; min-width:500px; padding-left:60px">
+          <pre style="margin:0">DirectPosition geographic = new DirectPosition2D(<var>φ</var>, <var>λ</var>);
+Matrix jacobian = <var><b>P</b></var>.derivative(geographic);
+double dx_dλ = jacobian.getElement(0,1);
+double dy_dφ = jacobian.getElement(1,0);</pre>
+        </td>
+      </tr>
+    </table>
 
     <p>
-      <span style="color: red">TODO</span>
+      Remaining equations in this section will abridge
+      ∂<var>x</var>(<var>λ</var>, <var>φ</var>) as ∂<var>x</var> and
+      ∂<var>y</var>(<var>λ</var>, <var>φ</var>) as ∂<var>y</var>,
+      but reader should keep in mind that each of those derivative values depends on the (<var>λ</var>, <var>φ</var>) coordinate given at Jacobian matrix calculation time.
+      The first matrix column tells us that if we apply a small displacement of ∂<var>φ</var> degrees of latitude from the (<var>φ</var>, <var>λ</var>) position,
+      — in other words if we move at the (<var>φ</var> + ∂<var>φ</var>, <var>λ</var>) geographic position —
+      then the projected coordinate will be displaced by (∂<var>x</var>, ∂<var>λ</var>) metres
+      — in other words it will become (<var>x</var> + ∂<var>x</var>, <var>y</var> + ∂<var>λ</var>).
+      Similarly the last matrix column gives us the displacement that happen on the projected coordinate
+      if we apply a small displacement of ∂<var>λ</var> degrees of longitude on the source geographic coordinate.
+      We can visualize such displacements in a figure like below.
+      This figure shows the derivative at two points, <var>P</var><sub>1</sub> and <var>P</var><sub>2</sub>,
+      for emphasing that the result change for every points.
+      In that figure, vectors <var>U</var> et <var>V</var> stand for the first and second column respectively
+      in the Jacobian matrices.
     </p>
 
     <table class="hidden"><tr>
@@ -459,10 +526,10 @@ public class MyApp {
               <mfenced open="[" close="]">
                 <mtable>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
                   </mtr>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
                   </mtr>
                 </mtable>
               </mfenced>
@@ -473,10 +540,10 @@ public class MyApp {
               <mfenced open="[" close="]">
                 <mtable>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
                   </mtr>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
                   </mtr>
                 </mtable>
               </mfenced>
@@ -692,7 +759,7 @@ public Matrix derivative(DirectPosition
         Except for the first and last ones, all Apache <abbr>SIS</abbr> steps work on right-handed coordinate systems
         (as opposed to the left-handed coordinate system when <var>latitude</var> is before <var>longitude</var>),
         with angular units in radians (instead than degrees) and
-        linear units relative to an ellipsoid of semi-major axis length of 1 (instead than Earth's size).
+        linear units relative to an ellipsoid of semi-major axis length of 1 (instead than Earth’s size).
         Working in those coordinate systems requires additional steps for unit conversions and axes swapping
         at the beginning and at the end of the chain.
         Apache <abbr>SIS</abbr> uses <cite>affine parametric conversions</cite> for this purpose,

Modified: sis/site/trunk/book/fr/referencing.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/referencing.html?rev=1762098&r1=1762097&r2=1762098&view=diff
==============================================================================
--- sis/site/trunk/book/fr/referencing.html (original)
+++ sis/site/trunk/book/fr/referencing.html Fri Sep 23 22:41:58 2016
@@ -32,19 +32,21 @@
       <h1 id="Referencing">Systèmes de références spatiales</h1>
     </header>
     <p>
-      Pour donner une position sur la Terre on peut utiliser des noms tels que celui d’une ville ou une adresse postale
+      Pour donner une position sur la Terre, on peut utiliser des noms tels que celui d’une ville ou une adresse postale
       — on parle alors de références spatiales par <cite>identifiants</cite> —
-      ou on peut donner des valeurs numériques valides dans un système de coordonnées donné
+      ou on peut donner des valeurs numériques valides dans un système de coordonnées donné telles que les latitudes et longitudes
       — on parle alors de références spatiales par <cite>coordonnées</cite>.
-      Chaque système implique des approximations telles que:
-    </p>
-    <ul>
-      <li>Le choix de la forme géométrique (géoïde, ellipsoïde, <i>etc.</i>) utilisée comme approximation de la forme de la Terre.</li>
-      <li>Le choix des propriétés géométriques (angles, distances, <i>etc.</i>) à préserver lors de la représentation d’une carte sur une surface plane.</li>
-      <li>Les pertes de précision lorsque l’on doit transformer des positions exprimées selon un système vers des positions exprimées selon un autre système.</li>
-    </ul>
-    <p>
-      En l’absence d’indication contraire, la précision recherchée pour les coordonnées sur la Terre est de 1 centimètre.
+      Chaque système de référence implique des approximations telles que
+      le choix de la forme géométrique (géoïde, ellipsoïde, <i>etc.</i>) utilisée comme approximation de la forme de la Terre,
+      le choix des propriétés géométriques (angles, distances, <i>etc.</i>) à préserver lors de la représentation d’une carte sur une surface plane, et
+      les pertes de précision lorsque l’on doit transformer des coordonnées vers des systèmes utilisant un <a href="#GeodeticDatum">référentiel</a> différent.
+    </p><p>
+      Une fausse croyance très répandue est que l’on peut éviter cette complexité en choisissant un seul système de référence des coordonnées
+      (typiquement <abbr title="World Geodetic System 1984">WGS84</abbr>) comme système universel pour toutes les données.
+      Les chapitres suivants expliqueront pourquoi la réalité n’est pas si simple.
+      Qu’un système universel réponde ou non aux besoins d’une application dépend de la précision désirée,
+      ainsi que du type de calculs que l’on souhaite effectuer avec les coordonnées.
+      Sauf indication contraire, Apache <abbr>SIS</abbr> tente d’assurer une précision de 1 centimètre pour les coordonnées sur la Terre.
       Mais la maîtrise de cette précision nécessite le respect de certaines conditions:
     </p>
     <ul>
@@ -53,34 +55,72 @@
           appelés par exemple « parallèles standards ».</li>
       <li>Vérifier la précision des transformations de coordonnées, par exemple avec
           <code>CoordinateOperation.getCoordinateOperationAccuracy()</code>.</li>
+      <li>Trouver les paramètres les plus appropriées pour une transformation de coordonnées requiert l’usage d’une base de données géodétiques telles que <abbr>EPSG</abbr>.
+          Déclarer ces paramètres directement dans le <abbr>CRS</abbr> (par exemple avec un élément <code>TOWGS84</code>) n’est souvent pas suffisant.</li>
     </ul>
+    <article>
+      <header>
+        <h1>Bibliothèques de type « early binding » versus « late binding »</h1>
+      </header>
+      <p>
+        Le caractère universel du système <abbr>WGS84</abbr> rend tentante l’idée de l’utiliser comme système pivot,
+        afin de simplifier l’implémentation d’une bibliothèque de transformation de coordonnées.
+        La transformation d’une coordonnée d’un référentiel <var>A</var> vers un référentiel <var>B</var>
+        pourrait se faire en transformant d’abord de <var>A</var> vers <abbr>WGS84</abbr>, puis de <abbr>WGS84</abbr> vers <var>B</var>.
+        Il suffirait ainsi de stocker dans chaque objet <code>GeodeticDatum</code> les informations nécessaires à la transformation vers <abbr>WGS84</abbr>.
+        Cette approche était encouragée dans la version 1 du format <abbr>WKT</abbr>, qui définissait un élément <code>TOWGS84[…]</code> remplissant ce rôle.
+        Cette approche est désignée par <abbr>EPSG</abbr> sous le nom de « early binding »
+        car elle associe des informations sur la transformations de coordonnées très tôt dans la définition des objets géodésiques,
+        souvent directement au moment de la construction d’un object <code>GeographicCRS</code>.
+        Bien que <abbr>EPSG</abbr> reconnaisse que cette approche soit couramment employée, elle n’est pas recommandée pour plusieurs raisons:
+      </p>
+      <ul>
+        <li>Il existe parfois plusieurs transformations allant d’un référentiel <var>A</var> vers <var>B</var>,
+            chacune étant plus précise pour une région géographique donnée.</li>
+        <li>Certaines opérations sont conçues spécifiquement pour transformer de <var>A</var> vers <var>B</var>
+            et n’ont pas la même précision qu’aurait une autre transformation faisant un détour par <abbr>WGS84</abbr>.</li>
+        <li><abbr>WGS84</abbr> lui-même subit parfois des révisions, ce qui en fait une cible mouvante (bien que très lentement)
+            pour les bibliothèques de transformations de coordonnées.</li>
+        <li>Il existe d’autres systèmes globaux qui pourraient servir de pivot, par exemple le <cite>Galileo Reference Frame</cite> (<abbr>GTRF</abbr>)
+            mis en place par le concurrent européen du <abbr>GPS</abbr>.</li>
+      </ul>
+      <div class="example"><p><b>Exemple:</b>
+        la base de données géodésiques <abbr>EPSG</abbr> définie une cinquantaine de transformations de <abbr>NAD27</abbr> vers <abbr>NAD83</abbr>.
+        Dans une approche de type « early binding », le même système de référence « <abbr>NAD27</abbr> » représenté dans le format <abbr>WKT</abbr> 1
+        aurait besoin d’être défini avec un élément <code>TOWGS84[-8, 160, 176]</code> pour des coordonnées aux États-Unis,
+        ou avec un élément <code>TOWGS84[-10, 158, 187]</code> pour coordonnées aux Canada.
+        Différents paramètres existent aussi pour d’autres régions telles que Cuba.
+        Il n’est donc pas possible de représenter une telle diversité en associant un seul élément <code>TOWGS84[…]</code> à un système de référence des coordonnées.
+        Même en restreignant l’usage d’un référenciel au domaine de validité de son élément <code>TOWGS84[…]</code>,
+        ces transformations resteraient approximatives avec une précision de 10 mètres dans le cas des États-Unis.
+        Des transformations plus précises existent sous la forme des grilles de changements de référentiel <abbr>NADCON</abbr>,
+        mais ces grilles sont pour des transformations de <abbr>NAD27</abbr> vers <abbr>NAD83</abbr>
+        (qui se déplacent ensemble sur la même plaque continentale) et non vers <abbr>WGS84</abbr> (qui se déplace indépendamment).
+        Cette différence était souvent ignorée lorsque l’on considérait que <abbr>NAD83</abbr> et <abbr>WGS84</abbr>
+        étaient pratiquement équivalents, mais cette supposition est aujourd’hui à prendre avec plus de précautions.
+      </p></div>
+      <p>
+        <abbr>EPSG</abbr> recommande plutôt d’utiliser une approche dite « late binding »,
+        selon laquelle les méthodes et paramètres nécessaires aux transformations de coordonnées sont définis pour des paires
+        de référentiels « <var>A</var> vers <var>B</var> » (éventuellement complétées par leurs domaines de validité)
+        plutôt qu’associés à des référentiels pris isolément.
+        Apache <abbr>SIS</abbr> est une implémentation de type « late binding »,
+        bien qu’une réminiscence de l’approche « early binding » existe toujours
+        sous la forme de la propriété <code>DefaultGeodeticDatum.getBursaWolfParameters()</code>.
+        <abbr>SIS</abbr> n’utilise cette dernière que comme solution de dernier recours
+        s’il ne peut pas appliquer l’approche « late binding » avec les systèmes de références donnés.
+      </p>
+    </article>
     <p>
       Le module <code>sis-referencing</code> de Apache <abbr>SIS</abbr> fournit un ensemble de classes implémentant
       les différentes spécialisations de l’interface <code>ReferenceSystem</code> ainsi que leurs composantes.
       Ces implémentations permettent de stocker une description des systèmes de références spatiales
       ainsi que leurs méta-données telles que la zone de validité.
       Toutefois ces objets n’effectuent aucune opération sur les coordonnées.
-      Ces opérations sont le travail d’une autre famille de classes, dont la racine est l’interface <code>CoordinateOperation</code>.
-      Ces classes seront discutées dans <a href="#CoordinateOperation">une autre section</a>,
-      mais nous mentionnons ici deux spécialisations en rapport avec le sujet de la précision des coordonnées:
+      Les <cite>conversions</cite> ainsi que les <cite>transformations</cite> de coordonnées sont le travail d’une autre famille de classes,
+      dont la racine est l’interface <code>CoordinateOperation</code>.
+      Ces classes seront discutées dans <a href="#CoordinateOperation">une autre section</a>.
     </p>
-    <ul>
-      <li>
-        <p>Les <strong>conversions</strong> de coordonnées sont entièrement définies par une formule mathématique.
-        Les conversions s’effectueraient avec une précision infinie s’il n’y avait pas les inévitables
-        erreurs d’arrondissements inhérents aux calculs sur des nombres réels.</p>
-        <div class="example"><p><b>Exemple:</b> les projections cartographiques.</p></div>
-      </li><li>
-        <p>Les <strong>transformations</strong> de coordonnées sont définies de manière empirique.
-        Elles ont souvent des erreurs de quelques mètres qui ne sont pas dues à des limites de la précision des ordinateurs.
-        Ces erreurs découlent du fait que la transformation utilisée n’est qu’une approximation d’une réalité plus complexe.</p>
-
-        <div class="example"><p><b>Exemple:</b> les changements de référentiels tel que le passage de la
-        <cite>Nouvelle Triangulation Française</cite> (<abbr>NTF</abbr>) vers le
-        <cite>Réseau Géodésique Français 1993</cite> (<abbr>RGF93</abbr>),
-        même lorsque la méthode de projection cartographique (Lambert conique conforme) ne change pas.</p></div>
-      </li>
-    </ul>
 
 
 
@@ -127,7 +167,10 @@
       et d’autres offrant un compromis pour l’ensemble de la planète.
     </p>
     <div class="example"><p><b>Exemple:</b>
-      au début du XX<sup>e</sup> siècle aux États-Unis, l’état du Michigan utilisait pour ses cartes un ellipsoïde basé
+      la base de données géodétiques <abbr>EPSG</abbr> définit entre autres les ellipsoïdes « <abbr>WGS</abbr> 84 », « Clarke 1866 », « Clarke 1880 »,
+      « <abbr>GRS</abbr> 1980 » and « <abbr>GRS</abbr> 1980 Authalic Sphere » (une sphère de même surface que l’ellipsoïde <abbr>GRS</abbr> 1980).
+      Un ellipsoïde peut être utilisé en divers endroits de la planète ou peut être très spécifique à une région précise.
+      Par exemple au début du XX<sup>e</sup> siècle aux États-Unis, l’état du Michigan utilisait pour ses cartes un ellipsoïde basé
       sur l’ellipsoïde « Clarke 1866 » mais auquel la longueur des axes a été allongée de 800 pieds.
       Cette modification visait à tenir compte du niveau moyen de l’état au dessus du niveau de la mer.</p>
     </div>
@@ -158,8 +201,7 @@
       et l’écart moyen par rapport au système de l’île de la Réunion 1947 est de 1,5 kilomètres.
       Il ne faut donc pas rapporter aveuglement des positions <abbr>GPS</abbr> sur une carte.
       Des correspondances avec les systèmes régionaux peuvent être nécessaires
-      et sont représentées dans GeoAPI sous forme d’objets de type <code>Transformation</code>
-      (une classe d’opérations mentionnée dans l’<a href="#Referencing">introduction de ce chapitre</a>).
+      et sont représentées dans GeoAPI sous forme d’objets de type <code>Transformation</code>.
     </p><p>
       Les généralisation de l’usage du système <abbr>WGS84</abbr> tend à réduire le besoin d’utiliser
       les objets <code>Transformation</code> pour les données récentes, mais ne l’élimine pas complètement.
@@ -175,59 +217,6 @@
       Mettre à jour dans un nouveau référentiel peut obliger à transformer des lignes droites ou des formes géométriques simples en des formes plus irrégulières
       si on ne veut pas que des parcelles de terrain changent de propriétaire.
     </p>
-    <article>
-      <header>
-        <h1>Bibliothèques de type « early binding » versus « late binding »</h1>
-      </header>
-      <p>
-        Le caractère universel du système <abbr>WGS84</abbr> rend tentante l’idée de l’utiliser comme système pivot,
-        afin de simplifier l’implémentation d’une bibliothèque de transformation de coordonnées.
-        La transformation d’une coordonnée d’un référentiel <var>A</var> vers un référentiel <var>B</var>
-        pourrait se faire en transformant d’abord de <var>A</var> vers <abbr>WGS84</abbr>, puis de <abbr>WGS84</abbr> vers <var>B</var>.
-        Il suffirait ainsi de stocker dans chaque objet <code>GeodeticDatum</code> les informations nécessaires à la transformation vers <abbr>WGS84</abbr>.
-        Cette approche était encouragée dans la version 1 du format <abbr>WKT</abbr>, qui définissait un élément <code>TOWGS84[…]</code> remplissant ce rôle.
-        Cette approche est désignée par <abbr>EPSG</abbr> sous le nom de « early binding »
-        car elle associe des informations sur la transformations de coordonnées très tôt dans la définition des objets géodésiques,
-        souvent directement au moment de la construction d’un object <code>GeographicCRS</code>.
-        Bien que <abbr>EPSG</abbr> reconnaisse que cette approche soit couramment employée, elle n’est pas recommandée pour plusieurs raisons:
-      </p>
-      <ul>
-        <li>Il existe parfois plusieurs transformations allant d’un référentiel <var>A</var> vers <var>B</var>,
-            chacune étant plus précise pour une région géographique donnée.</li>
-        <li>Certaines opérations sont conçues spécifiquement pour transformer de <var>A</var> vers <var>B</var>
-            et n’ont pas la même précision qu’aurait une autre transformation faisant un détour par <abbr>WGS84</abbr>.</li>
-        <li><abbr>WGS84</abbr> lui-même subit parfois des révisions, ce qui en fait une cible mouvante (bien que très lentement)
-            pour les bibliothèques de transformations de coordonnées.</li>
-        <li>Il existe d’autres systèmes globaux qui pourraient servir de pivot, par exemple le <cite>Galileo Reference Frame</cite> (<abbr>GTRF</abbr>)
-            mis en place par le concurrent européen du <abbr>GPS</abbr>.</li>
-      </ul>
-      <div class="example"><p><b>Exemple:</b>
-        la base de données géodésiques <abbr>EPSG</abbr> définie une cinquantaine de transformations de <abbr>NAD27</abbr> vers <abbr>NAD83</abbr>.
-        Dans une approche de type « early binding », le même système de référence « <abbr>NAD27</abbr> » représenté dans le format <abbr>WKT</abbr> 1
-        aurait besoin d’être défini avec un élément <code>TOWGS84[-8, 160, 176]</code> pour des coordonnées aux États-Unis,
-        ou avec un élément <code>TOWGS84[-10, 158, 187]</code> pour coordonnées aux Canada.
-        Différents paramètres existent aussi pour d’autres régions telles que Cuba.
-        Il n’est donc pas possible de représenter une telle diversité en associant un seul élément <code>TOWGS84[…]</code> à un système de référence des coordonnées.
-        Même en restreignant l’usage d’un référenciel au domaine de validité de son élément <code>TOWGS84[…]</code>,
-        ces transformations resteraient approximatives avec une précision de 10 mètres dans le cas des États-Unis.
-        Des transformations plus précises existent sous la forme des grilles de changements de référentiel <abbr>NADCON</abbr>,
-        mais ces grilles sont pour des transformations de <abbr>NAD27</abbr> vers <abbr>NAD83</abbr>
-        (qui se déplacent ensemble sur la même plaque continentale) et non vers <abbr>WGS84</abbr> (qui se déplace indépendamment).
-        Cette différence était souvent ignorée lorsque l’on considérait que <abbr>NAD83</abbr> et <abbr>WGS84</abbr>
-        étaient pratiquement équivalents, mais cette supposition est aujourd’hui à prendre avec plus de précautions.
-      </p></div>
-      <p>
-        <abbr>EPSG</abbr> recommande plutôt d’utiliser une approche dite « late binding »,
-        selon laquelle les méthodes et paramètres nécessaires aux transformations de coordonnées sont définis pour des paires
-        de référentiels « <var>A</var> vers <var>B</var> » (éventuellement complétées par leurs domaines de validité)
-        plutôt qu’associés à des référentiels pris isolément.
-        Apache <abbr>SIS</abbr> est une implémentation de type « late binding »,
-        bien qu’une réminiscence de l’approche « early binding » existe toujours
-        sous la forme de la propriété <code>DefaultGeodeticDatum.getBursaWolfParameters()</code>.
-        <abbr>SIS</abbr> n’utilise cette dernière que comme solution de dernier recours
-        s’il ne peut pas appliquer l’approche « late binding » avec les systèmes de références donnés.
-      </p>
-    </article>
 
     <h3 id="CoordinateSystem">Systèmes de coordonnées</h3>
     <p style="color: red">TODO</p>
@@ -247,7 +236,7 @@
       Les standards <abbr>OGC</abbr> récents demandent d’ordonner les axes tel que spécifié par l’autorité qui a définit le <abbr>CRS</abbr>.
       Mais des standards <abbr>OGC</abbr> plus anciens utilisaient l’ordre (<var>x</var>, <var>y</var>) inconditionnellement,
       en ignorant les spécifications des autorités sur ce point.
-      Beaucoup de logiciels continue d’utiliser cet ordre (<var>x</var>, <var>y</var>),
+      Beaucoup de logiciels continuent d’utiliser cet ordre (<var>x</var>, <var>y</var>),
       peut-être parce qu’une telle uniformisation rend l’implémentation et l’utilisation des <abbr>CRS</abbr> <em>en apparence</em> plus simple.
       Apache <abbr>SIS</abbr> supporte les deux conventions avec l’approche suivante:
       par défaut, <abbr>SIS</abbr> construit les <abbr>CRS</abbr> avec les axes <em>dans l’ordre définit par l’autorité</em>.
@@ -357,30 +346,55 @@ crs = AbstractCRS.castOrCopy(crs).forCon
     </p>
     <ul>
       <li>Le <cite>domaine de validité</cite>, soit comme une description textuelle telle que « Canada – onshore and offshore »
-          ou comme les coordonnées géographiques d’une boîte englobante.</li>
+        ou comme les coordonnées géographiques d’une boîte englobante.</li>
       <li>La <cite>précision</cite>, qui peut être n’importe quoi entre 1 centimètre et quelques kilomètres.</li>
-      <li>Le sous-type de l’opération sur les coordonées. Si l’opération est une instance de <code>Transformation</code>,
-          alors l’opération sélectionnée peut n’être qu’une possibilité parmi plusieurs, selon la région d’intérêt,
-          et sa précision peut être limitée à cause de contrainte du « monde réel » (pas seulement les erreurs d’arrondissements).
-          Si l’opération est plutôt une instance de <code>Conversion</code>, alors elle n’a pas ses limitations.</li>
+      <li>Le sous-type de l’opération sur les coordonnées. Parmi les sous-types possibles,
+        deux offrent les mêmes fonctionnalités mais avec une différence conceptuelle notable:
+        <ul class="verbose">
+          <li>
+            Les <strong>conversions</strong> de coordonnées sont entièrement définies par une formule mathématique.
+            Les conversions s’effectueraient avec une précision infinie s’il n’y avait pas les inévitables
+            erreurs d’arrondissements inhérents aux calculs sur des nombres réels.
+            Les projections cartographiques entrent dans cette catégorie.
+          </li><li>
+            Les <strong>transformations</strong> de coordonnées sont définies de manière empirique.
+            Elles ont souvent des erreurs de quelques mètres qui ne sont pas dues à des limites de la précision des ordinateurs.
+            Ces erreurs découlent du fait que la transformation utilisée n’est qu’une approximation d’une réalité plus complexe.
+            Les changements de référentiels tel que le passage de la
+            <cite>Nouvelle Triangulation Française</cite> (<abbr>NTF</abbr>) vers le
+            <cite>Réseau Géodésique Français 1993</cite> (<abbr>RGF93</abbr>) entrent dans cette catégorie.
+          </li>
+        </ul>
+      </li>
     </ul>
     <p>
-      Le travail mathématique réel est effectué par un objet obtenu par un appel à <code>cop.getMathTransform()</code>.
-      Les types <code>CoordinateOperation</code> et <code>MathTransform</code> sont séparés parce que ce dernier est une sorte de boîte noire,
-      qui peut être implémentée d’une manière très différente à ce que l’objet <code>CoordinateOperation</code> dit.
-      En particulier plusieurs opérations conceptuellement différentes (par exemple rotations de la longitude,
-      changements d’unités de mesure, conversions entre deux projections de Mercator qui utilisent le même référentiel, <i>etc.</i>)
-      sont implémentées par <code>MathTransform</code> comme des <a href="#AffineTransform">transformations affines</a>
-      et concaténées pour des raisons d’efficacité.
+      Lorsque l’opération sur les coordonnées est une instance de <code>Transformation</code>,
+      il est possible que l’instance choisie par <abbr>SIS</abbr> ne soit qu’une parmi plusieurs possibilités en fonction de la région d’intérêt.
+      En outre, sa précision sera certainement moindre que la précision centimétrique que l’on peut attendre d’une <code>Conversion</code>.
+      Vérifier la zone de validité ainsi que la précision déclarées dans les méta-données de la transformation prend alors une importance particulière.
     </p>
 
     <h3 id="MathTransform">Exécution de opérations</h3>
     <p>
+      L’objet <code>CoordinateOperation</code> introduit dans la section précédente fournit des informations de haut-niveau
+      (<abbr>CRS</abbr> source et destination, zone de validité, précision, paramètres de l’opération, <i>etc</i>).
+      Le travail mathématique réel est effectué par un objet séparé, obtenu par un appel à <code>CoordinateOperation.getMathTransform()</code>.
+      Contrairement aux instances de <code>CoordinateOperation</code>, les instances de <code>MathTransform</code> ne contiennent aucune méta-données.
+      Elles sont une sorte de boîte noire qui ignore tout des <abbr>CRS</abbr> source et destination
+      (en fait la même instance de <code>MathTransform</code> peut être utilisée pour différentes paires de <abbr>CRS</abbr> si le travail mathématique est le même).
+      En outre une instance de <code>MathTransform</code> peut être implémentée d’une manière très différente à ce que <code>CoordinateOperation</code> dit.
+      En particulier, plusieurs opérations conceptuellement différentes (par exemple rotations de la longitude,
+      changements d’unités de mesure, conversions entre deux projections de Mercator qui utilisent le même référentiel, <i>etc.</i>)
+      sont implémentées par <code>MathTransform</code> comme des <a href="#AffineTransform">transformations affines</a>
+      et concaténées pour des raisons d’efficacité, même si <code>CoordinateOperation</code> les affiche comme une chaîne d’opérations telles que la projection de Mercator.
+      La section « <a href="#CoordinateOperationSteps">chaîne d’opération conceptuelle versus réelle</a> » explique plus en détails les différences.
+    </p>
+    <p>
       Le code Java suivant effectue une projection cartographique à partir de coordonnées géographiques selon le référentiel
       <cite>World Geodetic System 1984</cite> (<abbr>WGS84</abbr>) vers des coordonnées selon le système <cite>WGS 84 / UTM zone 33N</cite>.
       Afin de rendre l’exemple un peu plus simple, ce code utilise des constantes pré-définies dans la classe de commodité <code>CommonCRS</code>.
       Mais des applications plus avancées voudront souvent utiliser des codes <abbr>EPSG</abbr> plutôt.
-      Notes que toutes les coordonnées géographiques dans ce code ont la latitude avant la longitude.
+      Notons que toutes les coordonnées géographiques dans ce code ont la latitude avant la longitude.
     </p>
 
 <pre>import org.opengis.geometry.DirectPosition;
@@ -413,72 +427,98 @@ public class MyApp {
 
     <h3 id="TransformDerivative">Dérivées partielles des opérations</h3>
     <p>
-      La section précédente indiquait comment calculer les coordonnées d’un point géographique dans une projection au choix.
-      Mais il existe une autre opération moins connue, qui consiste à calculer non pas la <em>coordonnées projetée</em> d’un point,
-      mais plutôt la <em>dérivée de la fonction de projection cartographique</em> en ce point.
+      La section précédente indiquait comment projeter les coordonnées d’un système de référence vers un autre.
+      Mais il existe une autre opération moins connue, qui consiste à calculer non pas la coordonnée projetée d’un point,
+      mais plutôt la dérivée de la fonction de projection cartographique en ce point.
       Cette opération était définie dans une ancienne spécification du consortium Open Geospatial,
       <a href="http://www.opengeospatial.org/standards/ct">OGC 01-009</a>, aujourd’hui un peu oubliée mais pourtant encore utile.
-    </p>
-
-    <p>
-      Appelons <var>P</var> une projection cartographique qui convertit une longitude et latitude (<var>λ</var>,<var>φ</var>) en degrés
-      vers une coordonnée projetée (<var>x</var>,<var>y</var>) en mètres.
+      Appelons <var>P</var> une projection cartographique qui convertit une latitude et longitude (<var>φ</var>, <var>λ</var>) en degrés
+      vers une coordonnée projetée (<var>x</var>, <var>y</var>) en mètres.
       Dans l’expression ci-dessous, nous représentons le résultat de la projection cartographique
       sous forme d’une matrice colonne (la raison sera plus claire bientôt):
     </p>
 
-    <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
-      <mi>P</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo>
-      <mo>=</mo>
-      <mfenced open="[" close="]">
-        <mtable>
-          <mtr><mtd><mi>x</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mtd></mtr>
-          <mtr><mtd><mi>y</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mtd></mtr>
-        </mtable>
-      </mfenced>
-    </math>
-
-    <p>La dérivée de la projection cartographique en ce même point peut se représenter par la matrice Jacobienne définie tel que:</p>
-
-    <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
-      <msup><mi>P</mi><mo>′</mo></msup><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo>
-      <mo>=</mo>
-      <msub><mi>JAC</mi><mrow><mi>P</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow></msub>
-      <mo>=</mo>
-      <mfenced open="[" close="]">
-        <mtable>
-          <mtr>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
-          </mtr>
-          <mtr>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
-            <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>λ</mi><mo>,</mo><mi>φ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
-          </mtr>
-        </mtable>
-      </mfenced>
-    </math>
-
-    <p>
-      Dans la suite de ce texte nous abrégerons ∂<var>x</var>(<var>λ</var>,<var>φ</var>) par ∂<var>x</var> et de même pour ∂<var>y</var>,
-      mais il faut garder à l’esprit que chacune de ces valeurs dépendent de la coordonnée (<var>λ</var>,<var>φ</var>) originale.
-      Le premier élément de la matrice (∂<var>x</var>/∂<var>λ</var>) nous indique à quel déplacement vers l’Est
-      (<var>x</var> en mètres) correspond un déplacement de un degré de longitude (<var>λ</var>).
-      De même, le dernier élément de la matrice (∂<var>y</var>/∂<var>φ</var>) nous indique à quel déplacement vers le Nord
-      (<var>y</var> en mètres) correspond un déplacement de un degré de latitude (<var>φ</var>).
-      Les autres éléments (∂<var>x</var>/∂<var>φ</var> et ∂<var>y</var>/∂<var>λ</var>) sont des termes croisés (par exemple à quel déplacement
-      en mètres vers le <em>Nord</em> correspond un déplacement de un degré de <em>longitude</em>).
-      Ces valeurs ne sont généralement valides qu’à la position géographique (<var>λ</var>,<var>φ</var>) donnée.
-      Si on se déplace un peu, ces valeurs changent légèrement.
-      Cette matrice nous donne toutefois une bonne idée du comportement de la projection dans le voisinage du point projeté.
-    </p>
-
-    <p>
-      On peut se représenter visuellement cette matrice comme ci-dessous.
+    <table class="hidden">
+      <tr>
+        <th>Équation</th>
+        <th>Code Java</th>
+      </tr>
+      <tr>
+        <td style="vertical-align:middle; min-width:350px; padding-right:60px">
+          <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
+            <mi>P</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo>
+            <mo>=</mo>
+            <mfenced open="[" close="]">
+              <mtable>
+                <mtr><mtd><mi>x</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mtd></mtr>
+                <mtr><mtd><mi>y</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mtd></mtr>
+              </mtable>
+            </mfenced>
+          </math>
+        </td>
+        <td style="vertical-align:middle; min-width:500px; padding-left:60px">
+          <pre style="margin:0">DirectPosition geographic = new DirectPosition2D(<var>φ</var>, <var>λ</var>);
+DirectPosition projected = <var><b>P</b></var>.transform(geographic, null);
+double <var>x</var> = projected.getOrdinate(0);
+double <var>y</var> = projected.getOrdinate(1);</pre>
+        </td>
+      </tr>
+    </table>
+
+    <p>La dérivée de la projection cartographique en ce même point peut se représenter par une matrice Jacobienne:</p>
+
+    <table class="hidden">
+      <tr>
+        <th>Équation</th>
+        <th>Code Java</th>
+      </tr>
+      <tr>
+        <td style="vertical-align:middle; min-width:350px; padding-right:60px">
+          <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
+            <msup><mi>P</mi><mo>′</mo></msup><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo>
+            <mo>=</mo>
+            <msub><mi>JAC</mi><mrow><mi>P</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow></msub>
+            <mo>=</mo>
+            <mfenced open="[" close="]">
+              <mtable>
+                <mtr>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                </mtr>
+                <mtr>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                  <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                </mtr>
+              </mtable>
+            </mfenced>
+          </math>
+        </td>
+        <td style="vertical-align:middle; min-width:500px; padding-left:60px">
+          <pre style="margin:0">DirectPosition geographic = new DirectPosition2D(<var>φ</var>, <var>λ</var>);
+Matrix jacobian = <var><b>P</b></var>.derivative(geographic);
+double dx_dλ = jacobian.getElement(0,1);
+double dy_dφ = jacobian.getElement(1,0);</pre>
+        </td>
+      </tr>
+    </table>
+
+    <p>
+      Les équations suivantes dans cette section abrégeront
+      ∂<var>x</var>(<var>φ</var>, <var>λ</var>) par ∂<var>x</var> ainsi que
+      ∂<var>y</var>(<var>φ</var>, <var>λ</var>) par ∂<var>y</var>,
+      mais il faut garder à l’esprit que chacune de ces valeurs dépendent de la coordonnée (<var>φ</var>, <var>λ</var>) donnée au moment du calcul de la matrice Jacobienne.
+      La première colonne de la matrice nous dit que si l’on effectue un petit déplacement de ∂<var>φ</var> degrés de latitude
+      à partir de la position (<var>φ</var>, <var>λ</var>)
+      — c’est-à-dire si on se déplace à la position geographique (<var>φ</var> + ∂<var>φ</var>, <var>λ</var>) —
+      alors la coordonnée projetée subira un déplacement de (∂<var>x</var>, ∂<var>λ</var>) metres
+      — c’est-à-dire qu’elle deviendra (<var>x</var> + ∂<var>x</var>, <var>y</var> + ∂<var>λ</var>).
+      De même la dernière colonne de la matrice nous indique quel sera le déplacement que subira la coordonnée projetée
+      si on effectue un petit déplacement de ∂<var>λ</var> degrés de longitude de la coordonnée géographique source.
+      On peut se représenter visuellement ces déplacements comme ci-dessous.
       Cette figure représente la dérivée en deux points, <var>P</var><sub>1</sub> et <var>P</var><sub>2</sub>,
       pour mieux illustrer le fait que le résultat varie en chaque point.
       Dans cette figure, les vecteurs <var>U</var> et <var>V</var> désignent respectivement
-      la première et deuxième colonne des matrices de dérivées.
+      la première et deuxième colonne des matrices Jacobiennes.
     </p>
 
     <table class="hidden"><tr>
@@ -492,10 +532,10 @@ public class MyApp {
               <mfenced open="[" close="]">
                 <mtable>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
                   </mtr>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
                   </mtr>
                 </mtable>
               </mfenced>
@@ -506,10 +546,10 @@ public class MyApp {
               <mfenced open="[" close="]">
                 <mtable>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>x</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
                   </mtr>
                   <mtr>
-                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>φ</mi></mrow></mfrac></mtd>
+                    <mtd><mfrac><mrow><mo>∂</mo><mi>y</mi></mrow><mrow><mo>∂</mo><mi>λ</mi></mrow></mfrac></mtd>
                   </mtr>
                 </mtable>
               </mfenced>

Modified: sis/site/trunk/content/book/book.css
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/book.css?rev=1762098&r1=1762097&r2=1762098&view=diff
==============================================================================
--- sis/site/trunk/content/book/book.css (original)
+++ sis/site/trunk/content/book/book.css Fri Sep 23 22:41:58 2016
@@ -29,6 +29,14 @@ ul.toc ul {
 }
 
 /*
+ * Other kind of lists
+ */
+ul.verbose li {
+  margin-top: 4px;
+  margin-bottom: 4px;
+}
+
+/*
  * Definition list
  */
 dl {



Mime
View raw message