sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1794656 [8/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/
Date Tue, 09 May 2017 23:04:36 GMT
Copied: sis/site/trunk/book/en/referencing/Referencing.html (from r1794573, sis/site/trunk/book/en/referencing.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/referencing/Referencing.html?p2=sis/site/trunk/book/en/referencing/Referencing.html&p1=sis/site/trunk/book/en/referencing.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/en/referencing.html [UTF-8] (original)
+++ sis/site/trunk/book/en/referencing/Referencing.html [UTF-8] Tue May  9 23:04:35 2017
@@ -20,16 +20,15 @@
   under the License.
 -->
 
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
-      xmlns:xi = "http://www.w3.org/2001/XInclude">
+<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en">
   <head>
-    <title>Spatial reference systems</title>
+    <title>Referencing</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/en/developer-guide.html"
+      Content below this point is copied in "(…)/content/book/en/developer-guide.html" file
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
@@ -129,774 +128,9 @@
         Those types will be discussed in <a href="#CoordinateOperation">another section</a>.
       </p>
 
-
-
-      <h2 id="CRS_Components">Components of a reference system by coordinates</h2>
-      <p>
-        Spatial reference systems by coordinates provide necessary information for mapping numerical coordinate values
-        to real-world locations. In Apache <abbr>SIS</abbr>, most information is contained (directly or indirectly) in
-        classes with a name ending in <abbr>CRS</abbr>, the abbreviation of <i>Coordinate Reference System</i>.
-        Those objects contain:
-      </p>
-      <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, especially when using map projections.</li>
-      </ul>
-      <p>
-        Those systems are described by the <abbr>ISO</abbr> 19111 standard (<i>Referencing by Coordinates</i>),
-        which replaces for most parts the older <abbr>OGC 01-009</abbr> standard (<i>Coordinate Transformation Services</i>).
-        Those standards are completed by two other standards defining exchange formats:
-        <abbr>ISO</abbr> 19136 and 19162 respectively for the
-        <cite>Geographic Markup Language</cite> (<abbr>GML</abbr>) — a <abbr>XML</abbr> format which is quite detailed but verbose —
-        and the <cite>Well-Known Text</cite> (<abbr>WKT</abbr>) — a text format easier to read by humans.
-      </p>
-
-      <h3 id="Ellipsoid">Geoid et ellipsoid</h3>
-      <p>
-        Since the real topographic surface is difficult to represent mathematically, it is not used directly.
-        A slightly more convenient surface is the geoid,
-        a surface where the gravitational field has the same value everywhere (an equipotential surface).
-        This surface is perpendicular to the direction of a plumb line at all points.
-        The geoid surface would be equivalent to the mean sea level if all oceans where at rest,
-        without winds or permanent currents like the Gulf Stream.
-      </p><p>
-        While much smoother than topographic surface, the geoid surface still have hollows and bumps
-        caused by the uneven distribution of mass inside Earth.
-        For more convenient mathematical operations, the geoid surface is approximated by an ellipsoid.
-        This “figure of Earth” is represented in GeoAPI by the <code>Ellipsoid</code> interface,
-        a fundamental component in coordinate reference systems of kind <code>GeographicCRS</code> and <code>ProjectedCRS</code>.
-        Tenth of ellipsoids are commonly used for datum definitions.
-        Some of them provide a very good approximation for a particular geographic area
-        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>
-        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>
-
-      <h3 id="GeodeticDatum">Geodetic datum</h3>
-      <p>
-        For defining a geodetic system in a country, a national authority selects an ellipsoid matching closely the country surface.
-        Differences between that ellipsoid and the geoid’s hollows and bumps are usually less than 100 metres.
-        Parameters that relate an <code>Ellipsoid</code> to the Earth surface (for example the position of ellipsoid center)
-        are represented by instances of <code>GeodeticDatum</code>.
-        Many <code>GeodeticDatum</code> definitions can use the same <code>Ellipsoid</code>,
-        but with different orientations or center positions.
-      </p><p>
-        Before the satellite era, geodetic measurements were performed exclusively from Earth surface.
-        Consequently, two islands or continents not in range of sight from each other were not geodetically related.
-        So the <cite>North American Datum 1983</cite> (<abbr>NAD83</abbr>) and the <cite>European Datum 1950</cite> (<abbr>ED50</abbr>)
-        are independent: their ellipsoids have different sizes and are centered at a different positions.
-        The same geographic coordinate will map different locations on Earth depending on whether the coordinate
-        uses one reference system or the other.
-      </p><p>
-        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> 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.
-      </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.
-        The Earth moves under the effect of plate tectonic and new systems are defined every years for taking that fact in account.
-        For example while <abbr>NAD83</abbr> was originally defined as practically equivalent to <abbr>WGS84</abbr>,
-        there is now (as of 2016) a 1.5 metres difference.
-        The <cite>Japanese Geodetic Datum 2000</cite> was also defined as practically equivalent to <abbr>WGS84</abbr>,
-        but the <cite>Japanese Geodetic Datum 2011</cite> now differs.
-        Even the <abbr>WGS84</abbr> datum, which was a terrestrial model realization at a specific time,
-        got revisions because of improvements in instruments accuracy.
-        Today, at least six <abbr>WGS84</abbr> versions exist.
-        Furthermore many borders were legally defined in legacy datums, for example <abbr>NAD27</abbr> in <abbr>USA</abbr>.
-        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>
-
-      <h3 id="CoordinateSystem">Coordinate systems</h3>
-      <p style="color: red">TODO</p>
-
-      <h4 id="AxisOrder">Axis order</h4>
-      <p>
-        The axis order is specified by the authority (typically a national agency) defining the <cite>Coordinate Reference System</cite> (<abbr>CRS</abbr>).
-        The order depends on the <abbr>CRS</abbr> type and the country defining the <abbr>CRS</abbr>.
-        In the case of geographic <abbr>CRS</abbr>, the (<var>latitude</var>, <var>longitude</var>) axis order is widely used by geographers and pilots for centuries.
-        However software developers tend to consistently use the (<var>x</var>, <var>y</var>) order for every kind of <abbr>CRS</abbr>.
-        Those different practices resulted in contradictory definitions of axis order for almost every <abbr>CRS</abbr> of kind <code>GeographicCRS</code>,
-        for some <code>ProjectedCRS</code> in the South hemisphere (South Africa, Australia, <i>etc.</i>) and for some polar projections among others.
-      </p><p>
-        Recent <abbr>OGC</abbr> standards mandate the use of axis order as defined by the authority.
-        Oldest <abbr>OGC</abbr> standards used the (<var>x</var>, <var>y</var>) axis order instead, ignoring any authority specification.
-        Many softwares still use the old (<var>x</var>, <var>y</var>) axis order,
-        maybe because such uniformization makes <abbr>CRS</abbr> implementation and usage <em>apparently</em> easier.
-        Apache <abbr>SIS</abbr> supports both conventions with the following approach:
-        by default, <abbr>SIS</abbr> creates <abbr>CRS</abbr> with axis order <em>as defined by the authority</em>.
-        Those <abbr>CRS</abbr> are created by calls to the <code>CRS.forCode(String)</code> method
-        and the actual axis order can be verified after the <abbr>CRS</abbr> creation with <code>System.out.println(crs)</code>.
-        But if (<var>x</var>, <var>y</var>) axis order is wanted for compatibility with older <abbr>OGC</abbr> specifications or other softwares,
-        then <abbr>CRS</abbr> forced to <cite>longitude first</cite> axis order can be created by a call to the following method:
-      </p>
-
-<pre>CoordinateReferenceSystem crs = …;               // CRS obtained by any means.
-crs = AbstractCRS.castOrCopy(crs).forConvention(AxesConvention.RIGHT_HANDED)</pre>
-
-      <p>
-        Among the legacy <abbr>OGC</abbr> standards that used the non-conform axis order,
-        an influent one is version 1 of the <cite>Well Known Text</cite> (<abbr>WKT</abbr>) format specification.
-        According that widely-used format, <abbr>WKT</abbr> 1 definitions without explicit <code>AXIS[…]</code> elements
-        shall default to (<var>longitude</var>, <var>latitude</var>) or (<var>x</var>, <var>y</var>) axis order.
-        In version 2 of <abbr>WKT</abbr> format, <code>AXIS[…]</code> elements are no longer optional
-        and should contain an explicit <code>ORDER[…]</code> sub-element for making the intended order yet more obvious.
-        But if <code>AXIS[…]</code> elements are nevertheless missing in a <abbr>WKT</abbr> 2 definition,
-        Apache <abbr>SIS</abbr> defaults to (<var>latitude</var>, <var>longitude</var>) order.
-        So in summary:
-      </p>
-      <ul>
-        <li>Default <abbr>WKT</abbr> 1 axis order of geographic <abbr>CRS</abbr> is (<var>longitude</var>, <var>latitude</var>) as mandated by <abbr>OGC</abbr> 01-009 specification.</li>
-        <li>Default <abbr>WKT</abbr> 2 axis order of geographic <abbr>CRS</abbr> is (<var>latitude</var>, <var>longitude</var>),
-            but this is <abbr>SIS</abbr>-specific as <abbr>ISO</abbr> 19162 does not mention default axis order.</li>
-      </ul>
-      <p>
-        To avoid ambiguities, users are encouraged to always provide explicit <code>AXIS[…]</code> elements in their <abbr>WKT</abbr>.
-        The <abbr>WKT</abbr> format will be presented in more details in the next sections.
-      </p>
-
-      <h3 id="GeographicCRS">Geographic reference systems</h3>
-      <p style="color: red">TODO</p>
-
-      <h4 id="GeographicWKT"><i>Well-Known Text</i> format</h4>
-      <p style="color: red">TODO</p>
-
-      <h3 id="ProjectedCRS">Map projections</h3>
-      <p>
-        Map projections represent a curved surface (the Earth) on a plane surface (a map or a computer screen)
-        with some control over deformations: one can preserve either the angles or the areas, but not both in same time.
-        The geometric properties to preserve depend on the feature to represent and the work to do on that feature.
-        For example countries elongated along the East-West axis often use a Lambert projection,
-        while countries elongated along the North-South axis prefer a Transverse Mercator projection.
-      </p>
-      <p style="color: red">TODO</p>
-
-      <h4 id="ProjectedWKT"><i>Well-Known Text</i> format</h4>
-      <p style="color: red">TODO</p>
-
-      <h3 id="CompoundCRS">Vertical and temporal dimensions</h3>
-      <p style="color: red">TODO</p>
-
-      <h4 id="CompoundWKT"><i>Well-Known Text</i> format</h4>
-      <p style="color: red">TODO</p>
-
-
-
-      <h2 id="GetCRS">Fetching a spatial reference system</h2>
-      <p style="color: red">TODO</p>
-
-      <h3 id="CRSAuthorityFactory">Looking <abbr>CRS</abbr> defined by authorities</h3>
-      <p style="color: red">TODO</p>
-
-      <h3 id="CRSParsing">Reading definitions in GML or WKT format</h3>
-      <p style="color: red">TODO</p>
-
-      <h3 id="CRSFactory">Constructing programmatically</h3>
-      <p style="color: red">TODO</p>
-
-      <h3 id="CRS_UserCode">Adding new <abbr>CRS</abbr> definitions</h3>
-      <p style="color: red">TODO</p>
-
-
-
-      <h2 id="CoordinateOperation">Coordinate operations</h2>
-      <p>
-        Given a <em>source</em> coordinate reference system (<abbr>CRS</abbr>) in which existing coordinate values are expressed,
-        and a <em>target</em> coordinate reference system in which coordinate values are desired,
-        Apache <abbr>SIS</abbr> can provide a <em>coordinate operation</em> performing the conversion or transformation work.
-        The search for coordinate operations may use a third argument, optional but recommended,
-        which is the geographic area of the data to transform.
-        That later argument is recommended because coordinate operations are often valid only in a some geographic area
-        (typically a particular country or state), and many transformations may exist
-        for the same pair of source and target <abbr>CRS</abbr> but different domain of validity.
-        Different coordinate operations may also be different compromises between accuracy and their domain of validity,
-        and specifying a smaller area of interest may allow Apache <abbr>SIS</abbr> to select a more accurate operation.
-      </p>
-      <div class="example"><p><b>Example:</b>
-        the <abbr>EPSG</abbr> geodetic dataset (as of version 7.9) defines 77 coordinate operations from the
-        <cite>North American Datum 1927</cite> (EPSG:4267) coordinate reference system to the
-        <cite>World Geodetic System 1984</cite> (EPSG:4326) <abbr>CRS</abbr>.
-        There is one operation valid only for coordinate transformations in Québec,
-        another operation valid for coordinate transformations in Texas west of 100°W,
-        another operation for the same state but east of 100°W, <i>etc</i>.
-        If the user did not specified any geographic area of interest,
-        then Apache <abbr>SIS</abbr> defaults on the coordinate operation which is valid in the largest area.
-        In this example, the “largest area” criterion results in the selection of a coordinate operation valid for Canada,
-        not <abbr>USA</abbr>.</p>
-      </div>
-      <p>
-        The easiest way to obtain a coordinate operation from above-cited information
-        is to use the <code>org.apache.sis.referencing.CRS</code> convenience class:
-      </p>
-
-<pre>CoordinateOperation cop = CRS.findOperation(sourceCRS, targetCRS, areaOfInterest);</pre>
-
-      <p>
-        Among the information provided by <code>CoordinateOperation</code> object, the following are of special interest:
-      </p>
-      <ul>
-        <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. 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>
-        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.
-        But more advanced applications will typically use <abbr>EPSG</abbr> codes instead.
-        Note that all geographic coordinates below express latitude before longitude.
-      </p>
-
-<pre>import org.opengis.geometry.DirectPosition;
-import org.opengis.referencing.crs.CoordinateReferenceSystem;
-import org.opengis.referencing.operation.CoordinateOperation;
-import org.opengis.referencing.operation.TransformException;
-import org.opengis.util.FactoryException;
-import org.apache.sis.referencing.CRS;
-import org.apache.sis.referencing.CommonCRS;
-import org.apache.sis.geometry.DirectPosition2D;
-
-public class MyApp {
-    public static void main(String[] args) throws FactoryException, TransformException {
-        CoordinateReferenceSystem sourceCRS = CommonCRS.WGS84.geographic();
-        CoordinateReferenceSystem targetCRS = CommonCRS.WGS84.UTM(40, 14);  // Get whatever zone is valid for 14°E.
-        CoordinateOperation operation = CRS.findOperation(sourceCRS, targetCRS, null);
-
-        // The above lines are costly and should be performed only once before to project many points.
-        // In this example, the operation that we got is valid for coordinates in geographic area from
-        // 12°E to 18°E (UTM zone 33) and 0°N to 84°N.
-
-        DirectPosition ptSrc = new DirectPosition2D(40, 14);           // 40°N 14°E
-        DirectPosition ptDst = operation.getMathTransform().transform(ptSrc, null);
-
-        System.out.println("Source: " + ptSrc);
-        System.out.println("Target: " + ptDst);
-    }
-}</pre>
-
-
-      <h3 id="TransformDerivative">Partial derivatives of coordinate operations</h3>
-      <p>
-        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>
-
-      <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>
-        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>
-        <td><img style="border: solid 1px" src="../../content/book/images/Derivatives.png" alt="Exemple de dérivées d’une projection cartographique"/></td>
-        <td style="padding-left: 30px; vertical-align: middle">
-          <p>where vectors are related to the matrix by:</p>
-          <math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="MathML capable browser required">
-            <mtable><mtr>
-              <mtd>
-                <mover><mi>U</mi><mo>→</mo></mover><mo>=</mo>
-                <mfenced open="[" close="]">
-                  <mtable>
-                    <mtr>
-                      <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>
-                    </mtr>
-                  </mtable>
-                </mfenced>
-              </mtd>
-              <mtd><mtext>et</mtext></mtd>
-              <mtd>
-                <mover><mi>V</mi><mo>→</mo></mover><mo>=</mo>
-                <mfenced open="[" close="]">
-                  <mtable>
-                    <mtr>
-                      <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>
-                    </mtr>
-                  </mtable>
-                </mfenced>
-              </mtd>
-            </mtr></mtable>
-          </math>
-        </td>
-      </tr></table>
-
-      <p>
-        Above figure shows one usage of map projection derivatives:
-        they provide the direction of parallels and meridians at a given location in a map projection.
-        One can use that information for determining if axes have been swapped or their direction reversed.
-        But the usefulness of map projection derivatives goes further.
-      </p>
-
-      <h4 id="DerivativeAndEnvelope">Transform derivatives applied to envelopes</h4>
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-      <table class="hidden">
-        <tr>
-          <th>Envelope before projection</th>
-          <th>Geometric shape after projection</th>
-        </tr>
-        <tr>
-          <td><img style="border: solid 1px; margin-right: 15px" src="../../content/book/images/GeographicArea.png" alt="Envelope in a geographic CRS"/></td>
-          <td><img style="border: solid 1px; margin-left:  15px" src="../../content/book/images/ConicArea.png" alt="Shape in a projected CRS"/></td>
-        </tr>
-      </table>
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-      <table class="hidden"><tr><td>
-        <img src="../../content/book/images/Approximation.png" alt="Cubic approximation of an envelope bounds"/>
-      </td><td style="padding-left: 60px">
-        Legend:
-        <ul>
-          <li><b>Blue:</b> the geometric shape of the envelope after projection.
-            This is the shape from which to get a new envelope.</li>
-          <li><b>Red</b> (with hash): The
-            <var>y</var> = <var>C</var>₀ + <var>C</var>₁λ + <var>C</var>₂λ² + <var>C</var>₃λ³ approximation.</li>
-          <li><b>Green</b> (dashed line): Position λ<sub>m</sub> of approximation minimum, obtained by resolving
-            0 = <var>C</var>₁ + 2<var>C</var>₂λ<sub>m</sub> + 3<var>C</var>₃λ<sub>m</sub>².
-            The same cubic line can have two minimums.</li>
-        </ul>
-      </td></tr></table>
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-
-
-      <h4 id="DerivativeAndRaster">Transform derivatives applied to rasters</h4>
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-      <table class="hidden">
-        <tr>
-          <th style="text-align: left">Source image</th>
-          <th style="text-align: right">Destination image</th>
-        </tr>
-        <tr>
-          <td colspan="2"><img src="../../content/book/images/RasterProjection.png" alt="Intersection of derivatives"/></td>
-        </tr>
-      </table>
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-      <table class="hidden"><tr>
-        <td><img src="../../content/book/images/WarpGrid.png" alt="Intersection of derivatives"/></td>
-        <td style="padding-left: 60px">
-        Legend:
-        <ul>
-          <li><b>Blue dots:</b>  first  iteration (9 points).</li>
-          <li><b>Green dots:</b> second iteration (25 points, including 16 news).</li>
-          <li><b>Red dots:</b>   third  iteration (81 points, including 56 news).</li>
-        </ul>
-        Continuing…
-        <ul>
-          <li>Forth iteration:  289 points, including  208 news.</li>
-          <li>Fifth iteration: 1089 points, including  800 news.</li>
-          <li>Sixth iteration: 4225 points, including 3136 news.</li>
-          <li>…</li>
-        </ul>
-      </td></tr></table>
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-      <p style="text-align:center"><img style="border: solid 1px" src="../../content/book/images/IntersectionOfDerivatives.png" alt="Intersection of derivatives"/></p>
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-
-      <h4 id="GetDerivative">Getting the derivative at a point</h4>
-      <p>
-        <span style="color: red">TODO</span>
-        Example:</p>
-
-<pre>AbstractMathTransform projection = ...;         // An Apache SIS map projection.
-double[] sourcePoint = {longitude, latitude};   // The geographic coordinate to project.
-double[] targetPoint = new double[2];           // Where to store the projection result.
-Matrix   derivative  = projection.<code class="SIS">transform</code>(sourcePoint, 0, targetPoint, 0, true);</pre>
-
-      <p>
-        <span style="color: red">TODO</span>
-      </p>
-
-<pre>@Override
-public Matrix derivative(DirectPosition p) throws TransformException {
-    Matrix jac = inverse().derivative(transform(p));
-    return Matrices.inverse(jac);
-}</pre>
-
-
-      <h3 id="CoordinateOperationSteps">Conceptual versus real chain of coordinate operations</h3>
-      <p>
-        Coordinate operations may include many steps, each with their own set of parameters.
-        For example transformations from one datum (e.g. <abbr>NAD27</abbr>) to another datum (e.g. <abbr>WGS84</abbr>)
-        can be approximated by an affine transform (translation, rotation and scale) applied on the <em>geocentric</em> coordinates.
-        This implies that the coordinates must be converted from <em>geographic</em> to geocentric domain before the affine transform,
-        then back to geographic domain after the affine transform.
-        The result is a three-steps process illustrated in the “Conceptual chain of operations” column of the example below.
-        However because that operation chain is very common, the <abbr>EPSG</abbr> geodetic dataset provides a shortcut
-        named “Geocentric translation <em>in geographic domain</em>”.
-        Using this operation, the conversion steps between geographic and geocentric <abbr>CRS</abbr> are implicit.
-        Consequently the datum shifts as specified by <abbr>EPSG</abbr> appears as if it was a single operation,
-        but this is not the real operation executed by Apache <abbr>SIS</abbr>.
-      </p>
-
-      <div class="example"><p><b>Example:</b>
-        transformation of geographic coordinates from <abbr>NAD27</abbr> to <abbr>WGS84</abbr> in Canada
-        can be approximated by the <abbr>EPSG</abbr>:1172 coordinate operation.
-        This single <abbr>EPSG</abbr> operation is actually a chain of three operations in which two steps are implicit.
-        The operation as specified by <abbr>EPSG</abbr> is shown in the first column below.
-        The same operation with the two hidden steps made explicit is shown in the second column.
-        The last column shows the same operation as implemented by Apache <abbr>SIS</abbr> under the hood,
-        which contains additional operations discussed below.
-        For all columns, input coordinates of the first step and output coordinates of the last step
-        are (<var>latitude</var>, <var>longitude</var>) coordinates in degrees.
-        </p>
-        <div style="display:flex; padding-left:24px">
-          <div style="width:30%; padding-right:15px; border-right:1px solid">
-            <b>Operation specified by <abbr>EPSG</abbr>:</b>
-            <ol>
-              <li><b>Geocentric translation</b> in <em>geographic</em> domain
-                <ul>
-                  <li>X-axis translation = -10 m</li>
-                  <li>Y-axis translation = 158 m</li>
-                  <li>Z-axis translation = 187 m</li>
-                </ul>
-              </li>
-            </ol>
-            Conversions between geographic and geocentric domains are implicit.
-            The semi-major and semi-minor axis lengths required for those conversions
-            are inferred from the source and target datum.
-          </div>
-          <div style="width:30%; padding-left:30px; padding-right:15px; border-right:1px solid">
-            <b>Conceptual chain of operations:</b>
-            <ol>
-              <li><b>Geographic to geocentric</b> conversion
-                <ul>
-                  <li>Source semi-major = 6378206.4 m</li>
-                  <li>Source semi-minor = 6356583.8 m</li>
-                </ul>
-              </li><li><b>Geocentric translation</b>
-                <ul>
-                  <li>X-axis translation = -10 m</li>
-                  <li>Y-axis translation = 158 m</li>
-                  <li>Z-axis translation = 187 m</li>
-                </ul>
-              </li><li><b>Geocentric to geographic</b> conversion
-                <ul>
-                  <li>Target semi-major = 6378137.0 m</li>
-                  <li>Target semi-minor ≈ 6356752.3 m</li>
-                </ul>
-              </li>
-            </ol>
-            Axis order and units are implicitly defined by the source and target <abbr>CRS</abbr>.
-            It is implementation responsibility to perform any needed unit conversions and/or axis swapping.
-          </div>
-          <div style="width:30%; padding-left:30px">
-            <b>Operations actually performed by Apache <abbr>SIS</abbr>:</b>
-            <ol>
-              <li><b>Affine parametric</b> conversion
-                <ul>
-                  <li>Scale factors (λ and φ) = 0</li>
-                  <li>Shear factors (λ and φ) = π/180</li>
-                </ul>
-              </li><li>Ellipsoid (radians domain) to centric conversion
-                <ul>
-                  <li>Eccentricity ≈ 0.08227</li>
-                </ul>
-              </li><li><b>Affine parametric transformation</b>
-                <ul>
-                  <li>Scale factors (X, Y and Z) ≈ 1.00001088</li>
-                  <li>X-axis translation ≈ -1.568 E-6</li>
-                  <li>Y-axis translation ≈ 24.772 E-6</li>
-                  <li>Z-axis translation ≈ 29.319 E-6</li>
-                </ul>
-              </li><li>Centric to ellipsoid (radians domain) conversion
-                <ul>
-                  <li>Eccentricity ≈ 0.08182</li>
-                </ul>
-              </li><li><b>Affine parametric</b> conversion
-                <ul>
-                  <li>Scale factors (λ and φ) = 0</li>
-                  <li>Shear factors (λ and φ) = 180/π</li>
-                </ul>
-              </li>
-            </ol>
-          </div>
-        </div>
-        <p>
-          The operation chain actually performed by Apache <abbr>SIS</abbr> is very different than the conceptual operation chain
-          because the coordinate systems are not the same.
-          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).
-          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,
-          which allow to combine axes swapping and unit conversions in a single step
-          (see <a href="#AffineTransform">affine transform</a> for more information).
-          The reason why Apache <abbr>SIS</abbr> splits conceptual operations in such fine-grained operations
-          is to allow more efficient concatenations of operation steps.
-          This approach often allows cancellation of two consecutive affine transforms,
-          for example a conversion from radians to degrees (e.g. after a <cite>geocentric to ellipsoid</cite> conversion)
-          immediately followed by a conversion from degrees to radians (e.g. before a map projection).
-          Another example is the <cite>Affine parametric transformation</cite> step above,
-          which combines both the <cite>geocentric translation</cite> step
-          and a scale factor implied by the ellipsoid change.
-        </p>
-      </div>
-      <p>
-        All those operation chains can be viewed in <cite>Well Known Text</cite> (<abbr>WKT</abbr>) or pseudo-<abbr>WKT</abbr> format.
-        The simplest operation chain, as specified by the authority, is given directly by the
-        <code>String</code> representation of the <code>CoordinateOperation</code> instance.
-        This <abbr>WKT</abbr> 2 representation contains not only a description of operations with their parameter values,
-        but also additional information about the context in which the operation applies (the source and target <abbr>CRS</abbr>)
-        together with some metadata like the accuracy and domain of validity.
-        Some operation steps and parameters may be omitted if they can be inferred from the context.
-      </p>
-      <div class="example">
-        <div style="display:flex; padding-left:24px; padding-right:24px">
-          <div>
-            <p><b>Example:</b>
-              the <abbr>WKT</abbr> 2 representation on the right is for the same coordinate operation than the one used in previous example.
-              This representation can be obtained by a call to <code>System.out.println(cop)</code>
-              where <code>cop</code> is a <code>CoordinateOperation</code> instance.
-              Some characteristics of this representation are:
-            </p>
-            <ul>
-              <li><p>The <code>SourceCRS</code> and <code>TargetCRS</code> elements determine axis order and units.
-                  For this reason, axis swapping and unit conversions do not need to be represented in this <abbr>WKT</abbr>.</p></li>
-              <li><p>The “Geocentric translation in geographic domain” operation implies conversions between geographic and geocentric coordinate reference systems.
-                  Ellipsoid semi-axis lengths are inferred from above <code>SourceCRS</code> and <code>TargetCRS</code> elements,
-                  so they do not need to be specified in this <abbr>WKT</abbr>.</p></li>
-              <li><p>The operation accuracy (20 metres) is much greater than the numerical floating-point precision.
-                  This kind of metadata could hardly be guessed from the mathematical function alone.</p></li>
-            </ul>
-          </div>
-          <div>
-
-<pre>CoordinateOperation["NAD27 to WGS 84 (3)",
-  SourceCRS[<span style="font-family:serif"><i>full CRS definition required here but omitted for brevity</i></span>],
-  TargetCRS[<span style="font-family:serif"><i>full CRS definition required here but omitted for brevity</i></span>],
-  Method["Geocentric translations (geog2D domain)"],
-    Parameter["X-axis translation", -10.0, Unit["metre", 1]],
-    Parameter["Y-axis translation", 158.0, Unit["metre", 1]],
-    Parameter["Z-axis translation", 187.0, Unit["metre", 1]],
-  OperationAccuracy[20.0],
-  Area["Canada - onshore and offshore"],
-  BBox[40.04, -141.01, 86.46, -47.74],
-  Id["EPSG", 1172, "8.9"]]</pre>
-
-          </div>
-        </div>
-      </div>
-      <p>
-        An operation chain closer to what Apache <abbr>SIS</abbr> really performs is given by the
-        <code>String</code> representation of the <code>MathTransform</code> instance.
-        In this <abbr>WKT</abbr> 1 representation, contextual information and metadata are lost;
-        a <code>MathTransform</code> is like a mathematical function with no knowledge about the meaning of the coordinates on which it operates.
-        Since contextual information are lost, implicit operations and parameters become explicit.
-        This representation is useful for debugging since any axis swapping operation (for example) become visible.
-        Apache <abbr>SIS</abbr> constructs this representation from the data structure in memory,
-        but convert them in a more convenient form for human, for example by converting radians to degrees.
-      </p>
-      <div class="example">
-        <div style="display:flex; padding-left:24px; padding-right:24px">
-          <div>
-            <p><b>Example:</b>
-              the <abbr>WKT</abbr> 1 representation on the right is for the same coordinate operation than the one used in previous example.
-              This representation can be obtained by a call to <code>System.out.println(cop.getMathTransform())</code>
-              where <code>cop</code> is a <code>CoordinateOperation</code> instance.
-              Some characteristics of this representation are:
-            </p>
-            <ul>
-              <li><p>Since there is not anymore (on intend) any information about source and target <abbr>CRS</abbr>,
-                  axis swapping (if needed) and unit conversions must be performed explicitly.
-                  This is the task of the first and last affine operations in this <abbr>WKT</abbr>.</p></li>
-              <li><p>The “Geocentric translation” operation is not anymore applied in the geographic domain, but in the geocentric domain.
-                  Consequently conversions between geographic and geocentric coordinate reference systems must be made explicit.
-                  Those explicit steps are also necessary for specifying the ellipsoid semi-axis lengths,
-                  since they can not anymore by inferred for source and target <abbr>CRS</abbr>.</p></li>
-              <li><p>Conversions between geographic and geocentric coordinates are three-dimensional.
-                  Consequently operations for increasing and reducing the number of dimensions are inserted.
-                  By default the ellipsoidal height before conversion is set to zero.</p></li>
-            </ul>
-          </div>
-          <div>
-
-<pre>Concat_MT[
-  Param_MT["Affine parametric transformation",
-    Parameter[<span style="font-family:serif"><i>parameters performing axis swapping omitted for brevity</i></span>]],
-  Inverse_MT[Param_MT["Geographic3D to 2D conversion"]],
-  Param_MT["Geographic/geocentric conversions",
-    Parameter["semi_major", 6378206.4],
-    Parameter["semi_minor", 6356583.8]],
-  Param_MT["Geocentric translations (geocentric domain)",
-    Parameter["X-axis translation", -10.0],
-    Parameter["Y-axis translation", 158.0],
-    Parameter["Z-axis translation", 187.0]],
-  Param_MT["Geocentric_To_Ellipsoid",
-    Parameter["semi_major", 6378137.0],
-    Parameter["semi_minor", 6356752.314245179]],
-  Param_MT["Geographic3D to 2D conversion"],
-  Param_MT["Affine parametric transformation",
-    Parameter[<span style="font-family:serif"><i>parameters performing axis swapping omitted for brevity</i></span>]]]</pre>
-
-          </div>
-        </div>
-      </div>
-      <p>
-        Finally, the raw operation chain can be view by a call to <code>AbstractMathTransform.toString(Convention.INTERNAL)</code>.
-        This pseudo-<abbr>WKT</abbr> representation shows exactly what Apache <abbr>SIS</abbr> does,
-        but is rarely used because difficult to read.
-        It may occasionally be useful for advanced debugging.
-      </p>
+      <xi:include href="ComponentsOfCRS.html"/>
+      <xi:include href="GetCRS.html"/>
+      <xi:include href="CoordinateOperations.html"/>
     </section>
   </body>
 </html>

Copied: sis/site/trunk/book/en/utility/ComparisonModes.html (from r1794573, sis/site/trunk/book/en/utility.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/utility/ComparisonModes.html?p2=sis/site/trunk/book/en/utility/ComparisonModes.html&p1=sis/site/trunk/book/en/utility.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/en/utility.html [UTF-8] (original)
+++ sis/site/trunk/book/en/utility/ComparisonModes.html [UTF-8] Tue May  9 23:04:35 2017
@@ -22,26 +22,20 @@
 
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
   <head>
-    <title>Utility classes and methods</title>
+    <title>ComparisonModes</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/en/developer-guide.html"
+      Content below this point is copied in "(…)/content/book/en/developer-guide.html" file
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
       <header>
-        <h1 id="Utilities">Utility classes and methods</h1>
+        <h2 id="ComparisonModes">Comparison modes of objects</h2>
       </header>
       <p>
-        This chapter describes aspects of Apache <abbr>SIS</abbr> that apply to the entire library.
-        Most of these utilities are not specific to spatial information systems.
-      </p>
-
-      <h2 id="ComparisonMode">Comparison modes of objects</h2>
-      <p>
         There are various opinions on how to implement Java standard’s <code>Object.equals(Object)</code> method.
         According to some, it should be possible to compare different implementations of the same interface or base class.
         But to follow this policy, each interface or base class’s javadoc must define the algorithms that all implementations
@@ -110,282 +104,6 @@
         (and so by extension all other modes that depend on it) only compares the properties known to <code>A</code>,
         regardless of whether <code>B</code> knows more.
       </p>
-
-
-
-      <h2 id="ObjectConverters">Object converters</h2>
-      <p>
-        There is sometime a need to convert instances from a <var>source</var> Java type to a <var>target</var> Java type
-        while those types are unknown at compile time.
-        Various projects (Apache Common Convert, Spring, <i>etc.</i>)
-        have created their own interface for performing object conversions between types known only at runtime.
-        Details vary, but such interfaces typically look like below:
-      </p>
-
-<pre>interface ObjectConverter&lt;S,T&gt; {   // Some projects use only "Converter" as interface name.
-    T apply(S object);             // Another method name commonly found in other projects is "convert".
-}</pre>
-
-      <p>
-        Like other projects, Apache <abbr>SIS</abbr> also defines its own <code>ObjectConverter</code> interface.
-        The main difference between <abbr>SIS</abbr> converter interface and the interfaces found in other projects
-        is that <abbr>SIS</abbr> converters provide some information about their mathematical properties.
-        An Apache <abbr>SIS</abbr> converter can have zero, one or many of the following properties:
-      </p>
-      <dl>
-        <dt><dfn>Injective</dfn></dt>
-        <dd>A function is injective if no pair of <var>S</var> values can produce the same <var>T</var> value.
-          <div class="example"><p><b>Example:</b>
-              the <code>Integer</code> → <code>String</code> conversion performed by <code>Integer.toString()</code>
-              is an <cite>injective</cite> function because if two <code>Integer</code> values are not equal,
-              then it is guaranteed that their conversions will result in different <code>String</code> values.
-              However the <code>String</code> → <code>Integer</code> conversion performed by <code>Integer.valueOf(String)</code>
-              is <strong>not</strong> an injective function
-              because many distinct <code>String</code> values can be converted to the same <code>Integer</code> value.
-              For example converting the "42", "+42" and "0042" character strings all result in the same 42 integer value.
-          </p></div>
-        </dd>
-
-        <dt><dfn>Surjective</dfn></dt>
-        <dd>A function is surjective if each values of <var>T</var> can be created from at least one value of <var>S</var>.
-          <div class="example"><p><b>Example:</b>
-              the <code>String</code> → <code>Integer</code> conversion performed by <code>Integer.valueOf(String)</code>
-              is a <cite>surjective</cite> function because every <code>Integer</code> value can be created from at least one <code>String</code> value.
-              However the <code>Integer</code> → <code>String</code> conversion performed by <code>Integer.toString()</code>
-              is <strong>not</strong> a surjective function because it can not produce all possible <code>String</code> values.
-              For example there is no way to produce the "ABC" value with the <code>Integer.toString()</code> method.
-          </p></div>
-        </dd>
-
-        <dt><dfn>Bijective</dfn></dt>
-        <dd>A function is bijective if there is a one-to-one relationship between <var>S</var> and <var>T</var> values.
-          <div class="example"><p><b>Note:</b>
-            the <cite>bijective</cite> property is defined here for clarity, but actually does not have an explicit item
-            in Apache <abbr>SIS</abbr> <code>FunctionProperty</code> enumeration.
-            It is not necessary since a function that is both <cite>injective</cite> and <cite>surjective</cite> is necessarily bijective.
-          </p></div>
-        </dd>
-
-        <dt><dfn>Order preserving</dfn></dt>
-        <dd>A function is order preserving if any sequence of increasing <var>S</var> values is mapped to a sequence of increasing <var>T</var> values.
-          <div class="example"><p><b>Example:</b>
-            conversion from <code>Integer</code> to <code>Long</code> preserve the natural ordering of elements.
-            However conversions from <code>Integer</code> to <code>String</code> do <strong>not</strong> preserve natural ordering,
-            because some sequences of increasing integer values are ordered differently when their string representations are sorted by lexicographic order.
-            For example 1, 2, 10 become "1", "10", "2".
-          </p></div>
-        </dd>
-
-        <dt><dfn>Order reversing</dfn></dt>
-        <dd>A function is order reversing if any sequence of increasing <var>S</var> values is mapped to a sequence of decreasing <var>T</var> values.
-          <div class="example"><p><b>Example:</b>
-            a conversion that reverses the sign of numbers.
-          </p></div>
-        </dd>
-      </dl>
-      <p>
-        Above information may seem unnecessary when values are converted without taking in account the context in which the values appear.
-        But when the value to convert is part of a bigger object, then above information can affect the way the converted value will be used.
-        For example conversion of a [<var>min</var> … <var>max</var>] range is straightforward when the converter is <cite>order preserving</cite>.
-        But if the converter is <cite>order reversing</cite>, then the minimum and maximum values need to be interchanged.
-        For example if the converter reverses the sign of values, then the converted range is [-<var>max</var> … -<var>min</var>].
-        If the converter is neither order preserving or order reversing, then range conversion is not allowed at all
-        (because it does not contain the same set of values) even if the minimum and maximum values could be converted individually.
-      </p>
-
-
-
-      <h2 id="Internationalization">Internationalization</h2>
-      <p>
-        In an architecture where a program executed on a server provides its data to multiple clients,
-        the server’s locale conventions are not necessarily the same as those of the clients.
-        Conventions may differ in language, but also in the way they write numeric values
-        (even between two countries that speak the same language) as well in time zone.
-        To produce messages that conform to the client’s conventions, <abbr>SIS</abbr> uses
-        two approaches, distinguished by their level of granularity: at the level of the messages themselves,
-        or at the level of the objects that create the messages.
-        The approach used also determines whether it is possible to share the same instance of an object for all languages.
-      </p>
-
-      <h3 id="LocalizedString">Distinct character sequences for each locale</h3>
-      <p>
-        Some classes are only designed to function according to one locale convention at a time.
-        This is of course true for the standard implementations of <code>java.text.Format</code>,
-        as they are entirely dedicated to the work of internationalization.
-        But it is also the case for other less obvious classes like <code>javax.imageio.ImageReader</code> and <code>ImageWriter</code>.
-        When one of these classes is implemented by <abbr>SIS</abbr>,
-        we identify it by implementing the <code>org.apache.sis.util.Localized</code> interface.
-        The <code class="SIS">getLocale()</code> method of this interface can determine the locale conventions
-        by which the instance produces its message.
-      </p>
-      <p>
-        Another class that provides different methods for different locales is <code>java.lang.Throwable</code>.
-        The standard Java <abbr>API</abbr> defines two methods for getting the error message:
-        <code>getMessage()</code> and <code>getLocalizedMessage()</code>.
-        Usually those two methods return the same character sequences,
-        but some exceptions thrown by Apache <abbr>SIS</abbr> may use different locales.
-        The policy that <abbr>SIS</abbr> tries to apply on a <em>best-effort</em> basis is:
-      </p>
-      <ul>
-        <li><code>getMessage()</code> returns the message in the <abbr title="Java Virtual Machine">JVM</abbr> default locale.
-            In a client-server architecture, this is often the locale on the server side.
-            This is the recommended language for logging messages to be read by system administrators.</li>
-        <li><code>getLocalizedMessage()</code> returns the message in a locale that depends on the context
-            in which the exception has been thrown. This is often the locale used by a particular <code>Format</code>
-            or <code class="SIS">DataStore</code> instance, and can be presumed to be the locale on the client side.
-            This is the recommended language to show in the user application.</li>
-      </ul>
-
-      <div class="example"><p><b>Example:</b>
-        If an error occurred while a Japanese client connected to an European server, the localized message may be sent
-        to the client in Japanese language as given by <code>getLocalizedMessage()</code> while the same error may be
-        logged on the server side in the French (for example) language as given by <code>getMessage()</code>.
-        This allows system administrator to analyze the issue without the need to understand client’s language.
-      </p></div>
-      <p>
-        The utility class <code>org.apache.sis.util.Exceptions</code> provides convenience methods to get messages
-        according to the conventions of a given locale, when this information is available.
-      </p>
-
-
-
-      <h3 id="InternationalString">Single instance for all supported locales</h3>
-      <p>
-        The <abbr>API</abbr> conventions defined by <abbr>SIS</abbr> or inherited by GeoAPI favour the use of the
-        <code>InternationalString</code> type when the value of a <code>String</code> type would likely be localized.
-        This approach allows us to defer the internationalization process to the time when a character sequence is requested,
-        rather than the time when the object that contains them is created.
-        This is particularly useful for immutable classes used for creating unique instances independently of locale conventions.
-      </p>
-      <div class="example"><p><b>Example:</b>
-        <abbr>SIS</abbr> includes only one instance of the <code>OperationMethod</code>
-        type representing the Mercator projection, regardless of the client’s language.
-        But its <code class="GeoAPI">getName()</code> method (indirectly) provides an instance of
-        <code>InternationalString</code>, so that <code>toString(Locale.ENGLISH)</code> returns <cite>Mercator projection</cite>
-        while <code>toString(Locale.FRENCH)</code> returns <cite>Projection de Mercator</cite>.
-      </p></div>
-      <p>
-        When defining spatial objects independently of locale conventions, we reduce the risk of computational overload.
-        For example, it is easier to detect that two maps use the same cartographic projection if this last is represented by the
-        same instance of <code>CoordinateOperation</code>,
-        even if the projection has a different name depending on the country.
-        Moreover, certain types of <code>CoordinateOperation</code> may require coordinate transformation matrices,
-        so sharing a single instance becomes even more preferable in order to reduce memory consumption.
-      </p>
-
-
-
-      <h3 id="Locale.ROOT"><code>Locale.ROOT</code> convention</h3>
-      <p>
-        All <abbr>SIS</abbr> methods receiving or returning the value of a <code>Locale</code> type accept the <code>Locale.ROOT</code> value.
-        This value is interpreted as specifying not to localize the text.
-        The notion of a <cite>non-localized text</cite> is a little false, as it is always necessary to chose a formatting convention.
-        This convention however, though very close to English, is usually slightly different.
-        For example:
-      </p>
-      <ul>
-        <li>
-          Identifiers are written as they appear in <abbr>UML</abbr> diagrams,
-          such as <cite>blurredImage</cite> instead of <cite>Blurred image</cite>.
-        </li>
-        <li>
-          Dates are written according to the <abbr>ISO</abbr> 8601 format,
-          which does not correspond to English conventions.
-        </li>
-        <li>
-          Numbers are written using their <code>toString()</code> methods, rather than using a <code>java.text.NumberFormat</code>.
-          As a result, there are differences in the number of significant digits,
-          use of exponential notation and the absence of thousands separators.
-        </li>
-      </ul>
-
-
-
-      <h3 id="UnicodePoint">Treatment of characters</h3>
-      <p>
-        In Java, sequences of characters use UTF-16 encoding.
-        There is a direct correspondence between the values of the <code>char</code> type and the great majority of characters,
-        which facilitates the use of sequences so long as these characters are sufficient.
-        However, certain Unicode characters cannot be represented by a single <code>char</code>.
-        These <i>supplementary characters</i> include certain ideograms,
-        but also road and geographical symbols in the 1F680 to 1F700 range.
-        Support for these supplementary characters requires slightly more complex interactions than the classic case,
-        where we may assume a direct correspondence.
-        Thus, instead of the loop on the left below, international applications must generally use the loop on the right:
-      </p>
-
-      <table class="hidden">
-        <tr>
-          <th>Loop to Avoid</th>
-          <th>Recommended loop</th>
-          <th>Supplementary character examples</th>
-        </tr>
-        <tr>
-          <td>
-
-<pre style="margin-top: 6pt">for (int i=0; i&lt;string.length(); i++) {
-    char c = string.charAt(i);
-    if (Character.isWhitespace(c)) {
-        // A blank space was found.
-    }
-}</pre>
-
-          </td><td>
-
-<pre style="margin-top: 6pt">for (int i=0; i&lt;string.length();) {
-    int c = string.codePointAt(i);
-    if (Character.isWhitespace(c)) {
-        // A blank space was found.
-    }
-    i += Character.charCount(c);
-}</pre>
-
-          </td><td>
-            <center>(rendering depends on browser capabilities)</center>
-            <p style="font-size: 40px">&#x1F689; &#x1F6A5; &#x1F6A7; &#x1F6AB;
-              &#x1F6AF; &#x1F6B8; &#x1F6BA; &#x1F6B9; &#x1F6C4; &#x1F6AD;</p>
-          </td>
-        </tr>
-      </table>
-
-      <p>
-        <abbr>SIS</abbr> supports supplementary characters by using the loop on the right where necessary,
-        but the loop on the left is occasionally used when it is known that the characters searched for are not supplementary characters,
-        even if some may be present in the sequence in which we are searching.
-      </p>
-
-
-
-      <h4 id="Whitespaces">Blank spaces interpretation</h4>
-      <p>
-        Standard Java provides two methods for determining whether a character is a blank space:
-        <code>Character.isWhitespace(…)</code> and <code>Character.isSpaceChar(…)</code>.
-        These two methods differ in their interpretations of non-breaking spaces, tabs and line breaks.
-        The first method conforms to the interpretation currently used in languages such as Java, C/C++ and <abbr>XML</abbr>,
-        which considers tabs and line breaks to be blank spaces, while non-breaking spaces are read as not blank.
-        The second method — which conforms strictly to the Unicode definition — makes the opposite interpretation.
-      </p>
-      <p>
-        <abbr>SIS</abbr> uses each of these methods in different contexts.
-        <code>isWhitespace(…)</code> is used to <em>separate</em> the elements of a list (numbers, dates, words, etc.),
-        while <code>isSpaceChar(…)</code> is used to ignore blank spaces <em>inside</em> a single element.
-      </p>
-      <div class="example"><p><b>Example:</b>
-        Take a list of numbers represented according to French conventions.
-        Each number may contain <em>non-breaking spaces</em> as thousands separators,
-        while the different numbers in the list may be separated by ordinary spaces, tabs or line breaks.
-        When analyzing a number, we want to consider the non-breaking spaces as being part of the number,
-        whereas a tab or a line break most likely indicates a separation between this number and the next.
-        We would thus use <code>isSpaceChar(…)</code>.
-        Conversely, when separating the numbers in the list, we want to consider tabs and line breaks as separators,
-        but not non-breaking spaces.
-        We would thus use <code>isWhitespace(…)</code>.
-        The role of ordinary spaces, to which either case might apply, should be decided beforehand.
-      </p></div>
-      <p>
-        In practice, this distinction is reflected in the use of <code>isSpaceChar(…)</code> in the implementations of <code>java.text.Format</code>,
-        or the use of <code>isWhitespace(…)</code> in nearly all the rest of the <abbr>SIS</abbr> library.
-      </p>
     </section>
   </body>
 </html>

Copied: sis/site/trunk/book/en/utility/Internationalization.html (from r1794573, sis/site/trunk/book/en/utility.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/utility/Internationalization.html?p2=sis/site/trunk/book/en/utility/Internationalization.html&p1=sis/site/trunk/book/en/utility.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/en/utility.html [UTF-8] (original)
+++ sis/site/trunk/book/en/utility/Internationalization.html [UTF-8] Tue May  9 23:04:35 2017
@@ -22,181 +22,20 @@
 
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
   <head>
-    <title>Utility classes and methods</title>
+    <title>Internationalization</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/en/developer-guide.html"
+      Content below this point is copied in "(…)/content/book/en/developer-guide.html" file
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
       <header>
-        <h1 id="Utilities">Utility classes and methods</h1>
+        <h2 id="Internationalization">Internationalization</h2>
       </header>
       <p>
-        This chapter describes aspects of Apache <abbr>SIS</abbr> that apply to the entire library.
-        Most of these utilities are not specific to spatial information systems.
-      </p>
-
-      <h2 id="ComparisonMode">Comparison modes of objects</h2>
-      <p>
-        There are various opinions on how to implement Java standard’s <code>Object.equals(Object)</code> method.
-        According to some, it should be possible to compare different implementations of the same interface or base class.
-        But to follow this policy, each interface or base class’s javadoc must define the algorithms that all implementations
-        shall use for their <code>equals(Object)</code> and <code>hashCode()</code> methods.
-        This approach is common in <code>java.util.Collection</code> and its child interfaces.
-        Transferring this approach to certain GeoAPI interfaces, however, would be a difficult task,
-        and would probably not be followed in many implementations.
-        Moreover, it comes at the expense of being able to take into account supplementary attributes in the child interfaces,
-        unless this possibility has been specified in the parent interface.
-        This constraint arises from the following points of the <code>equals(Object)</code> and <code>hashCode()</code> method contracts:
-      </p>
-      <ul>
-        <li><code>A.equals(B)</code> implies <code>B.equals(A)</code> (symmetry);</li>
-        <li><code>A.equals(B)</code> and <code>B.equals(C)</code> implies <code>A.equals(C)</code> (transitivity);</li>
-        <li><code>A.equals(B)</code> implies <code>A.hashCode() == B.hashCode()</code>.</li>
-      </ul>
-      <p>
-        For example, these three constraints are violated if <var>A</var> (and eventually <var>C</var>) can contain attributes
-        which <var>B</var> ignores.
-        To bypass this problem, an alternative approach is to require that the objects compared by the
-        <code>Object.equals(Object)</code> method be of the same class; in other words, <code>A.getClass() == B.getClass()</code>.
-        This approach is sometimes regarded as contrary to the principles of object oriented programming.
-        In practice, for relatively complex applications, the important accorded to these principles depends on the context
-        in which the objects are compared:
-        if the objects are added to a <code>HashSet</code> or used as keys in a <code>HashMap</code>,
-        we would need a stricter adherence to the <code>equals(Object)</code> and <code>hashCode()</code> contract.
-        But if the developer is comparing the objects his- or herself, for example to check that the relevant information has been changed,
-        then the constraints of symmetry, transitivity or coherence with the hash values may be of little interest.
-        More permissive comparisons may be desirable, sometimes going so far as to tolerate minor discrepancies in numerical values.
-      </p>
-      <p>
-        In order to allow developers a certain amount of flexibility, many classes in the <abbr>SIS</abbr>
-        library implement the <code>org.apache.sis.util.LenientComparable</code> interface,
-        which defines a <code class="SIS">equals(Object, ComparisonMode)</code> method.
-        The principle modes of comparison are:
-      </p>
-      <ul>
-        <li><p>
-          <b><code class="SIS">STRICT</code></b> — The objects compared must share the same class and have exactly equal attributes,
-          including any possible public attributes specific to the implementation.
-        </p></li>
-        <li><p>
-          <b><code class="SIS">BY_CONTRACT</code></b> — The objects compared must implement the same GeoAPI (or other standard)
-          interface, but need not be of the same implementation class.
-          Only the attributes defined in the interface are compared;
-          all other attributes specific to the implementation — even if they are public — are ignored.
-        </p></li>
-        <li><p>
-          <b><code class="SIS">IGNORE_METADATA</code></b> — Like <code class="SIS">BY_CONTRACT</code>,
-          but only compares attributes that influence the operations (numeric calculations or otherwise) performed by the object.
-          For example, in a geodesic datum, the longitude (in relation to Greenwich) of the original meridian
-          would be taken into account, while the name of the meridian would be ignored.
-        </p></li>
-        <li><p>
-          <b><code class="SIS">APPROXIMATIVE</code></b> — Like <code class="SIS">IGNORE_METADATA</code>,
-          but tolerates minor discrepancies in numerical values.
-        </p></li>
-      </ul>
-      <p>
-        The default mode, used in all <code>equals(Object)</code> methods in <abbr>SIS</abbr>,
-        is <code class="SIS">STRICT</code>. This mode is chosen for a safe operation — particularly with <code>HashMap</code> —
-        without the need to rigorously define <code>equals(Object)</code> and <code>hashCode()</code> operations in every interface.
-        With this mode, the order of objects (<code>A.equals(B)</code> or <code>B.equals(A)</code>) is unimportant.
-        It is, however, the only mode that offers this guarantee.
-        In the expression <code>A.equals(B)</code>, the <code class="SIS">BY_CONTRACT</code> mode
-        (and so by extension all other modes that depend on it) only compares the properties known to <code>A</code>,
-        regardless of whether <code>B</code> knows more.
-      </p>
-
-
-
-      <h2 id="ObjectConverters">Object converters</h2>
-      <p>
-        There is sometime a need to convert instances from a <var>source</var> Java type to a <var>target</var> Java type
-        while those types are unknown at compile time.
-        Various projects (Apache Common Convert, Spring, <i>etc.</i>)
-        have created their own interface for performing object conversions between types known only at runtime.
-        Details vary, but such interfaces typically look like below:
-      </p>
-
-<pre>interface ObjectConverter&lt;S,T&gt; {   // Some projects use only "Converter" as interface name.
-    T apply(S object);             // Another method name commonly found in other projects is "convert".
-}</pre>
-
-      <p>
-        Like other projects, Apache <abbr>SIS</abbr> also defines its own <code>ObjectConverter</code> interface.
-        The main difference between <abbr>SIS</abbr> converter interface and the interfaces found in other projects
-        is that <abbr>SIS</abbr> converters provide some information about their mathematical properties.
-        An Apache <abbr>SIS</abbr> converter can have zero, one or many of the following properties:
-      </p>
-      <dl>
-        <dt><dfn>Injective</dfn></dt>
-        <dd>A function is injective if no pair of <var>S</var> values can produce the same <var>T</var> value.
-          <div class="example"><p><b>Example:</b>
-              the <code>Integer</code> → <code>String</code> conversion performed by <code>Integer.toString()</code>
-              is an <cite>injective</cite> function because if two <code>Integer</code> values are not equal,
-              then it is guaranteed that their conversions will result in different <code>String</code> values.
-              However the <code>String</code> → <code>Integer</code> conversion performed by <code>Integer.valueOf(String)</code>
-              is <strong>not</strong> an injective function
-              because many distinct <code>String</code> values can be converted to the same <code>Integer</code> value.
-              For example converting the "42", "+42" and "0042" character strings all result in the same 42 integer value.
-          </p></div>
-        </dd>
-
-        <dt><dfn>Surjective</dfn></dt>
-        <dd>A function is surjective if each values of <var>T</var> can be created from at least one value of <var>S</var>.
-          <div class="example"><p><b>Example:</b>
-              the <code>String</code> → <code>Integer</code> conversion performed by <code>Integer.valueOf(String)</code>
-              is a <cite>surjective</cite> function because every <code>Integer</code> value can be created from at least one <code>String</code> value.
-              However the <code>Integer</code> → <code>String</code> conversion performed by <code>Integer.toString()</code>
-              is <strong>not</strong> a surjective function because it can not produce all possible <code>String</code> values.
-              For example there is no way to produce the "ABC" value with the <code>Integer.toString()</code> method.
-          </p></div>
-        </dd>
-
-        <dt><dfn>Bijective</dfn></dt>
-        <dd>A function is bijective if there is a one-to-one relationship between <var>S</var> and <var>T</var> values.
-          <div class="example"><p><b>Note:</b>
-            the <cite>bijective</cite> property is defined here for clarity, but actually does not have an explicit item
-            in Apache <abbr>SIS</abbr> <code>FunctionProperty</code> enumeration.
-            It is not necessary since a function that is both <cite>injective</cite> and <cite>surjective</cite> is necessarily bijective.
-          </p></div>
-        </dd>
-
-        <dt><dfn>Order preserving</dfn></dt>
-        <dd>A function is order preserving if any sequence of increasing <var>S</var> values is mapped to a sequence of increasing <var>T</var> values.
-          <div class="example"><p><b>Example:</b>
-            conversion from <code>Integer</code> to <code>Long</code> preserve the natural ordering of elements.
-            However conversions from <code>Integer</code> to <code>String</code> do <strong>not</strong> preserve natural ordering,
-            because some sequences of increasing integer values are ordered differently when their string representations are sorted by lexicographic order.
-            For example 1, 2, 10 become "1", "10", "2".
-          </p></div>
-        </dd>
-
-        <dt><dfn>Order reversing</dfn></dt>
-        <dd>A function is order reversing if any sequence of increasing <var>S</var> values is mapped to a sequence of decreasing <var>T</var> values.
-          <div class="example"><p><b>Example:</b>
-            a conversion that reverses the sign of numbers.
-          </p></div>
-        </dd>
-      </dl>
-      <p>
-        Above information may seem unnecessary when values are converted without taking in account the context in which the values appear.
-        But when the value to convert is part of a bigger object, then above information can affect the way the converted value will be used.
-        For example conversion of a [<var>min</var> … <var>max</var>] range is straightforward when the converter is <cite>order preserving</cite>.
-        But if the converter is <cite>order reversing</cite>, then the minimum and maximum values need to be interchanged.
-        For example if the converter reverses the sign of values, then the converted range is [-<var>max</var> … -<var>min</var>].
-        If the converter is neither order preserving or order reversing, then range conversion is not allowed at all
-        (because it does not contain the same set of values) even if the minimum and maximum values could be converted individually.
-      </p>
-
-
-
-      <h2 id="Internationalization">Internationalization</h2>
-      <p>
         In an architecture where a program executed on a server provides its data to multiple clients,
         the server’s locale conventions are not necessarily the same as those of the clients.
         Conventions may differ in language, but also in the way they write numeric values



Mime
View raw message