Merge branch 'asf-staging' into asf-site.
The main change is an update of the developer guide.
diff --git a/book/book.css b/book/book.css
index d2d61bf..effe5d8 100644
--- a/book/book.css
+++ b/book/book.css
@@ -107,6 +107,18 @@
margin-top: 9px;
margin-bottom: 9px;
}
+dt {
+ margin-top: 9px;
+ font-weight: bold;
+}
+
+span.term-source:before {
+ color: SteelBlue;
+ content: " — Source: ";
+}
+span.term-source {
+ color: SteelBlue;
+}
/*
* Chapters and sections titles (excluding the book titles).
@@ -274,7 +286,8 @@
margin-bottom: 21px;
padding: 12px;
border: 2px solid silver;
- background: #F8F8F8
+ background: #F8F8F8;
+ font-size: smaller;
}
samp.xml {
diff --git a/book/en/developer-guide.html b/book/en/developer-guide.html
index 177993d..a27a6a6 100644
--- a/book/en/developer-guide.html
+++ b/book/en/developer-guide.html
@@ -21,7 +21,9 @@
<p>Table of content</p>
<ul>
<li><a href="#Introduction">Introduction</a><ul>
-<li><a href="#Conventions">Typographic and naming conventions</a></li>
+<li><a href="#DefinitionOfTerms">Definition of terms</a></li>
+<li><a href="#TypographicConventions">Typographic conventions</a></li>
+<li><a href="#CodingConventions">Coding conventions</a></li>
<li><a href="#Installation">Installation</a></li>
<li><a href="#DataAccess">Data access overview</a></li></ul></li>
<li><a href="#Coverage">Data as coverage</a><ul>
@@ -48,8 +50,11 @@
<li><a href="#TransformDerivative">Partial derivatives of coordinate operations</a></li>
<li><a href="#CoordinateOperationSteps">Chain of coordinate operation steps</a></li></ul></li></ul></li>
<li><a href="#Metadata">Metadata</a><ul>
-<li><a href="#GetMetadataElement">Navigating in metadata elements</a><ul>
-<li><a href="#MetadataAsMap">View as key-value pairs</a></li></ul></li></ul></li>
+<li><a href="#NavigateMetadata">Navigating in metadata elements</a><ul>
+<li><a href="#GetMetadataElement">Direct access via getter methods</a></li>
+<li><a href="#MetadataAsMap">View as key-value pairs</a></li>
+<li><a href="#MetadataAsTreeTable">View as tree table</a></li></ul></li>
+<li><a href="#NilReason">Nil values in mandatory properties</a></li></ul></li>
<li><a href="#XML-ISO">XML representation of ISO objects</a><ul>
<li><a href="#XML-ISO-19115">ISO 19115-3 metadata</a><ul>
<li><a href="#gco-id">Links to previously-defined instances</a></li>
@@ -109,16 +114,13 @@
</p><p>
The library is an implementation of <abbr title="Open Geospatial Consortium">OGC</abbr> <a href="http://www.geoapi.org">GeoAPI</a> interfaces.
In a series of <code class="GeoAPI">org.opengis.*</code> packages, GeoAPI offers a set of implementation-neutral Java interfaces for geospatial applications.
-These interfaces closely follow the specifications of the <abbr>OGC</abbr>, while interpreting and adapting them
-to meet the needs of Java developers — for example, conforming with Java naming conventions.
+These interfaces closely follow the specifications of the <abbr>OGC</abbr>,
+while interpreting and adapting them to meet the needs of Java developers.
The conceptual model of GeoAPI will be explained in detail in the chapters describing Apache <abbr>SIS</abbr> implementation.
-However, we can get an overview of its content by consulting the page listing the mapping between
-<a href="http://www.geoapi.org/3.0/javadoc/content.html">GeoAPI methods and the standards where they come from</a>.
-The <a href="#GeoAPI">annex</a> provides more details about GeoAPI history and how to use it.
</p><p>
While Apache <abbr>SIS</abbr> is primarily a library for helping developers to create their own applications,
<abbr>SIS</abbr> provides also an optional JavaFX application for testing its capability to read, transform and visualize data files.
-Screenshots of this application may be used in this document for illustrative purposes.
+Screenshots of this application are used in this document for illustrative purposes.
</p><p>
<b>Note:</b> this document contains mathematical formulas expressed in MathML.
For viewing those formulas, a MathML-capable browser (e.g. Firefox) is required.
@@ -129,15 +131,78 @@
+
<section>
<header>
-<h2 id="Conventions"><span class="section-number">1.1.</span> Typographic and naming conventions</h2>
+<h2 id="DefinitionOfTerms"><span class="section-number">1.1.</span> Definition of terms</h2>
+</header>
+<p>
+The meaning of words sometime depend on the community using them.
+The Apache <abbr title="Spatial Information System">SIS</abbr> library prefers as much as possible to use terms in the sense of <abbr title="Open Geospatial Consortium">OGC</abbr> and <abbr>ISO</abbr> standards.
+Particular care must be taken with the interfaces between <abbr>SIS</abbr> and certain other external libraries.
+For example, the <abbr>ISO</abbr> 19123 standard see <code class="OGC">CV_Coverage</code> as functions
+in which the <dfn>domain</dfn> is the set of spatio-temporal coordinates encompassed by the data,
+and the <dfn>range</dfn> is the set of values encompassed.
+However, <abbr title="University Corporation for Atmospheric Research">UCAR</abbr>’s <abbr title="Network Common Data Form">netCDF</abbr> library
+applies these terms instead to the function for converting pixel indices (its <dfn>domain</dfn>) to spatial-temporal coordinates (its <dfn>range</dfn>).
+Thus the <abbr>UCAR</abbr> library’s <dfn>range</dfn> may be the <dfn>domain</dfn> of <abbr>ISO</abbr> 19123.
+</p>
+<dl>
+<dt>Coverage</dt>
+<dd>Feature that acts as a function to return values from its range for any direct position within its spatial,
+temporal or spatiotemporal domain.
+<span class="term-source">ISO 19123</span></dd>
+
+<dt>Coordinate</dt>
+<dd>One of a sequence of numbers designating the position of a point.
+<span class="term-source">ISO 19111</span></dd>
+
+<dt>Coordinate operation</dt>
+<dd>Process using a mathematical model, based on a one-to-one relationship, that changes coordinates
+in a source coordinate reference system to coordinates in a target coordinate reference system,
+or that changes coordinates at a source coordinate epoch to coordinates at a target coordinate epoch
+within the same coordinate reference system.
+<span class="term-source">ISO 19111</span></dd>
+
+<dt>Coordinate reference system</dt>
+<dd>Coordinate system that is related to an object by a datum.
+<span class="term-source">ISO 19111</span></dd>
+
+<dt>Coordinate system</dt>
+<dd>Set of mathematical rules for specifying how coordinates are to be assigned to points.
+<span class="term-source">ISO 19111</span></dd>
+
+<dt>Coordinate tuple</dt>
+<dd>Tuple composed of coordinates.
+The number of coordinates in the coordinate tuple equals the dimension of the coordinate system.
+The order of coordinates in the coordinate tuple is identical to the order of the axes of the coordinate system.
+<span class="term-source">ISO 19111</span></dd>
+
+<dt>Datum</dt>
+<dd>Parameter or set of parameters that realize the position of the origin,
+the scale, and the orientation of a coordinate system.
+<span class="term-source">ISO 19111</span></dd>
+
+<dt>Domain</dt>
+<dd>Well-defined set.
+<span class="term-source">ISO 19123</span></dd>
+
+<dt>Range</dt>
+<dd>Set of feature attribute values associated by a function with the elements of the domain of a coverage.
+<span class="term-source">ISO 19123</span></dd>
+</dl>
+</section>
+
+
+<section>
+<header>
+<h2 id="TypographicConventions"><span class="section-number">1.2.</span> Typographic conventions</h2>
</header>
<p>
The elements defined in a computer language, such as classes and methods in Java or elements in an <abbr>XML</abbr> document,
appear in monospaced font in this document.
In order to facilitate an understanding of the relationships between Apache <abbr title="Spatial Information System">SIS</abbr> and the standards,
-these elements are also represented using the following colour codes:
+these elements are also represented using the following color codes:
</p>
<ul>
<li>
@@ -152,7 +217,7 @@
</li>
<li>
Elements left in black are either defined elsewhere (for example the standard Java library),
-or there is simply no emphasis on that element for the discussion.
+or there is no emphasis on that element for the discussion.
</li>
</ul>
<p>
@@ -160,7 +225,13 @@
<code class="OGC">SC_ProjectedCRS</code> is an <abbr>UML</abbr> and <abbr>XML</abbr> element defined by the <abbr>ISO</abbr> 19111 standard.
Then <code class="GeoAPI">org.opengis.referencing.crs.<b>ProjectedCRS</b></code> is the implementation-neutral GeoAPI interface derived from that standard,
and <code class="SIS">org.apache.sis.referencing.crs.<b>DefaultProjectedCRS</b></code> is the implementation class provided by Apache SIS.
-</p><p>
+</p>
+</section>
+<section>
+<header>
+<h2 id="CodingConventions"><span class="section-number">1.3.</span> Coding conventions</h2>
+</header>
+<p>
Apache SIS implements most GeoAPI interfaces by a classes of the same name than the interface
but prefixed by <code>Abstract</code>, <code>Default</code> or <code>General</code> word.
The <code>General</code> prefix is sometimes used instead of <code>Default</code>
@@ -172,46 +243,17 @@
</p><p>
Apache SIS classes prefixed by <code>Abstract</code> should not (in principle) be instantiated.
Users should instantiate a non-abstract subclass instead.
-However many <abbr>SIS</abbr> classes are only conceptually abstract,
+However many <abbr title="Spatial Information System">SIS</abbr> classes are only conceptually abstract,
without <code>abstract</code> Java keyword in class definition.
Such classes can be instantiated by a <code>new AbstractXXX(…)</code> statement despite being conceptually abstract.
Such instantiations should be avoided, but are nevertheless permitted in last resort when it is not possible to determine the exact subtype.
</p>
-<p>
-Text in gray boxes, like below (click to expand), are for information purpose only and can be ignored.
-</p>
-<details>
-<summary>Note about the definition of terms</summary>
-<article id="ChosenTerms">
-<header>
-<h2>Source of term definitions</h2>
-</header>
-<p>
-Standards sometimes favour the application of certain generic terms to particular contexts,
-which may differ from the context in which other communities use these terms.
-For example, the terms <i>domain</i> and <i>range</i> may apply to arbitrary mathematical functions in order to designate
-a set of possible values of inputs and outputs respectively.
-The <abbr title="International Organization for Standardization">ISO</abbr> 19123 standard applies these terms to <code class="OGC">CV_Coverage</code> objects,
-seen as functions in which the <i>domain</i> is the set of spatio-temporal coordinates encompassed by the data,
-and the <i>range</i> is the set of values encompassed.
-</p><p>
-However the functions to which above terms are applied by <abbr>ISO</abbr> standards are not the same as the functions to which they are applied by other libraries.
-For example <abbr title="University Corporation for Atmospheric Research">UCAR</abbr>’s <abbr title="Network Common Data Form">netCDF</abbr> library
-applies these terms instead to the function for converting pixel indices (its <i>domain</i>) to spatial-temporal coordinates (its <i>range</i>).
-Thus the <abbr>UCAR</abbr> library’s <i>range</i> may be the <i>domain</i> of <abbr>ISO</abbr> 19123.
-</p><p>
-The Apache <abbr title="Spatial Information System">SIS</abbr> library prefers as much as possible to use terms in the sense of <abbr title="Open Geospatial Consortium">OGC</abbr> and <abbr>ISO</abbr> norms.
-Particular care must be taken, however, with the interfaces between <abbr>SIS</abbr> and certain other external libraries,
-in order to reduce the risk of confusion.
-</p>
-</article>
-</details>
</section>
<section>
<header>
-<h2 id="Installation"><span class="section-number">1.2.</span> Installation</h2>
+<h2 id="Installation"><span class="section-number">1.4.</span> Installation</h2>
</header>
<p>
The easiest way to use Apache <abbr title="Spatial Information System">SIS</abbr> is to declare Maven dependencies in the application project.
@@ -225,7 +267,7 @@
see <a href="../../epsg.html">How to use EPSG geodetic dataset</a> page for more information.
</p>
<pre><properties>
- <sis.version>1.3</sis.version>
+ <sis.version>1.4</sis.version>
</properties>
<dependencies>
<dependency>
@@ -250,7 +292,7 @@
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
- <version>2.3.6</version>
+ <version>4.0.4</version>
<scope>runtime</scope>
</dependency>
@@ -283,7 +325,7 @@
<section>
<header>
-<h2 id="DataAccess"><span class="section-number">1.3.</span> Data access overview</h2>
+<h2 id="DataAccess"><span class="section-number">1.5.</span> Data access overview</h2>
</header>
<p>
It is possible to instantiate data structures programmatically in memory.
@@ -308,35 +350,40 @@
legal or technical constraints on data usage,
the history of processing apply on the data,
expected updates schedule, <i>etc.</i>
-</p><p>
-Various data formats have their own metadata model, but Apache <abbr title="Spatial Information System">SIS</abbr> translates all of them
+The metadata structures depends on the data formats, but Apache <abbr title="Spatial Information System">SIS</abbr> translates all of them
in a unique metadata model in order to hide this heterogeneity.
-This <em>pivot model</em> approach is often used by various libraries,
-with <cite>Dublin Core</cite> as a popular choice.
-For Apache <abbr>SIS</abbr>, the chosen pivot model is the <abbr title="International Organization for Standardization">ISO</abbr> <cite>19115</cite> international standard.
-This model organizes metadata in a tree structure where each information is accessible by a well-defined path,
-regardless the origin of that information.
+This <em>pivot model</em> approach is often used by various libraries, with Dublin Core as a popular choice.
+For Apache <abbr>SIS</abbr>, the chosen pivot model is the <abbr title="International Organization for Standardization">ISO</abbr> 19115 international standard.
+This model organizes metadata in a tree structure.
For example if a data format can provides a geographic bounding box encompassing all data,
then that information will always be accessible (regardless the data format) from the root <code class="GeoAPI">Metadata</code> object
-under the <code class="OGC">identificationInfo</code> node, <code class="OGC">extent</code> sub-node,
-<code class="OGC">geographicElement</code> sub-node.
-</p>
-<div class="example"><p><b>Example:</b>
-following code read a metadata file from a Landsat-8 image and prints the declared geographic bounding box:
+under the <code class="OGC">identificationInfo</code> node, then the <code class="OGC">extent</code> sub-node,
+and finally the <code class="OGC">geographicElement</code> sub-node.
+For example, the following code read a metadata file from a Landsat-8 image and prints the declared geographic bounding box:
</p>
-<pre><code><b>try</b> (<code class="SIS">DataStore</code> store = <code class="SIS">DataStores</code>.open(<b>new</b> File(<i>"LC81230522014071LGN00_MTL.txt"</i>))) {
- <code class="GeoAPI">Metadata</code> overview = store.<code class="SIS">getMetadata()</code>;
+<pre><code>
+<b>import</b> org.opengis.metadata.<code class="GeoAPI">Metadata</code>;
+<b>import</b> org.opengis.metadata.extent.<code class="GeoAPI">GeographicBoundingBox</code>;
+<b>import</b> org.apache.sis.storage.<code class="SIS">DataStore</code>;
+<b>import</b> org.apache.sis.storage.<code class="SIS">DataStores</code>;
+<b>import</b> org.apache.sis.storage.DataStoreException;
+<b>import</b> org.apache.sis.metadata.iso.extent.<code class="SIS">Extents</code>;
- <code class="comment">// Convenience method for fetching the geographic bounding box at the right location in metadata tree.</code>
- <code class="GeoAPI">GeographicBoundingBox</code> bbox = <code class="SIS"><code class="SIS">Extents</code>.getGeographicBoundingBox</code>(overview);
+<b>void</b> main() <b>throws</b> DataStoreException {
+ <b>try</b> (<code class="SIS">DataStore</code> store = <code class="SIS">DataStores</code>.open(<b>new</b> File(<i>"LC81230522014071LGN00_MTL.txt"</i>))) {
+ <code class="GeoAPI">Metadata</code> overview = store.<code class="SIS">getMetadata()</code>;
- System.out.println(<i>"The geographic bounding box is:"</i>);
- System.out.println(bbox);
+ <code class="comment">// Convenience method for fetching value at the "metadata/identificationInfo/geographicElement" path.</code>
+ <code class="GeoAPI">GeographicBoundingBox</code> bbox = <code class="SIS"><code class="SIS">Extents</code>.getGeographicBoundingBox</code>(overview);
+
+ System.out.println(<i>"The geographic bounding box is:"</i>);
+ System.out.println(bbox);
+ }
}</code></pre>
<p>
-This example produces the following output (this area is located in Vietnam):
+Above example produces the following output (this area is located in Vietnam):
</p>
<pre><samp>The geographic bounding box is:
@@ -345,64 +392,16 @@
├─East bound longitude…………………………… 110°26′39.66″E
├─South bound latitude…………………………… 10°29′59.604″N
└─North bound latitude…………………………… 12°37′25.716″N</samp></pre>
-</div>
<p>
-The <abbr>ISO</abbr> 19115 standard defines hundreds of elements.
-Some of them will be introduced progressively in next chapters.
-But in order to give some idea about what is available, the following table lists a few metadata elements.
-Most of the nodes accept an arbitrary number of values.
-For example the <code class="OGC">extent</code> node may contain many geographic areas.
-</p>
-
-<table class="monospacedHeaderColumn" style="font-size:0.82vw">
-<caption>Extract of a few metadata elements from ISO 19115</caption>
-<tr><th>Element</th> <th>Description</th></tr>
-<tr><td style="padding-top:9px">Metadata</td> <td style="padding-top:9px">Metadata about a dataset, service or other resources.</td></tr>
-<tr><td> ├─Reference system info</td> <td>Description of the spatial and temporal reference systems used in the dataset.</td></tr>
-<tr><td> ├─Identification info</td> <td>Basic information about the resource(s) to which the metadata applies.</td></tr>
-<tr><td> │ ├─Citation</td> <td>Name by which the cited resource is known, reference dates, presentation form, <i>etc.</i></td></tr>
-<tr><td> │ │ └─Cited responsible party</td> <td>Role, name, contact and position information for individuals or organizations that are responsible for the resource.</td></tr>
-<tr><td> │ ├─Topic category</td> <td>Main theme(s) of the resource (e.g. farming, climatology, environment, economy, health, transportation, <i>etc.</i>).</td></tr>
-<tr><td> │ ├─Descriptive keywords</td> <td>Category keywords, their type, and reference source.</td></tr>
-<tr><td> │ ├─Spatial resolution</td> <td>Factor which provides a general understanding of the density of spatial data in the resource.</td></tr>
-<tr><td> │ ├─Temporal resolution</td> <td>Smallest resolvable temporal period in a resource.</td></tr>
-<tr><td> │ ├─Extent</td> <td>Spatial and temporal extent of the resource.</td></tr>
-<tr><td> │ ├─Resource format</td> <td>Description of the format of the resource(s).</td></tr>
-<tr><td> │ ├─Resource maintenance</td> <td>Information about the frequency of resource updates, and the scope of those updates.</td></tr>
-<tr><td> │ └─Resource constraints</td> <td>Information about constraints (legal or security) which apply to the resource(s).</td></tr>
-<tr><td> ├─Content info</td> <td>Information about the feature catalog and describes the coverage and image data characteristics.</td></tr>
-<tr><td> │ ├─Imaging condition</td> <td>Conditions which affected the image (e.g. blurred image, fog, semi darkness, <i>etc.</i>).</td></tr>
-<tr><td> │ ├─Cloud cover percentage</td> <td>Area of the dataset obscured by clouds, expressed as a percentage of the spatial extent.</td></tr>
-<tr><td> │ └─Attribute group</td> <td>Information on attribute groups of the resource.</td></tr>
-<tr><td> │ ├─Content type</td> <td>Types of information represented by the values (e.g. thematic classification, physical measurement, <i>etc.</i>).</td></tr>
-<tr><td> │ └─Attribute</td> <td>Information on an attribute of the resource.</td></tr>
-<tr><td> │ ├─Sequence identifier</td> <td>Unique name or number that identifies attributes included in the coverage.</td></tr>
-<tr><td> │ ├─Peak response</td> <td>Wavelength at which the response is the highest.</td></tr>
-<tr><td> │ ├─Min/max value</td> <td>Minimum/maximum value of data values in each sample dimension included in the resource.</td></tr>
-<tr><td> │ ├─Units</td> <td>Units of data in each dimension included in the resource.</td></tr>
-<tr><td> │ └─Transfer function type</td> <td>Type of transfer function to be used when scaling a physical value for a given element.</td></tr>
-<tr><td> ├─Distribution info</td> <td>Information about the distributor of and options for obtaining the resource(s).</td></tr>
-<tr><td> │ ├─Distribution format</td> <td>Description of the format of the data to be distributed.</td></tr>
-<tr><td> │ └─Transfer options</td> <td>Technical means and media by which a resource is obtained from the distributor.</td></tr>
-<tr><td> ├─Data quality info</td> <td>Overall assessment of quality of a resource(s).</td></tr>
-<tr><td> ├─Acquisition information</td> <td>Information about the acquisition of the data.</td></tr>
-<tr><td> │ ├─Environmental conditions</td> <td>Record of the environmental circumstances during the data acquisition.</td></tr>
-<tr><td> │ └─Platform</td> <td>General information about the platform from which the data were taken.</td></tr>
-<tr><td> │ └─Instrument</td> <td>Instrument(s) mounted on a platform.</td></tr>
-<tr><td> └─Resource lineage</td> <td>Information about the provenance, sources and/or the production processes applied to the resource.</td></tr>
-<tr><td> ├─Source</td> <td>Information about the source data used in creating the data specified by the scope.</td></tr>
-<tr><td> └─Process step</td> <td>Information about events in the life of a resource specified by the scope.</td></tr>
-</table>
-<p>
-Among metadata elements introduced in this chapter, there is one which will be the topic of
+Metadata are covered in more details in a <a href="#Metadata">latter chapter</a>.
+Among metadata elements, there is one which will be the topic of
a <a href="#Referencing">dedicated chapter</a>: <code class="OGC">referenceSystemInfo</code>.
Its content is essential for accurate data positioning;
without this element, even positions given by latitudes and longitudes are ambiguous.
Reference systems have many characteristics that make them apart from other metadata:
-they are immutable, cannot be handled by <code class="SIS">MetadataStandard.ISO_19115.asValueMap(…)</code>,
-have a particular text representation and are associated to an engine
-performing coordinate transformation from one reference system to another.
+they are immutable, have a particular Well-Known Text representation and are associated
+to an engine performing coordinate transformation from one reference system to another.
</p>
</section>
</section>
@@ -910,7 +909,7 @@
This case is illustrated by the red rectangle in the figure below.
</p>
<p style="text-align:center">
-<img alt="Envelope example with and without anti-meridian spanning." src="../../apidocs/org/apache/sis/geometry/doc-files/AntiMeridian.png"/>
+<img alt="Envelope example with and without anti-meridian spanning." src="../../apidocs/org.apache.sis.referencing/org/apache/sis/geometry/doc-files/AntiMeridian.png"/>
</p>
<p>
The notions of inclusion and intersection, however, are interpreted slightly differently in these two cases.
@@ -1845,30 +1844,194 @@
<header>
<h1 id="Metadata"><span class="section-number">5.</span> Metadata</h1>
</header>
+<p>
+Many metadata standards exist, including Dublin core, <abbr title="International Organization for Standardization">ISO</abbr> 19115
+and the Image I/O metadata defined in the <code>javax.imageio.metadata</code> package.
+Apache <abbr title="Spatial Information System">SIS</abbr> uses the <abbr>ISO</abbr> 19115 series of standards as the pivotal metadata structure,
+and converts other metadata structures to <abbr>ISO</abbr> 19115 when needed.
+The <abbr>ISO</abbr> 19115 standard defines hundreds of metadata elements,
+but the following table gives an overview with a few of them.
+Note that most of the nodes accept an arbitrary number of values.
+For example the <code class="OGC">extent</code> node may contain many geographic areas.
+</p>
+
+<table class="monospacedHeaderColumn" style="font-size:0.82vw">
+<caption>Extract of a few metadata elements from ISO 19115</caption>
+<tr><th>Element</th> <th>Description</th></tr>
+<tr><td style="padding-top:9px">Metadata</td> <td style="padding-top:9px">Metadata about a dataset, service or other resources.</td></tr>
+<tr><td> ├─Reference system info</td> <td>Description of the spatial and temporal reference systems used in the dataset.</td></tr>
+<tr><td> ├─Identification info</td> <td>Basic information about the resource(s) to which the metadata applies.</td></tr>
+<tr><td> │ ├─Citation</td> <td>Name by which the cited resource is known, reference dates, presentation form, <i>etc.</i></td></tr>
+<tr><td> │ │ └─Cited responsible party</td> <td>Role, name, contact and position information for individuals or organizations that are responsible for the resource.</td></tr>
+<tr><td> │ ├─Topic category</td> <td>Main theme(s) of the resource (e.g. farming, climatology, environment, economy, health, transportation, <i>etc.</i>).</td></tr>
+<tr><td> │ ├─Descriptive keywords</td> <td>Category keywords, their type, and reference source.</td></tr>
+<tr><td> │ ├─Spatial resolution</td> <td>Factor which provides a general understanding of the density of spatial data in the resource.</td></tr>
+<tr><td> │ ├─Temporal resolution</td> <td>Smallest resolvable temporal period in a resource.</td></tr>
+<tr><td> │ ├─Extent</td> <td>Spatial and temporal extent of the resource.</td></tr>
+<tr><td> │ ├─Resource format</td> <td>Description of the format of the resource(s).</td></tr>
+<tr><td> │ ├─Resource maintenance</td> <td>Information about the frequency of resource updates, and the scope of those updates.</td></tr>
+<tr><td> │ └─Resource constraints</td> <td>Information about constraints (legal or security) which apply to the resource(s).</td></tr>
+<tr><td> ├─Content info</td> <td>Information about the feature catalog and describes the coverage and image data characteristics.</td></tr>
+<tr><td> │ ├─Imaging condition</td> <td>Conditions which affected the image (e.g. blurred image, fog, semi darkness, <i>etc.</i>).</td></tr>
+<tr><td> │ ├─Cloud cover percentage</td> <td>Area of the dataset obscured by clouds, expressed as a percentage of the spatial extent.</td></tr>
+<tr><td> │ └─Attribute group</td> <td>Information on attribute groups of the resource.</td></tr>
+<tr><td> │ ├─Content type</td> <td>Types of information represented by the values (e.g. thematic classification, physical measurement, <i>etc.</i>).</td></tr>
+<tr><td> │ └─Attribute</td> <td>Information on an attribute of the resource.</td></tr>
+<tr><td> │ ├─Sequence identifier</td> <td>Unique name or number that identifies attributes included in the coverage.</td></tr>
+<tr><td> │ ├─Peak response</td> <td>Wavelength at which the response is the highest.</td></tr>
+<tr><td> │ ├─Min/max value</td> <td>Minimum/maximum value of data values in each sample dimension included in the resource.</td></tr>
+<tr><td> │ ├─Units</td> <td>Units of data in each dimension included in the resource.</td></tr>
+<tr><td> │ └─Transfer function type</td> <td>Type of transfer function to be used when scaling a physical value for a given element.</td></tr>
+<tr><td> ├─Distribution info</td> <td>Information about the distributor of and options for obtaining the resource(s).</td></tr>
+<tr><td> │ ├─Distribution format</td> <td>Description of the format of the data to be distributed.</td></tr>
+<tr><td> │ └─Transfer options</td> <td>Technical means and media by which a resource is obtained from the distributor.</td></tr>
+<tr><td> ├─Data quality info</td> <td>Overall assessment of quality of a resource(s).</td></tr>
+<tr><td> ├─Acquisition information</td> <td>Information about the acquisition of the data.</td></tr>
+<tr><td> │ ├─Environmental conditions</td> <td>Record of the environmental circumstances during the data acquisition.</td></tr>
+<tr><td> │ └─Platform</td> <td>General information about the platform from which the data were taken.</td></tr>
+<tr><td> │ └─Instrument</td> <td>Instrument(s) mounted on a platform.</td></tr>
+<tr><td> └─Resource lineage</td> <td>Information about the provenance, sources and/or the production processes applied to the resource.</td></tr>
+<tr><td> ├─Source</td> <td>Information about the source data used in creating the data specified by the scope.</td></tr>
+<tr><td> └─Process step</td> <td>Information about events in the life of a resource specified by the scope.</td></tr>
+</table>
+
+<p>
+The ISO 19115 standard is reified by the <a href="http://www.geoapi.org">GeoAPI</a> interfaces
+defined in the <code class="GeoAPI">org.opengis.metadata</code> package and sub-packages.
+For each interface, the collection of declared getter methods defines its <dfn>properties</dfn> (or <dfn>attributes</dfn>).
+The implementation classes are defined in the <code class="SIS">org.apache.sis.metadata.iso</code> package and sub-packages.
+The sub-packages hierarchy is the same as GeoAPI,
+and the names of implementation classes are the name of the GeoAPI interfaces
+prefixed with <code>Abstract</code> or <code>Default</code>. In this context,
+the <code>Abstract</code> prefix means that the class is abstract in the sense of the implemented standard.
+It it not necessarily abstract in the sense of Java. Because incomplete metadata are common in practice,
+sometimes an "abstract" class may be instantiated because of the lack of knowledge about the exact sub-type.
+A metadata instance (abstract or not) may also have missing values for properties considered as mandatory.
+The latter case is handled by <a href="#NilReason">nil reasons</a>.
+</p><p>
+A metadata may be created programmatically like below:
+</p>
+
+<pre><code>
+<b>import</b> org.apache.sis.metadata.iso.citation.DefaultCitation;
+<b>import</b> org.opengis.metadata.citation.<code class="GeoAPI">PresentationForm</code>;
+
+<b>void</b> main() {
+ <code class="comment">// Convenience constructor setting the "title" property to the given value.</code>
+ var citation = <b>new</b> DefaultCitation(<i>"Map of Antarctica"</i>);
+ citation.getPresentationForms().add(<code class="GeoAPI">PresentationForm</code>.DOCUMENT_HARDCOPY);
+
+ <code class="comment">// The following code prints "Map of Antarctica".</code>
+ System.out.println(citation.getTitle());
+}</code></pre>
+
+<p>
+But more often, metadata are obtained by parsing an <abbr>XML</abbr> document
+conforms to the <abbr>ISO</abbr> 19115-3 schema:
+</p>
+
+<pre><code><b>import</b> org.apache.sis.xml.XML;
+<b>import</b> org.opengis.metadata.<code class="GeoAPI">Metadata</code>;
+<b>import</b> jakarta.xml.bind.JAXBException;
+
+<b>void</b> main() <b>throws</b> JAXBException {
+ var metadata = (<code class="GeoAPI">Metadata</code>) XML.unmarshal(Path.of(<i>"Map of Antarctica.xml"</i>));
+}</code></pre>
+
+<p>
+Metadata objects in Apache <abbr>SIS</abbr> are mostly containers:
+they provide getter and setter methods for manipulating the values associated to properties
+(for example the <code class="OGC">title</code> property of a <code class="GeoAPI">Citation</code> object),
+but otherwise does not process the values.
+Exceptions to this rule are deprecated properties,
+which are not stored but rather redirected to their replacements.
+</p>
+
<section>
<header>
-<h2 id="GetMetadataElement"><span class="section-number">5.1.</span> Navigating in metadata elements</h2>
+<h2 id="NavigateMetadata"><span class="section-number">5.1.</span> Navigating in metadata elements</h2>
</header>
<p>
-Methods like <code class="GeoAPI">getExtents()</code> are efficient when looking for a particular element known at compile-time.
-But those elements may be deep in the tree structure and may require traversal of many optional elements and collection members,
-which is sometimes tedious. For a few frequently-used elements, some convenience methods are provided.
+The metadata modules provide support methods for handling the metadata objects through Java Reflection.
+This is an approach similar to <cite>Java Beans</cite>, in that users are encouraged to use directly the API of
+Plain Old Java objects every time their type is known at compile time,
+and fallback on the reflection technic when the type is known only at runtime.
+When using Java reflection, a metadata can be viewed in different ways:
+</p>
+<ul>
+<li>As key-value pairs in a <code>Map</code> (from <code>java.util</code>).</li>
+<li>As a <code>TreeTable</code> (from <code class="SIS">org.apache.sis.util.collection</code>).</li>
+<li>As a table record in a database (using <code class="SIS">org.apache.sis.metadata.sql</code>).</li>
+<li>As an <abbr>XML</abbr> document conforms to <abbr title="International Organization for Standardization">ISO</abbr> standard schema.</li>
+</ul>
+<p>
+The use of reflection is described <a href="#MetadataAsMap">below</a>.
+The <abbr>XML</abbr> representation is described in a <a href="#XML-ISO-19115">separated chapter</a>.
+</p>
+
+<h3 id="GetMetadataElement"><span class="section-number">5.1.1.</span> Direct access via getter methods</h3>
+<p>
+All metadata classes provide getter, and sometime setter, methods for their properties.
+Some properties accept many values, in which case the property type is a collection.
+The following example prints the range of latitudes of all data descriptions
+found in a given root <code class="GeoAPI">Metadata</code> object:
+</p>
+
+<pre><code>
+<b>import</b> org.opengis.metadata.metadata;
+<b>import</b> org.opengis.metadata.extent.<code class="GeoAPI">Extent</code>;
+<b>import</b> org.opengis.metadata.extent.<code class="GeoAPI">GeographicExtent</code>;
+<b>import</b> org.opengis.metadata.extent.<code class="GeoAPI">GeographicBoundingBox</code>;
+<b>import</b> org.opengis.metadata.identification.<code class="GeoAPI">Identification</code>;
+<b>import</b> org.opengis.metadata.identification.<code class="GeoAPI">DataIdentification</code>;
+
+<b>void</b> main() {
+ <code class="GeoAPI">Metadata</code> metadata = ...; <code class="comment">// For example, metadata read from a data store.</code>
+ <b>for</b> (<code class="GeoAPI">Identification</code> identification : metadata.getIdentificationInfo()) {
+ <b>if</b> (identification <b>instanceof</b> <code class="GeoAPI">DataIdentification</code> data) {
+ <b>for</b> (<code class="GeoAPI">Extent</code> extent : data.getExtents()) {
+ <code class="comment">// Extents may have horizontal, vertical and temporal components.</code>
+ <b>for</b> (<code class="GeoAPI">GeographicExtent</code> horizontal : extent.getGeographicElements()) {
+ <b>if</b> (horizontal <b>instanceof</b> <code class="GeoAPI">GeographicBoundingBox</code> bbox) {
+ <b>double</b> south = bbox.getSouthBoundLatitude();
+ <b>double</b> north = bbox.getNorthBoundLatitude();
+ System.out.println(<i>"Latitude range: "</i> + south + <i>" to "</i> + north);
+ }
+ }
+ }
+ }
+ }
+}</code></pre>
+
+<p>
+Because of <abbr title="International Organization for Standardization">ISO</abbr> 19115 richness, interesting information may be buried deeply in the metadata tree, as in above example.
+For a few frequently-used elements, some convenience methods are provided.
Those conveniences are generally defined as static methods in classes having a name in plural form.
For example the <code class="SIS">Extents</code> class defines static methods for fetching more easily some information from <code class="GeoAPI">Extent</code> metadata elements.
For example the following method navigates through different branches where North, South, East and West data bounds may be found:
</p>
-<pre><code><code class="GeoAPI">GeographicBoundingBox</code> bbox = <code class="SIS">Extents</code>.getGeographicBoundingBox(extent);</code></pre>
+
+<pre><code>
+<b>import</b> org.opengis.metadata.metadata;
+<b>import</b> org.opengis.metadata.extent.<code class="GeoAPI">GeographicBoundingBox</code>;
+<b>import</b> org.apache.sis.metadata.iso.extent.<code class="SIS">Extents</code>;
+
+<b>void</b> main() {
+ <code class="GeoAPI">Metadata</code> metadata = ...; <code class="comment">// For example, metadata read from a data store.</code>
+ <code class="GeoAPI">GeographicBoundingBox</code> bbox = <code class="SIS">Extents</code>.getGeographicBoundingBox(extent);
+}</code></pre>
+
<p>
Those conveniences are defined as static methods in order to allow their use with different metadata implementations.
Some other classes providing static methods for specific interfaces are
<code class="SIS">Citations</code>, <code class="SIS">Envelopes</code>, <code class="SIS">Matrices</code> and <code class="SIS">MathTransforms</code>.
</p>
-<h3 id="MetadataAsMap"><span class="section-number">5.1.1.</span> View as key-value pairs</h3>
+<h3 id="MetadataAsMap"><span class="section-number">5.1.2.</span> View as key-value pairs</h3>
<p>
Above static methods explore fragments of metadata tree in search for requested information,
but the searches are still targeted to elements whose types and at least part of their paths are known at compile-time.
@@ -1876,17 +2039,23 @@
In such cases, one can view the metadata as a <code>java.util.Map</code> like below:
</p>
-<pre><code>Map<String,Object> elements = <code class="SIS">MetadataStandard</code>.ISO_19115.<code class="SIS">asValueMap</code>(
- metadata, <code class="comment">// Any instance from the org.opengis.metadata package or a sub-package.</code>
- <b>null</b>, <code class="comment">// Used for resolving ambiguities. We can ignore for this example.</code>
- <code class="SIS">KeyNamePolicy</code>.<code class="SIS">JAVABEANS_PROPERTY</code>, <code class="comment">// Keys in the map will be getter method names without "get" prefix.</code>
- <code class="SIS">ValueExistencePolicy</code>.<code class="SIS">NON_EMPTY</code>); <code class="comment">// Entries with null or empty values will be omitted.</code>
-<code class="comment">/*
- * Print the names of all root metadata elements having a value.
- * This loop does not iterate recursively in children.
- */</code>
-<b>for</b> (String name : elements.keySet()) {
- System.out.println(name);
+<pre><code>
+<b>import</b> java.util.Map;
+<b>import</b> org.apache.sis.metadata.<code class="SIS">MetadataStandard</code>;
+<b>import</b> org.apache.sis.metadata.<code class="SIS">KeyNamePolicy</code>;
+<b>import</b> org.apache.sis.metadata.<code class="SIS">ValueExistencePolicy</code>;
+
+<b>void</b> main() {
+ Map<String,Object> elements = <code class="SIS">MetadataStandard</code>.ISO_19115.<code class="SIS">asValueMap</code>(
+ metadata, <code class="comment">// Any instance from the org.opengis.metadata package or a sub-package.</code>
+ <b>null</b>, <code class="comment">// Used for resolving ambiguities. We can ignore for this example.</code>
+ <code class="SIS">KeyNamePolicy</code>.<code class="SIS">JAVABEANS_PROPERTY</code>, <code class="comment">// Keys in the map will be getter method names without "get" prefix.</code>
+ <code class="SIS">ValueExistencePolicy</code>.<code class="SIS">NON_EMPTY</code>); <code class="comment">// Entries with null or empty values will be omitted.</code>
+
+ <code class="comment">// Print the names of all root metadata elements having a value.</code>
+ <b>for</b> (String name : elements.keySet()) {
+ System.out.println(name);
+ }
}</code></pre>
<p>
@@ -1901,9 +2070,66 @@
(similar to property names but not always identical).
Differences in upper cases and lower cases are ignored when this tolerance does not introduce ambiguities.
For more information on metadata views, see
-<a href="../../apidocs/org/apache/sis/metadata/package-summary.html#package.description"><code class="SIS">org.apache.sis.metadata</code></a>
+<a href="../../apidocs/org.apache.sis.metadata/org/apache/sis/metadata/package-summary.html#package.description"><code class="SIS">org.apache.sis.metadata</code></a>
package javadoc.
</p>
+
+<h3 id="MetadataAsTreeTable"><span class="section-number">5.1.3.</span> View as tree table</h3>
+<p>
+A richer alternative to the view as a map is the view as a tree table.
+With this view, the metadata structure is visible as a tree,
+and each tree node is a table row with the following columns:
+</p>
+<table>
+<caption>Columns of a tree table view of a metadata</caption>
+<tr><th>Column</th> <th>Description</th></tr>
+<tr><td><code class="SIS">IDENTIFIER</code></td> <td>The UML identifier if any, or otherwise the Java Beans name, of the metadata property.</td></tr>
+<tr><td><code class="SIS">INDEX</code></td> <td>If the property is a collection, then the zero-based index of the element in that collection.</td></tr>
+<tr><td><code class="SIS">NAME</code></td> <td>A human-readable name for the node, derived from above identifier and index.</td></tr>
+<tr><td><code class="SIS">TYPE</code></td> <td>The base type of the value (usually a GeoAPI interface).</td></tr>
+<tr><td><code class="SIS">VALUE</code></td> <td>The metadata value for the node. This column may be writable.</td></tr>
+<tr><td><code class="SIS">NIL_REASON</code></td> <td>If the value is mandatory and nevertheless absent, the reason why.</td></tr>
+<tr><td><code class="SIS">REMARKS</code></td> <td>Remarks or warning on the property value.</td></tr>
+</table>
+<p>
+Tree table views are obtained in a way similar to <a href="#MetadataAsMap">map views</a>,
+but using the <code class="SIS">asTreeTable(Object)</code> method instead of <code class="SIS">asValueMap(Object)</code>.
+</p>
+</section>
+
+
+<section>
+<header>
+<h2 id="NilReason"><span class="section-number">5.2.</span> Nil values in mandatory properties</h2>
+</header>
+<p>
+Apache <abbr title="Spatial Information System">SIS</abbr> allows any metadata property to be <code>null</code>
+(for values that are not collections) or an empty collection.
+However, <abbr title="International Organization for Standardization">ISO</abbr> 19115 defines some properties as mandatory.
+For example, the <code class="OGC">title</code> of a <code class="GeoAPI">Citation</code> is mandatory,
+while the <code class="OGC">edition</code> is optional.
+Apache <abbr>SIS</abbr> will not raise any warning or error if a mandatory property is missing.
+But for strict <abbr>ISO</abbr> compliance, the reason why the property is missing should be provided.
+Predefined reasons are:
+</p>
+<table>
+<caption>Predefined nil reasons from <abbr>ISO</abbr> 19115-3</caption>
+<tr><th>Reason</th> <th>Explanation</th></tr>
+<tr><td><code class="OGC">inapplicable</code></td> <td>The property is not applicable.</td></tr>
+<tr><td><code class="OGC">unknown</code></td> <td>The value probably exists but is not known.</td></tr>
+<tr><td><code class="OGC">missing</code></td> <td>The value cannot exist.</td></tr>
+<tr><td><code class="OGC">withheld</code></td> <td>The value cannot be revealed.</td></tr>
+<tr><td><code class="OGC">template</code></td> <td>The value will be available later.</td></tr>
+</table>
+<p>
+The transmission of this information requires the use of a non-null object, even when the value is missing.
+In such case, <abbr>SIS</abbr> will return an object that, besides implementing the desired GeoAPI interface,
+also implements the <code class="SIS">org.apache.sis.xml.NilObject</code> interface.
+This interface flags the instances where all methods return an empty collection, an empty table, <code>null</code>,
+<code>NaN</code>, <code>0</code> or <code>false</code>, in this preference order, as permitted by the return types of the methods.
+Each instance that implements <code class="SIS">NilObject</code> provides a <code class="SIS">getNilReason()</code> method
+indicating why the object is nil.
+</p>
</section>
</section>
@@ -2127,27 +2353,15 @@
<h3 id="nilReason"><span class="section-number">6.1.2.</span> Placeholders for missing values</h3>
<p>
-When a property is not defined, the corresponding GeoAPI method usually returns <code>null</code>.
-However, things become complicated when the missing property is a value considered mandatory by <abbr title="International Organization for Standardization">ISO</abbr> 19115 standard.
-<abbr>ISO</abbr> 19115-3 allows for the omission of mandatory properties so long as the reason for the missing value is indicated.
-The reason may be that the property is not applicable (<code class="OGC">inapplicable</code>),
-that the value probably exists but is not known (<code class="OGC">unknown</code>),
-that the value cannot exist (<code class="OGC">missing</code>),
-or that the value cannot be revealed (<code class="OGC">withheld</code>), <i>etc.</i>
-The transmission of this information requires the use of a non-nul object, even when the value is missing.
-<abbr title="Spatial Information System">SIS</abbr> will then return an object that, besides implementing the desired GeoAPI interface,
-also implements the <code class="SIS">org.apache.sis.xml.NilObject</code> interface.
-This interface flags the instances where all methods return an empty collection, an empty table, <code>null</code>,
-<code>NaN</code>, <code>0</code> or <code>false</code>, in this preference order, as permitted by the return types of the methods.
-Each instance that implements <code class="SIS">NilObject</code> provides a <code class="SIS">getNilReason()</code> method
-indicating why the object is nil.
-</p>
-<p>
+If a mandatory property value is missing, a <a href="#NilReason">nil reason should be provided</a>.
+The reason is specified in a <code class="OGC">nilReason</code> attribute, which can take values such as
+<code class="OGC">unknown</code>, <code class="OGC">missing</code>, <code class="OGC">inapplicable</code>,
+<code class="OGC">withheld</code>, <code class="OGC">template</code>, <i>etc.</i>
In the following example, the left side shows a <code class="OGC">CI_Citation</code> element containing a
<code class="OGC">CI_Series</code> element, while on the right side the series is unknown.
If the <code class="OGC">CI_Series</code> element had been completely omitted,
then the <code class="GeoAPI">Citation.getSeries()</code> method would return <code>null</code> in Java.
-But when a <code class="OGC">nilReason</code> is present, the <abbr>SIS</abbr> implementation of
+But when a <code class="OGC">nilReason</code> is present, the <abbr title="Spatial Information System">SIS</abbr> implementation of
<code class="SIS">getSeries()</code> returns instead an object that implements both the
<code class="GeoAPI">Series</code> and <code class="SIS">NilReason</code> interfaces, and in which the
<code class="SIS">getNilReason()</code> method returns the constant <code class="SIS">UNKNOWN</code>.
@@ -2828,7 +3042,8 @@
At this time, the wave of web services had not yet eclipsed classical programming interfaces.
The interfaces of the <abbr>OGC</abbr> did anticipate a networked world,
but invested rather — in the case of Java — in <abbr>RMI</abbr> (<i>Remote Method Invocation</i>) technology.
-As the GeoAPI project did not yet exist, we retroactively designate these historical interfaces “<a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a>”.
+As the GeoAPI project did not yet exist, we retroactively designate these historical interfaces
+“<a href="http://www.geoapi.org/archives/1.0/index.html">GeoAPI 1.0</a>”.
These interfaces already used the package name <code class="GeoAPI">org.opengis</code>, which would be adopted by GeoAPI.
</p><p>
In 2002, developers of free projects launched a
diff --git a/book/fr/developer-guide.html b/book/fr/developer-guide.html
deleted file mode 100644
index 2643e8a..0000000
--- a/book/fr/developer-guide.html
+++ /dev/null
@@ -1,3868 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?><!--
-
- Licensed to the Apache Software Foundation (ASF)
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- This is an automatically generated file. DO NOT EDIT.
- See the files in the `content/developer-guide` directory instead.
-
---><!DOCTYPE html SYSTEM "about:legacy-compat">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
-
-<head>
-<title>Introduction à Apache SIS</title>
-<meta charset="UTF-8"/>
-<link href="../book.css" rel="stylesheet" type="text/css"/>
-<script src="../toc.js">/* highlighter */</script>
-</head>
-<body>
-<nav>
-<p>Table des matières</p>
-<ul>
-<li><a href="#Standards">Standards et normes</a><ul>
-<li><a href="#ConceptualModels">Sources des modèles conceptuels de Apache SIS</a></li>
-<li><a href="#GeoAPI">Des modèles conceptuels vers des interfaces Java: GeoAPI</a><ul>
-<li><a href="#GeoAPI-implementation">Implémentations fournies par Apache SIS</a></li></ul></li>
-<li><a href="#AboutBook">Conventions utilisées dans ce guide</a><ul>
-<li><a href="#ChosenTerms">Choix des termes</a></li></ul></li></ul></li>
-<li><a href="#DataAccess">Accès aux données géospatiales</a><ul>
-<li><a href="#GetMetadataElement">Parcourir les méta-données</a></li></ul></li>
-<li><a href="#Coverage">Couvertures de données (Coverages)</a></li>
-<li><a href="#Geometry">Géométries</a><ul>
-<li><a href="#GeometryBase">Classes de base</a><ul>
-<li><a href="#DirectPosition">Points et positions directes</a></li>
-<li><a href="#Envelope">Enveloppes</a></li></ul></li></ul></li>
-<li><a href="#Referencing">Systèmes de références spatiales</a><ul>
-<li><a href="#ComponentsOfCRS">Composantes d’un système de références par coordonnées</a><ul>
-<li><a href="#Ellipsoid">Géoïde et ellipsoïde</a></li>
-<li><a href="#GeodeticDatum">Référentiel géodésique</a></li>
-<li><a href="#CoordinateSystem">Systèmes de coordonnées</a></li>
-<li><a href="#GeographicCRS">Systèmes géographiques</a></li>
-<li><a href="#ProjectedCRS">Projections cartographiques</a></li></ul></li>
-<li><a href="#CoordinateOperations">Opérations sur les coordonnées</a><ul>
-<li><a href="#CRS.findOperation">Obtention d’une opération sur les coordonnées</a></li>
-<li><a href="#MathTransform">Exécution de opérations</a></li>
-<li><a href="#TransformDerivative">Dérivées partielles des opérations</a></li></ul></li>
-<li><a href="#Formats">Formats de stockage des données</a></li>
-<li><a href="#XML-ISO">Représentation des objets en XML</a><ul>
-<li><a href="#XML-ISO-19115">Représentation des méta-données selon ISO 19115-3</a></li></ul></li></ul></li>
-<li><a href="#Utilities">Classes et méthodes utilitaires</a><ul>
-<li><a href="#ComparisonModes">Modes de comparaisons des objets</a></li>
-<li><a href="#ObjectConverters">Convertisseurs d’objets</a></li>
-<li><a href="#Internationalization">Internationalisation</a><ul>
-<li><a href="#LocalizedString">Chaînes de caractères distinctes pour chaque conventions locales</a></li>
-<li><a href="#InternationalString">Instance unique pour toutes les conventions locales</a></li>
-<li><a href="#Locale.ROOT">Convention Locale.ROOT</a></li>
-<li><a href="#UnicodePoint">Traitement des caractères</a></li></ul></li></ul></li>
-<li><a href="#GeoAPI-details">Relation entre GeoAPI et les standards</a><ul>
-<li><a href="#GeoAPI-modules">Les modules de GeoAPI</a></li>
-<li><a href="#SpecificationToInterfaces">Des spécifications de l’OGC aux interfaces Java</a><ul>
-<li><a href="#UML-annotation">Correspondances explicites entre GeoAPI et les spécifications abstraites</a></li>
-<li><a href="#MappingToJDK">Correspondances implicites avec le JDK standard</a></li></ul></li>
-<li><a href="#ReduceDependency">Réduire la dépendance directe envers Apache SIS</a><ul>
-<li><a href="#UML-annotation-indep">Correspondances entre GeoAPI et les spécifications abstraites</a></li>
-<li><a href="#ServiceLoader">Obtenir une implémentation des interfaces de GeoAPI</a></li></ul></li></ul></li>
-<li><a href="#Tests">Les suites de tests</a><ul>
-<li><a href="#GeoAPI-conformance">Conformance avec GeoAPI</a><ul>
-<li><a href="#GeoAPI-validators">Validations des instances</a></li>
-<li><a href="#GeoAPI-tests">Exécution des tests pré-définis</a></li></ul></li></ul></li>
-<li><a href="#DesignNotes">Notes de design</a><ul>
-<li><a href="#AffineTransform">Utilisation des transformations affines</a><ul>
-<li><a href="#AffineTransformAPI">Intégration avec les bibliothèques graphiques</a></li></ul></li>
-<li><a href="#MatrixLibrary">Particularités d’une bibliothèque de calculs matriciels pour un SIG</a><ul>
-<li><a href="#NonSquareMatrix">Que faire des matrices qui ne sont pas carrées (et pourquoi)</a></li>
-<li><a href="#MatrixLibrarySummary">La bibliothèque matricielle de Apache SIS</a></li></ul></li></ul></li>
-</ul>
-</nav>
-
-<main>
-<p style="margin-top:30pt; font-size:30pt; font-weight:900; text-align:center">
-Introduction à Apache SIS™
-</p>
-<div class="warning" style="position:sticky; top:0; font-size:18px; padding:32px; border-width:3px">
-Cette page est une traduction de la version anglaise du guide.
-Cette traduction n’est pas maintenue et peut être obsolète.
-Pour des informations plus à jour, voir la <a href="../en/developer-guide.html">version anglaise</a>.
-</div>
-
-
-
-
-
-
-
-
-
-
-
-
-<section>
-<header>
-<h1 id="Standards"><span class="section-number">1.</span> Standards et normes</h1>
-</header>
-<p>
-Une communauté d’informations géospatiales est un ensemble de systèmes ou d’individus capables d’échanger
-leurs données géospatiales grâce à des définitions et des standards communs ainsi qu’une reconnaissance réciproque.
-Comme il existe une multitude de façons de représenter des informations géospatiales,
-chaque communauté est amenée à les structurer en fonction de ses centres d’intérêts.
-Cette diversité complique la tâche des utilisateurs de systèmes d’information géographiques (<abbr>SIG</abbr>)
-en les plaçant devant une variété apparemment chaotique de formats et de structures de données.
-Les caractéristiques de ces structures varient en fonction des phénomènes observés et des méthodes de mesure,
-ainsi que des habitudes des organisations produisant les données.
-Une telle variété agit comme un frein aux études qui requièrent des combinaisons de données hétérogènes,
-surtout lorsqu’elles proviennent de communautés traditionnellement distinctes.
-Par exemple, un chercheur étudiant le choléra peut s’intéresser aux populations de crevettes comme vecteur de propagation de la maladie.
-Mais les médecins et les océanographes n’ayant pas forcement l’habitude de partager leurs travaux,
-les participants à une telle étude peuvent être limités par les efforts qu’ils sont disposés à fournir pour convertir les données.
-</p><p>
-Nous ne pouvons pas imposer un format uniforme à l’ensemble des données, car la diversité des formats tient
-à des facteurs tels que les contraintes des appareils de mesure et la distribution statistique des valeurs.
-Une solution plus flexible consiste à assurer l’interopérabilité des données à travers une interface de programmation
-(<abbr title="Application Programming Interface">API</abbr>) commune.
-Cette <abbr>API</abbr> n’est pas forcement définie dans un langage de programmation;
-la tendance actuelle est plutôt de définir des conventions utilisant les protocoles web existants,
-que l’on peut transposer dans des langages de programmation.
-Mais pour que cette démarche puisse être pérennisée, l’<abbr>API</abbr> doit être largement accepté par des développeurs indépendants.
-Autrement dit, l’<abbr>API</abbr> doit s’approcher autant que possible des standards industriels.
-</p><p>
-Les accès aux bases de données relationnelles sont un exemple de tâche ayant bénéficié d’une standardisation relativement bien réussie.
-L’industrie a établie un langage commun — le standard <abbr title="Structured Query Language">SQL</abbr> — que les concepteurs du Java
-ont enrobé dans des interfaces de programmation formant le standard <abbr title="Java DataBase Connectivity">JDBC</abbr>.
-Ces interfaces sont aujourd’hui implementées par de nombreux logiciels libres et commerciaux.
-Comme pour les bases de données, des méthodes d’accès aux informations géographiques ont été standardisées.
-Mais les efforts en ce sens sont plus récents et leurs intégrations dans les logiciels, surtout les plus anciens,
-sont incomplètes et pas toujours cohérentes.
-Au moment d’écrire ces lignes, aucun produit de notre connaissance n’implémente la totalité des spécifications.
-Mais on trouve de nombreuses implémentations couvrant un spectre plus ou moins large.
-La bibliothèque Apache <abbr>SIS</abbr>™ décrite dans ce document en est une.
-</p><p>
-Apache <abbr title="Spatial Information System">SIS</abbr> se caractérise par un effort soutenu de respect des standards.
-De manière générale, le respect des standards exige un effort plus grand que ce qu’aurait requis un développement isolé,
-mais se rentabilise par un double avantage: en plus d’accroître l’interopérabilité des données avec celles des projets externes,
-il nous indique aussi une voie robuste à suivre pour l’élaboration du modèle conceptuel qui sera reflété par l’<abbr>API</abbr>.
-En effet, les groupes d’experts qui conçoivent les standards anticipent des difficultés qui échappent parfois à l’ingénieur en début de projet,
-mais qui risquent de le rattraper avant la fin.
-</p>
-
-
-
-
-
-
-<section>
-<header>
-<h2 id="ConceptualModels"><span class="section-number">1.1.</span> Sources des modèles conceptuels de Apache SIS</h2>
-</header>
-<p>
-La majorité des standards utilisés par Apache <abbr title="Spatial Information System">SIS</abbr> ont été élaborés
-par le <a href="https://www.ogc.org/">consortium <i>Open Geospatial</i></a> (<abbr>OGC</abbr>),
-parfois en collaboration avec l’<a href="https://www.iso.org/">organisation internationale de normalisation</a> (<abbr>ISO</abbr>).
-Certains standards de l’<abbr>ISO</abbr> deviennent eux-mêmes des standards Européens via la
-<a href="http://inspire.jrc.ec.europa.eu">directive INSPIRE</a>, ou des standards français via l’<abbr>AFNOR</abbr>.
-Ces standards offrent deux technologies clés:
-</p>
-<ul>
-<li>
-Permettre à une communauté d’annoncer leurs informations,
-de manière à ce que des individus ou des systèmes en dehors de cette communauté puissent les découvrir.
-</li>
-<li>
-Transférer des informations d’une communauté vers une autre en préservant leurs sémantiques,
-même si les deux communautés utilisent des représentations internes très différentes.
-</li>
-</ul>
-<p>
-Ces standards sont fournis gratuitement à la communauté internationale sous la forme de
-<a href="https://www.ogc.org/standards/is">spécifications (fichiers <abbr title="Portable Document Format">PDF</abbr>)</a> ou de
-<a href="http://schemas.opengis.net/gml/3.3/">schémas (fichiers <abbr title="XML Schema Definition">XSD</abbr>)</a>.
-Les organismes de normalisation ne fabriquent pas de logiciel; pour obtenir une implémentation de ces spécifications,
-les utilisateurs doivent choisir un des produits conformes disponibles sur le marché ou développer leur propres solutions.
-C’est le respect volontaire de ces spécifications qui permet à des communautés à priori indépendantes d’échanger
-plus facilement des informations géographiques.
-</p>
-
-
-
-<details>
-<summary>Pour en savoir plus sur le processus de standardisation</summary>
-<article id="OGC-process">
-<header>
-<h2>Processus de standardisation à l’<abbr>OGC</abbr></h2>
-</header>
-<p>
-Les travaux de l’<abbr title="Open Geospatial Consortium">OGC</abbr> se font par courriers électroniques,
-par conférences téléphoniques et par <a href="https://www.ogc.org/event?category=ogctcpc">réunions réelles</a>.
-L’<abbr>OGC</abbr> organise quatre réunions par années, chacune d’une durée de cinq jours,
-hébergées par des organisations membres sponsorisant l’événement (compagnies, universités, centres de recherches, <i>etc.</i>).
-Le continent hôte alterne entre l’Europe et l’Amérique du Nord, avec une présence croissante en Asie depuis 2011.
-Ces réunions reçoivent habituellement entre 50 et 100 participants parmi les centaines de membres de l’<abbr>OGC</abbr>.
-Certains participants sont présents à quasiment toutes les réunions et constituent des piliers de l’organisation.
-Les réunions de l’<abbr>OGC</abbr> offrent des opportunités d’échanges avec des membres d’horizons diverses.
-</p><p>
-La création d’un standard <abbr>OGC</abbr> commence par le regroupement d’organisations ou d’individus constatant un intérêt commun pour une problématique.
-Un groupe de travail est proposé sous l’appellation de <i>Domain Working Group</i> (<abbr>DWG</abbr>) ou <i>Standard Working Group</i> (<abbr>SWG</abbr>).
-Les <abbr>DWG</abbr> sont ouverts à tout membre de l’<abbr>OGC</abbr>,
-tandis que les <abbr>SWG</abbr> nécessitent de la part des participants un engagement à ne pas entraver
-la diffusion du standard par des réclamations de propriétés intellectuelles.
-</p>
-
-<h3 id="OGC-SWG">Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</h3>
-<p>
-Pour être accepté, un projet de standardisation doit être supporté par un nombre minimal de membres appartement à des organisations distinctes.
-Ces membres fondateurs rédigent une charte définissant les objectifs du <abbr>SWG</abbr>,
-qui doit être approuvée par le comité technique de l’<abbr title="Open Geospatial Consortium">OGC</abbr>.
-Chaque membre fondateur est doté d’un droit de vote, dans les limites d’un membre votant par organisation.
-Tout nouveau membre qui souhaite joindre le <abbr>SWG</abbr> après sa création se verra attribué un rôle d’observateur,
-avec attribution sur demande d’un droit de vote après quelques mois d’observation.
-</p><p>
-Un <abbr>SWG</abbr> peut contenir plusieurs dizaines de membres,
-mais les volontaires effectuant l’essentiel du travail sont habituellement moins nombreux.
-Leurs propositions sont soumises à l’ensemble des membres du groupe, qui peuvent les accepter par consentement unanime.
-Les objections, s’il y en a, doivent être argumentées et une alternative proposée.
-Les <abbr>SWG</abbr> essaient généralement de débattre d’un problème jusqu’à ce qu’un consensus se forme
-plutôt que d’avancer malgré des votes négatifs, même s’ils sont minoritaires.
-Les décisions du groupes sont alors intégrées dans la spécification par un membre assumant le rôle d’éditeur.
-</p><p>
-Le groupe de travail doit autant que possible structurer la spécification sous forme d’un noyau autour duquel gravite diverses extensions.
-Une suite de tests doit accompagner le standard, et permettre de classer les implémentations en fonction du niveau des tests passés.
-Au moins une <i>implémentation de référence</i> passant les tests doit exister pour démontrer que le standard est utilisable.
-</p><p>
-Lorsque le standard est jugé prêt, le <abbr>SWG</abbr> vote une motion
-proposant de le soumettre au vote des instances supérieures de l’<abbr>OGC</abbr>.
-Cette procédure nécessite plusieurs mois.
-Il existe une procédure plus rapide pour entériner des standards de fait, mais elle n’est appliquée qu’avec parcimonie.
-</p>
-
-<h3 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</h3>
-<p>
-Toute proposition de standard est d’abord examinée par le conseil d’architecture (<i><abbr title="Open Geospatial Consortium">OGC</abbr> Architecture Board</i> — <abbr>OAB</abbr>).
-Ce conseil vérifie que le standard répond aux exigences de l’<abbr>OGC</abbr> sur la forme,
-sur la modularisation, et en termes d’intégration avec les autres standards.
-Si l’<abbr>OAB</abbr> donne son aval, le standard est alors soumis au vote des membres du comité technique (<abbr>TC</abbr>).
-Ce comité regroupe les principaux membres de l’<abbr>OGC</abbr> qui sont seuls habilités à donner le vote final.
-En cas d’approbation, le standard est diffusé publiquement pour commentaires pendant une période de quelques mois.
-Au terme de cette période, le <abbr title="Standard Working Group">SWG</abbr> doit examiner et répondre à chacun des commentaires.
-Les éventuelles modifications au standard sous soumises à l’<abbr>OAB</abbr>, puis le standard est définitivement publié.
-Cette diffusion est alors annoncée par un communiqué de presse de l’<abbr>OGC</abbr>.
-</p><p>
-Certains membres de l’<abbr title="Open Geospatial Consortium">OGC</abbr> et du <abbr title="Technical Committe">TC</abbr>
-assurent aussi la liaison avec l’organisation internationale de normalisation (<abbr title="International Organization for Standardization">ISO</abbr>).
-La coopération entre les deux organismes va dans les deux sens: l’<abbr>OGC</abbr> adopte les standards <abbr>ISO</abbr> comme base sur
-laquelle développer de nouveaux standards, et certains de ces nouveaux standards <abbr>OGC</abbr> deviennent des standards <abbr>ISO</abbr>.
-</p>
-
-<h3 id="OGC-RFC">Procédure de soumission de propositions de modifications</h3>
-<p>
-Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications à des standards <abbr title="Open Geospatial Consortium">OGC</abbr>.
-Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles,
-sont <a href="https://www.ogc.org/standards/cr">disponibles en ligne</a>.
-Chaque proposition est revue par le <abbr title="Standard Working Group">SWG</abbr>.
-</p><p>
-Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle, par exemple GitHub,
-hébergés en dehors des structures de l’<abbr>OGC</abbr>.
-</p>
-</article>
-</details>
-
-
-
-<p>
-Outre ces organisations formelles de normalisation, il existe aussi des organisations qui ne sont pas officiellement
-dédiées à l’élaboration de normes mais dont les travaux ont été largement adoptés comme standards de fait.
-En particulier, la base de données <a href="https://epsg.org/">EPSG</a> fournit des codes numériques permettant d’identifier
-facilement un système de référence des coordonnées parmi <a href="../../tables/CoordinateReferenceSystems.html">plusieurs milliers</a>.
-Cette base de données est offerte par des compagnies pétrolières qui ont vu leur intérêt à ce que leurs prospections se fassent
-bien à l’endroit voulu, sachant qu’elles ne contrôlent pas toujours la production des cartes sur lesquelles elles se positionnent.
-D’autres exemples de standards de fait sont les formats
-<a href="http://geotiff.osgeo.org">GeoTIFF</a> pour les données réparties sur une grille (les images), et
-<a href="http://fr.wikipedia.org/wiki/Shapefile">Shapefile</a> pour les données vectorielles (les géométries).
-</p><p>
-Les standards <abbr>OGC</abbr> sont spécifiés dans plusieurs dizaines de documents.
-Chaque document élabore un service, par exemple les transformations de coordonnées.
-Le fonctionnement de chaque service est décrit par un ensemble de classes d’objets et leurs interactions.
-Ces éléments sont illustrés par des diagrammes <abbr>UML</abbr> (<i>Unified Modeling Language</i>)
-dans des spécifications dites « abstraites ».
-Les <a href="https://www.ogc.org/standards/as">spécifications abstraites</a> ne font référence à aucun langage informatique concret.
-Leurs concepts peuvent se concrétiser dans un langage de programmation, une base de données ou un schéma <abbr>XML</abbr> de manière plus ou moins directe.
-Il existe toutefois une part d’arbitraire dans la façon de concrétiser une spécification abstraite, étant donné que des ajustements sont souvent nécessaires
-pour tenir compte des contraintes ou des conventions du langage ciblé.
-Certaines structures de données n’existent que dans quelques langages, par exemple les unions qui existent en C/C++ mais pas en Java.
-</p>
-
-
-
-<details>
-<summary>Pour en savoir plus sur les « spécifications d’implémentation »</summary>
-<article id="implementation-standard">
-<header>
-<h2>Note historique</h2>
-</header>
-<p>
-Au tournant du millénaire, les spécifications abstraites étaient explicitement concrétisées dans des <i>spécifications d’implémentations</i>.
-Le terme « implémentation » était ici à prendre au sens de tout type d’interfaces (Java ou autres) dérivées des diagrammes
-<abbr title="Unified Modeling Language">UML</abbr> — et non pas d’implémentations au sens du Java.
-Des telles spécifications existaient pour les langages <abbr title="Structured Query Language">SQL</abbr>,
-<abbr title="Common Object Request Broker Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr> et Java.
-Ces langages étant capables d’exécuter des procédures, les spécifications de cette époque définissaient
-non seulement des structures de données, mais aussi des opérations s’appliquant sur ces structures.
-</p><p>
-Par la suite, l’engouement pour le « web 2.0 » a fait grimper l’intérêt pour le <abbr>XML</abbr> au détriment des autres langages.
-Les anciennes spécifications d’implémentations ont été dépréciées, et les schémas <abbr title="XML Schema Definition">XSD</abbr>
-sont devenus la principale concrétisation des spécifications abstraites.
-Même la façon de concevoir les spécifications abstraites a évoluée: les opérations y sont plus rarement définies,
-par conséquence ce qui reste ressemble davantage à des descriptions de schémas de base de données.
-Certaines opérations qui étaient définies dans les anciennes normes apparaissent maintenant, sous une autre forme, dans les spécifications des services web.
-Enfin le terme « spécification d’implémentation » a été abandonné, pour être englobé dans « standard <abbr title="Open Geospatial Consortium">OGC</abbr> ».
-Mais malgré leur dépréciation, les <a href="https://www.ogc.org/docs/retired">anciennes spécifications d’implémentation</a>
-restent utiles aux programmes en langage Java car:
-</p>
-<ul>
-<li>
-Leurs modèles plus simples, appliqués aux mêmes concepts, aident à comprendre les nouvelles spécifications.
-</li>
-<li>
-Ils définissent parfois des façons simples d’effectuer des tâches courantes
-là où les nouvelles spécifications se limitent au cas général.
-</li>
-<li>
-Les opérations étant plus souvent omises dans les nouvelles spécifications,
-les anciennes spécifications restent un complément utile pour définir des <abbr title="Application Programming Interface">API</abbr>.
-</li>
-</ul>
-<p>
-Le projet Apache <abbr title="Spatial Information System">SIS</abbr> se base sur les spécifications les plus récentes,
-tout en puisant dans les archives de l’<abbr title="Open Geospatial Consortium">OGC</abbr>
-pour compléter certains standards abstraits ou les rendre un peu plus facile d’utilisation.
-Certaines anciennes définitions sont conservées comme « méthodes de commodités »,
-n’apportant pas toujours de nouvelles fonctionnalités mais facilitant l’usage pratique d’une bibliothèque.
-</p>
-</article>
-</details>
-</section>
-
-
-<section>
-<header>
-<h2 id="GeoAPI"><span class="section-number">1.2.</span> Des modèles conceptuels vers des interfaces Java: GeoAPI</h2>
-</header>
-<p>
-Le projet <a href="http://www.geoapi.org">GeoAPI</a> offre un ensemble d’interfaces Java pour les applications géo-spatiales.
-Dans une séries de paquets <code class="GeoAPI">org.opengis.*</code>, GeoAPI définit des structures représentant des méta-données,
-des systèmes de référence des coordonnées, ainsi que des opérations effectuant des projections cartographiques.
-Dans une partie qui n’est pas encore standardisée — dénommée <i>pending</i> — GeoAPI définit des structures
-représentant des images géo-référencées, des géométries, des filtres pouvant s’appliquer à des requêtes, et d’autres fonctionnalités.
-Ces interfaces suivent de très près les spécifications de l’<abbr title="Open Geospatial Consortium">OGC</abbr>, tout en les interprétant et en les adaptant
-de manière à répondre aux attentes des développeurs Java — par exemple en se conformant aux conventions de nommage.
-Ces interfaces bénéficient à la fois aux applications clientes et aux bibliothèques:
-</p>
-<ul>
-<li><p>
-Les développeurs des applications clientes bénéficient d’une plus grande base de connaissances disponible sur internet
-(due aux nombreuses publications en lien avec les standards de l’<abbr>OGC</abbr>), ainsi que d’une interopérabilité accrue.
-L’interopérabilité est facilitée par une meilleure séparation entre les applications qui <em>appellent</em> les fonctions de GeoAPI,
-et les bibliothèques qui <em>implémentent</em> GeoAPI. Il s’agit d’une séparation similaire à celle qu’offrent les interfaces
-<a href="http://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/"><abbr title="Java DataBase Connectivity">JDBC</abbr></a> (<i>Java Database Connectivity</i>) du Java standard.
-En utilisant l’<abbr title="Application Programming Interface">API</abbr> des interfaces, les développeurs peuvent faire abstraction de l’implémentation sous-jacente.
-Par exemple ils peuvent effectuer des projections cartographiques à l’aide des bibliothèques
-<a href="http://www.geoapi.org/geoapi-proj4/index.html">Proj.4</a> ou Apache <abbr title="Spatial Information System">SIS</abbr>,
-sans changer leurs programmes lorsqu’ils changent de bibliothèque.
-</p></li>
-<li><p>
-Les développeurs des bibliothèques héritent de l’expertise des auteurs des spécifications, via les modèles que représentent les interfaces.
-GeoAPI fournit aussi un cadre dans lequel les développeurs peuvent implémenter en priorité les fonctionnalité qui leurs sont le plus nécessaires,
-tout en ayant des points où raccrocher les développements futurs.
-Par exemple les clients peuvent appeler une fonction de GeoAPI même si elle n’est pas encore supportée par la bibliothèque,
-quitte à obtenir une valeur nulle en attendant qu’une nouvelle version de la bibliothèque retourne une valeur intéressante.
-</p></li>
-</ul>
-
-<details>
-<summary>Pour en savoir plus sur les origines du projet GeoAPI</summary>
-<article id="GeoAPI-history">
-<header>
-<h2>Historique du projet GeoAPI</h2>
-</header>
-<p>
-En 2001, le consortium <i>Open GIS</i> (l’ancien nom du consortium <i>Open Geospatial</i>) publia la spécification d’implémentation
-<a href="https://www.ogc.org/standards/ct"><abbr title="Open Geospatial Consortium">OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
-Cette spécification, élaborée par <i>Computer Aided Development Corporation</i> (Cadcorp),
-était accompagnée d’interfaces <abbr title="Component Object Model">COM</abbr>, <abbr title="Common Object Request Broker Architecture">CORBA</abbr> et Java.
-À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques.
-Les interfaces de l’<abbr>OGC</abbr> anticipaient tout de même un monde connecté en réseau,
-mais misaient plutôt — dans le cas du Java — sur la technologie <abbr>RMI</abbr> (<i>Remote Method Invocation</i>).
-Bien que le projet GeoAPI n’existait pas encore, nous désignons rétrospectivement ces interfaces historiques sous le nom de
-« <a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a> ».
-Ces interfaces utilisaient déjà le nom de paquet <code class="GeoAPI">org.opengis</code>, qui sera adopté par GeoAPI.
-</p><p>
-En 2002, des développeurs de projets libres ont lancé un
-<a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr title="Application Programming Interface">API</abbr> géo-spatial</a>.
-La proposition initiale suscita l’intérêt d’au moins cinq projets libres.
-Le projet fut créé sur <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
-qui héberge depuis lors le code source dans un <a href="http://www.geoapi.org/source-repository.html">dépôt Subversion</a>.
-Le projet pris le nom de « GeoAPI » à ce moment là, et utilisa les interfaces de la spécification <abbr>OGC</abbr> 01-009 comme point de départ.
-</p><p>
-Quelques mois plus tard, l’<abbr>OGC</abbr> lança le projet
-<a href="https://www.ogc.org/standards/go"><abbr>GO-1</abbr>: <i>Geographic Objects</i></a>,
-qui poursuivait des buts similaires à ceux de GeoAPI.
-Entre-temps, l’<abbr>OGC</abbr> avait abandonné certaines de leur spécifications en faveur des normes <abbr title="International Organization for Standardization">ISO</abbr>.
-GeoAPI et <abbr>GO-1</abbr> ont joint leurs efforts pour une refonte des interfaces de GeoAPI en les basant sur ces nouvelles normes <abbr>ISO</abbr>.
-La première mouture, <a href="http://www.geoapi.org/1.0/index.html">GeoAPI 1.0</a>, a servit de point de départ
-aux premières ébauches de la spécification <abbr>OGC</abbr> 03-064 du groupe de travail <abbr>GO</abbr>-1.
-La version finale de cette spécification est devenue un standard <abbr>OGC</abbr> en 2005, et
-<a href="http://www.geoapi.org/2.0/index.html">GeoAPI 2.0</a> a été publiée à cette occasion.
-</p><p>
-Le projet <abbr>GO</abbr>-1 était porté essentiellement par une compagnie nommée <i>Polexis</i>.
-Son rachat par <i>Sys Technology</i> et le changement de priorité des nouveaux propriétaires
-ont causé l’arrêt des travaux de <abbr>GO</abbr>-1, et par ricochet un ralentissement des développements de GeoAPI.
-Afin de reprendre les développements, un nouveau groupe de travail « GeoAPI 3.0 » a été créé à l’<abbr>OGC</abbr>.
-Ce groupe a réduit les ambitions par rapport à GeoAPI 2.0 en se concentrant sur les interfaces les plus stables,
-et en plaçant les autres — notamment les géométries — dans un module nommé « <a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a> »,
-pour considérations futures. <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> est devenu un
-<a href="https://www.ogc.org/standards/geoapi">standard <abbr>OGC</abbr></a> en 2011.
-Cette version a été la première à être déployée dans le <a href="http://search.maven.org/#search|ga|1|geoapi">dépôt central de Maven</a>.
-</p>
-</article>
-</details>
-
-<p id="GeoAPI-core">
-GeoAPI est constitué de plusieurs modules.
-Les modules <code class="GeoAPI">geoapi</code> et <code class="GeoAPI">geoapi-pending</code>
-fournissent les interfaces dérivées des schémas <abbr title="Unified Modeling Language">UML</abbr> des standards internationaux.
-Le modèle conceptuel sera expliqué en détails dans les chapitres décrivant l’implémentation Apache <abbr title="Spatial Information System">SIS</abbr>.
-On peut toutefois avoir un aperçu de son contenu en consultant la page listant les
-<a href="http://www.geoapi.org/3.0/javadoc/content.html">types et méthodes de GeoAPI et les standards d’où ils proviennent</a>.
-Ces modules ainsi que la correspondance entre GeoAPI et les standards internationaux sont décrits plus en détails
-<a href="#SpecificationToInterfaces">en annexe</a>.
-</p>
-
-
-
-<h3 id="GeoAPI-implementation"><span class="section-number">1.2.1.</span> Implémentations fournies par Apache SIS</h3>
-<p>
-Apache SIS implémente la plupart des interfaces de GeoAPI avec une classe du même nom que l’interface,
-mais préfixée de « <code>Abstract</code> », « <code>Default</code> » ou « <code>General</code> ».
-Les classes de Apache SIS qui sont préfixées par « <code>Default</code> » peuvent être instanciées directement
-par une instruction <code>new DefaultXXX(…)</code> ou par la méthode <code>createXXX(…)</code> correspondante d’une fabrique.
-</p>
-<div class="example"><b>Example:</b> pour représenter un système de référence de coordonnées projetées (Mercator, Lambert, <i>etc</i>):
-<ul>
-<li><code class="GeoAPI">org.opengis.referencing.crs.ProjectedCRS</code> est l’interface définie par GeoAPI sur la base du standard ISO 19111, et</li>
-<li><code class="SIS">org.apache.sis.referencing.crs.DefaultProjectedCRS</code> est l’implémentation fournie par Apache SIS.</li>
-</ul>
-Une instance peut être créée par:
-<ul>
-<li><code>ProjectedCRS crs = new DefaultProjectedCRS(…)</code>, ou</li>
-<li><code>ProjectedCRS crs = CRSFactory.createProjectedCRS(…)</code>.</li>
-</ul>
-Les deux approches attendent les mêmes arguments (omis dans cet exemple).
-</div>
-<p>
-Dans la configuration par défaut de Apache SIS,
-utiliser <code>FooFactory.createXXX(…)</code> ou <code>new DefaultXXX(…)</code> revient presque au même
-excepté que les <code>FooFactory</code> peuvent retourner des instances existantes
-plutôt que de créer systématiquement de nouvelles instances,
-et que les exceptions en cas d’arguments invalides sont de types différents.
-Dans des configurations plus avancées, l’usage des <code class="GeoAPI">Factory</code> permet de
-<a href="#ServiceLoader">réduire la dépendance directe d’une application envers SIS</a>
-et de permettre une inversion de contrôle.
-</p><p>
-Le préfix « <code>General</code> » est parfois utilisé à la place de « <code>Default</code> »
-afin de signaler que des implémentations alternatives existent pour des cas spécifiques.
-Par exemple l’interface <code class="GeoAPI">Envelope</code> est implémentée par au moins deux classes de Apache SIS:
-<code class="SIS">GeneralEnvelope</code> et <code class="SIS">Envelope2D</code>.
-La première implémentation peut représenter des enveloppes de n’importe quelle dimension
-alors que la seconde implémentation est spécialisée pour les enveloppes à deux dimensions.
-</p><p>
-Les classes de Apache SIS qui sont préfixées par « <code>Abstract</code> » ne doivent pas – en principe – être instanciées.
-Il faut plutôt instancier une sous-classe non-abstraites.
-Toutefois plusieurs classes de SIS ne sont abstraites que conceptuellement,
-sans que la définition de la classe ne contienne le mot-clé <code>abstract</code> du Java.
-Ces classes peuvent être instanciées par l’instruction <code>new AbstractXXX(…)</code>
-– mais pas par les <code class="GeoAPI">Factory</code> – malgré qu’elles soient conceptuellement abstraites.
-Mais ces instanciations ne devraient être faites qu’en dernier recours,
-lorsqu’il n’est vraiment pas possible de déterminer le sous-type exact.
-</p>
-</section>
-
-
-<section>
-<header>
-<h2 id="AboutBook"><span class="section-number">1.3.</span> Conventions utilisées dans ce guide</h2>
-</header>
-<p>
-Les éléments définis dans un langage informatique, tels que les classes ou méthodes en Java
-ainsi que les éléments dans un fichier <abbr>XML</abbr>, apparaissent avec une police de caractères mono-espacée.
-Afin de faciliter la compréhension des liens qui existent entre Apache <abbr title="Spatial Information System">SIS</abbr> et les standards,
-ces éléments sont en outre représentés en utilisant les codes de couleurs suivants:
-</p>
-<ul>
-<li>
-Les éléments en bleu sont définis dans un standard de l’<abbr title="Open Geospatial Consortium">OGC</abbr>
-ou de l’<abbr title="International Organization for Standardization">ISO</abbr>.
-Exemple: <code class="OGC">CD_Ellipsoid</code>.
-</li>
-<li>
-Les éléments en vert sont définis dans GeoAPI.
-Exemple: <code class="GeoAPI">Ellipsoid</code>.
-</li>
-<li>
-Les éléments en brun sont définis dans Apache <abbr title="Spatial Information System">SIS</abbr>.
-Exemple: <code class="SIS">DefaultEllipsoid</code>.
-</li>
-<li>
-Les éléments laissés en noir sont soient définis ailleurs (exemple: <code>String</code>),
-ou ne font pas l’objet d’une emphase particulière pour la discussion.
-</li>
-</ul>
-<p>
-Des compléments d’information apparaissent dans des boîtes grises.
-Le lecteur peut ignorer ces boîtes grises sans que cela ne nuise à la compréhension du texte.
-</p>
-
-
-
-<h3 id="ChosenTerms"><span class="section-number">1.3.1.</span> Choix des termes</h3>
-<p>
-Les standards privilégient parfois l’application de certains termes génériques à des contextes particuliers,
-qui peuvent différer du contexte dans lequel d’autres communautés emploient ces termes.
-Par exemple les termes <i>domain</i> et <i>range</i> peuvent s’appliquer à des fonctions arbitraires
-pour désigner l’ensemble des valeurs possibles en entrés et en sorties respectivement.
-Mais les fonctions auxquelles certains standards <abbr title="International Organization for Standardization">ISO</abbr>
-les appliquent ne sont pas les mêmes que les fonctions auxquelles d’autres bibliothèques les appliquent.
-Par exemple <abbr>ISO</abbr> 19123 applique ces termes aux objets <code class="OGC">CV_Coverage</code>,
-vus comme des fonctions dont le domaine est l’ensemble des coordonnées spatio-temporelles de la couverture de données
-et le <i>range</i> l’ensemble des valeurs de la couverture.
-Mais la bibliothèque <abbr title="Network Common Data Form">netCDF</abbr> de l’<abbr title="University Corporation for Atmospheric Research">UCAR</abbr>
-applique plutôt ces termes à la fonction convertissant les indices de pixels (son domaine) vers les coordonnées spatio-temporelles (son <i>range</i>).
-Ainsi, un <i>range</i> de la bibliothèque de l’<abbr>UCAR</abbr> peut être le domaine de <abbr>ISO</abbr> 19123.
-</p><p>
-La bibliothèque Apache <abbr title="Spatial Information System">SIS</abbr> privilégie autant que possible l’utilisation des termes dans le sens des normes <abbr title="Open Geospatial Consortium">OGC</abbr> et <abbr>ISO</abbr>.
-Mais un soin particulier doit être apporté aux interfaces entre <abbr>SIS</abbr> et certaines bibliothèques externes, afin de réduire les risques de confusions.
-</p>
-</section>
-</section>
-
-
-<section>
-<header>
-<h1 id="DataAccess"><span class="section-number">2.</span> Accès aux données géospatiales</h1>
-</header>
-<p>
-Bien qu’il soit possible de créer des structures de données programmatiquement en mémoire,
-le plus souvent les données sont lues à partir de fichiers ou autres types d’entrepôts.
-Il y a plusieurs moyens d’accéder à ces données, mais une façon pratique est d’utiliser
-la méthode de commodité <code class="SIS">DataStores.open(Object)</code>.
-L’argument donné à cette méthode peut être un chemin vers un fichier
-(<code>File</code>, <code>Path</code>, <code>URL</code>, <code>URI</code>),
-un flux d’entrée vers un fichier déjà ouvert
-(<code>Channel</code>, <code>DataInput</code>, <code>InputStream</code>, <code>Reader</code>),
-une connexion à une base de données (<code>DataSource</code>, <code>Connection</code>)
-ou d’autres types d’objets spécifiques à la source de données.
-La méthode <code class="SIS">DataStores.open(Object)</code> se charge de détecter le format de données
-et retourne une instance de <code class="SIS">DataStore</code> pouvant le lire.
-</p>
-<p>
-Les fonctionnalités d’un <code class="SIS">DataStore</code> dépendent de la nature des données à manipuler
-(couvertures de données, ensembles de géométries, séries temporelles, <i>etc.</i>),
-mais dans tous les cas il y aura toujours au moins quelques méta-données que l’on peut extraire.
-Les méta-données permettent d’identifier les phénomènes ou entités décrits par les données
-(température, occupation du sol, <i>etc.</i>),
-la région géographique ou la plage temporelle couverte par les données ainsi que leur résolution.
-Certains sources suffisamment riches fournissent aussi une estimation de la qualité des données,
-des informations permettant de contacter la personne ou l’organisme responsable des données,
-les contraintes légales ou techniques à l’utilisation, l’historique des traitements,
-les dates prévues des prochaines mises-à-jour, <i>etc.</i>
-</p>
-<p>
-Les différents formats de données ont souvent leurs propres modèles de méta-données,
-mais Apache <abbr title="Spatial Information System">SIS</abbr> les traduit tous vers un modèle unique afin de cacher cette hétérogénéité.
-Cette approche, consistant à choisir un seul modèle de méta-données comme <em>modèle pivot</em>, est fréquemment utilisée par d’autres bibliothèques aussi.
-Par exemple Apache Tika utilise le standard <cite>Dublin Core</cite> comme modèle pivot,
-alors que Java Image I/O définit son propre modèle standard dans le paquet <code>javax.imageio.metadata</code>.
-Pour Apache <abbr>SIS</abbr>, le modèle pivot choisi est le standard international de méta-données en information géographique
-<abbr title="International Organization for Standardization">ISO</abbr> 19115-1:2014 — <cite>principes de base</cite>, complété par
-<abbr>ISO</abbr> 19115-2 — <cite>extensions pour l’acquisition et le traitement</cite>.
-Ce modèle organise les méta-données dans une arborescence où chaque information est accessible via un chemin bien défini,
-peu importe l’origine de cette information.
-Par exemple si un format de données peut nous fournir les coordonnées géographiques d’une boîte englobant toutes les données,
-alors cette information sera toujours accessible (peu importe le format de données) à partir de l’objet <code class="GeoAPI">Metadata</code>
-sous le noeud <code class="OGC">identificationInfo</code>, sous-noeud <code class="OGC">extent</code>,
-sous-noeud <code class="OGC">geographicElement</code>.
-</p>
-<div class="example"><p><b>Exemple:</b>
-le code suivant lit un fichier de méta-données d’une image Landsat-8 et affiche les limites géographiques qui y sont déclarées:
-</p>
-
-<pre><code><b>try</b> (<code class="SIS">DataStore</code> ds = <code class="SIS">DataStores</code>.open(<b>new</b> File(<i>"LC81230522014071LGN00_MTL.txt"</i>))) {
- <code class="GeoAPI">Metadata</code> md = ds.<code class="SIS">getMetadata()</code>;
-
- <code class="comment">// Afin de simplifier cet exemple, nous omettons les vérifications de valeurs nulles ou de collections vides.</code>
- <code class="GeoAPI">Identification</code> idInfo = md .<code class="GeoAPI">getIdentificationInfo()</code>.iterator().next();
- <code class="GeoAPI">Extent</code> extent = idInfo.<code class="GeoAPI">getExtents()</code> .iterator().next();
- <code class="GeoAPI">GeographicExtent</code> bbox = extent.<code class="GeoAPI">getGeographicElements()</code>.iterator().next();
-
- System.out.println(<i>"La région géographique des données est:"</i>);
- System.out.println(bbox);
-}</code></pre>
-
-<p>
-Cet exemple produit la sortie suivante (la région est située au Vietnam):
-</p>
-
-<pre><samp>La région géographique des données est:
-Geographic Bounding Box
- ├─West bound longitude…………………………… 108°20′10,464″E
- ├─East bound longitude…………………………… 110°26′39,66″E
- ├─South bound latitude…………………………… 10°29′59,604″N
- └─North bound latitude…………………………… 12°37′25,716″N</samp></pre>
-
-<p>
-Le code Java dans cet exemple extrait des éléments de méta-données par des appels à des méthodes Java telles que <code class="GeoAPI">getExtents()</code>,
-mais les chapitres suivants introduiront d’autres façons utilisant des identifiants sous forme de chaînes de caractères.
-Ces approches alternatives sont plus pratiques lorsque l’on ne connaît pas au moment de la compilation quelles méthodes appeler.
-</p>
-</div>
-
-<p>
-La norme <abbr>ISO</abbr> 19115 définit des centaines d’éléments.
-Certains de ces éléments seront introduits progressivement dans les chapitres suivants.
-Mais afin de donner une petite idée de ce qui est disponible, le tableau suivant en liste quelques uns.
-La plupart des noeuds acceptent un nombre arbitraire de valeurs.
-Par exemple il peut y avoir plusieurs zones géographiques décrites sous le noeud <code class="OGC">extent</code>.
-</p>
-
-<table style="line-height:1">
-<caption>Quelques éléments de méta-données extraits de ISO 19115</caption>
-<tr><th>Élément</th> <th>Description</th></tr>
-<tr><td style="padding-top:9px">Metadata</td> <td style="padding-top:9px">Méta-données à propos d’un jeu de données, d’un service ou autres ressources.</td></tr>
-<tr><td> ├─Reference system info</td> <td>Description du système de référence spatial et temporel utilisé dans le jeu de données.</td></tr>
-<tr><td> ├─Identification info</td> <td>Information de base à propos de la ressource décrite par les méta-données.</td></tr>
-<tr><td> │ ├─Citation</td> <td>Nom selon lequel la ressource est connue, ainsi que des dates de références, la forme de présentation, <i>etc.</i></td></tr>
-<tr><td> │ │ └─Cited responsible party</td> <td>Rôle, nom, contact et position des individus ou organisations qui sont responsables de la ressource.</td></tr>
-<tr><td> │ ├─Topic category</td> <td>Principaux thèmes de la ressource (agriculture, climatologie, environnement, économie, santé, transport, <i>etc.</i>).</td></tr>
-<tr><td> │ ├─Descriptive keywords</td> <td>Mots-clés, leurs types, et référence vers la source les définissant.</td></tr>
-<tr><td> │ ├─Spatial resolution</td> <td>Facteur (échelle, taille de pixel) donnant une idée globale de la densité spatiale des données de la ressource.</td></tr>
-<tr><td> │ ├─Temporal resolution</td> <td>La plus petite période temporelle pouvant être résolue dans la ressource.</td></tr>
-<tr><td> │ ├─Extent</td> <td>Étendue spatiale et temporelle de la ressource.</td></tr>
-<tr><td> │ ├─Resource format</td> <td>Description du format de la ressource.</td></tr>
-<tr><td> │ ├─Resource maintenance</td> <td>Information sur la fréquence des mises-à-jours de la ressources, ainsi que la portée de ces mises-à-jours.</td></tr>
-<tr><td> │ └─Resource constraints</td> <td>Information sur les contraintes légales ou de sécurités qui s’appliquent à la ressource.</td></tr>
-<tr><td> ├─Content info</td> <td>Information sur le catalogue d’entités ainsi que les caractéristiques des couvertures de données ou images.</td></tr>
-<tr><td> │ ├─Imaging condition</td> <td>Conditions qui affectent les images (image floue, brouillard, semi-obscurité, <i>etc.</i>).</td></tr>
-<tr><td> │ ├─Cloud cover percentage</td> <td>Proportion des données masquées par les nuages, comme pourcentage de l’étendue spatiale.</td></tr>
-<tr><td> │ └─Attribute group</td> <td>Information sur les groupes d’attributs de la ressource.</td></tr>
-<tr><td> │ ├─Content type</td> <td>Types d’information représentée par les valeurs (classification thématique, mesures physiques, <i>etc.</i>).</td></tr>
-<tr><td> │ └─Attribute</td> <td>Information sur un attribut d’une ressource.</td></tr>
-<tr><td> │ ├─Sequence identifier</td> <td>Nom ou numéro unique qui identifie l’attribut dans une couverture de données.</td></tr>
-<tr><td> │ ├─Peak response</td> <td>Longueur d’onde à laquelle la réponse du capteur est maximale.</td></tr>
-<tr><td> │ ├─Min/max value</td> <td>Valeur minimale/maximale des données pour chaque dimension d’échantillonage inclue dans la ressource.</td></tr>
-<tr><td> │ ├─Units</td> <td>Unités de mesures pour chaque dimension d’échantillonage inclue dans la ressource.</td></tr>
-<tr><td> │ └─Transfer function type</td> <td>Type de fonction de transfert utilisée pour convertir un élément en valeur physique.</td></tr>
-<tr><td> ├─Distribution info</td> <td>Information sur les distributeurs et les façons d’obtenir la ressource.</td></tr>
-<tr><td> │ ├─Distribution format</td> <td>Description des formats dans lesquels les données peuvent être distribuées.</td></tr>
-<tr><td> │ └─Transfer options</td> <td>Moyens techniques et médias par lesquels une ressource peut être obtenue à partir de son distributeur.</td></tr>
-<tr><td> ├─Data quality info</td> <td>Évaluation globale de la qualité de la ressource.</td></tr>
-<tr><td> ├─Acquisition information</td> <td>Information sur l’acquisition des données.</td></tr>
-<tr><td> │ ├─Environmental conditions</td> <td>Conditions environnementales dans lesquels les données ont été acquises.</td></tr>
-<tr><td> │ └─Platform</td> <td>Information générale sur la plate-forme à partir de laquelle les données ont été acquises.</td></tr>
-<tr><td> │ └─Instrument</td> <td>Instruments montées sur la plate-forme.</td></tr>
-<tr><td> └─Resource lineage</td> <td>Information sur la provenance, les sources et/ou les étapes de production de la ressource.</td></tr>
-<tr><td> ├─Source</td> <td>Information sur les données sources utilisées pour créer les données décrites par les méta-données.</td></tr>
-<tr><td> └─Process step</td> <td>Historique des événements survenues dans la productions des données.</td></tr>
-</table>
-
-
-
-<section>
-<header>
-<h2 id="GetMetadataElement"><span class="section-number">2.1.</span> Parcourir les méta-données</h2>
-</header>
-<p>
-L’utilisation de méthodes telles que <code class="GeoAPI">getExtents()</code>
-est efficace lorsque l’on cherche un élément bien précis, connu au moment de la compilation.
-Mais le fait que l’élément recherché peut être assez loin dans l’arborescence et
-que beaucoup d’éléments soient optionnels ou membres de collections rend parfois le parcourt laborieux.
-Pour quelques éléments fréquemment demandés, des méthodes de commodité existent.
-Elles sont généralement définies sous forme de méthodes statiques dans une classe dont le nom est au pluriel.
-Par exemple la classe <code class="SIS">Extents</code> définie des méthodes statiques pour extraire plus facilement
-certaines informations à partir de l’élément de méta-donnée <code class="GeoAPI">Extent</code>.
-Ainsi la ligne suivante prendra en charge le travail un peu fastidieux de parcourir les différentes branches possible
-pouvant aboutir aux limites nord, sud, est et ouest de la donnée:
-</p>
-<pre><code><code class="GeoAPI">GeographicBoundingBox</code> bbox = <code class="SIS">Extents</code>.getGeographicBoundingBox(extent);</code></pre>
-<p>
-Ces méthodes de commodité sont définies sous forme de méthodes statiques
-afin de permettre leur utilisation avec différentes implémentations des éléments de méta-données.
-Même dans Apache <abbr title="Spatial Information System">SIS</abbr>, la classe <code class="SIS">DefaultExtent</code> n’est pas la seule implémentation de l’interface <code class="GeoAPI">Extent</code>.
-Il y a aussi d’autres implémentations qui puiseront leur information à la demande dans une base de données,
-ou des implémentations conçues spécifiquement pour des formats de données particuliers.
-D’autres exemples de classes fournissant des méthodes statiques dédiées à une interface sont
-<code class="SIS">Citations</code>, <code class="SIS">Envelopes</code>, <code class="SIS">Matrices</code> et <code class="SIS">MathTransforms</code>.
-</p><p>
-Ces méthodes statiques parcourent une plus grande portion de l’arbre de méta-données afin de trouver ou dériver l’élément demandé,
-mais ce dernier reste un élément dont le type et au moins une partie du chemin sont connus au moment de la compilation.
-Il arrive que l’on veuille plutôt accéder à des éléments qui ne sont connus qu’au moment de l’exécution, ou encore parcourir tous les éléments.
-Dans ces cas, on peut utiliser une vue sous forme de <code>java.util.Map</code> comme dans l’exemple suivant:
-</p>
-
-<pre><code>Map<String,Object> elements = <code class="SIS">MetadataStandard</code>.ISO_19115.<code class="SIS">asValueMap</code>(
- metadata, <code class="comment">// N’importe quelle instance du paquet org.opengis.metadata ou d’un sous-paquet.</code>
- <b>null</b>, <code class="comment">// Utilisé pour résoudre des ambiguïtés. Peut être ignoré pour cet exemple.</code>
- <code class="SIS">KeyNamePolicy</code>.<code class="SIS">JAVABEANS_PROPERTY</code>, <code class="comment">// Les clés seront les noms des méthodes mais sans le prefix « get ».</code>
- <code class="SIS">ValueExistencePolicy</code>.<code class="SIS">NON_EMPTY</code>); <code class="comment">// Les entrés dont la valeur est nulle ou vide seront omises.</code>
-<code class="comment">/*
- * Affiche les noms de tous les éléments à la racine de la méta-données qui ont une valeur.
- * Cette bouche ne va pas descendre dans les enfants (pas de récursivité).
- */</code>
-<b>for</b> (String name : elements.keySet()) {
- System.out.println(name);
-}</code></pre>
-
-<p>
-Le <code>Map</code> retourné par <code class="SIS">asValueMap(…)</code> est une vue « vivante »:
-tout changement dans l’instance <code>metadata</code> se reflétera immédiatement dans la vue.
-En fait, chaque appel à <code>map.get("foo")</code> se traduit par un appel à la méthode <code>metadata.getFoo()</code> correspondante.
-Réciproquement, toute opération <code>map.put("foo", …)</code> ou <code>map.remove("foo")</code> effectuée sur la vue
-sera traduite en appel à la méthode <code>metadata.setFoo(…)</code> correspondante si cette dernière existe.
-Cette vue est assez souple sur les clés données en argument aux méthodes de <code>Map</code>:
-elles peuvent être le nom de la propriété (<code>"foo"</code>), le nom de la méthode (<code>"getFoo"</code>),
-ou le nom utilisé dans les diagrammes <abbr title="Unified Modeling Language">UML</abbr> de la norme <abbr title="International Organization for Standardization">ISO</abbr> 19115
-(assez proche du nom de la propriété mais pas toujours identique).
-Les différences entre majuscules et minuscules sont ignorées si elles ne causent pas d’ambiguïtés.
-Pour plus d’information sur ce mécanisme de vues sur les méta-données, voir la Javadoc du paquet
-<a href="../../apidocs/org/apache/sis/metadata/package-summary.html#package.description"><code class="SIS">org.apache.sis.metadata</code></a>.
-</p><p>
-Parmi les éléments de méta-données présentés dans ce chapitre, il en est un qui fera l’objet
-d’un <a href="#Referencing">chapitre dédié</a>: <code class="OGC">referenceSystemInfo</code>.
-Son contenu est essentiel pour positionner précisément les données.
-Sans lui, même les positions exprimées sous forme de latitudes et longitudes sont ambigües.
-Les systèmes de références ont plusieurs caractéristiques qui les différencient des autres méta-données:
-ils sont immuables, ne peuvent pas être parcourus par <code class="SIS">MetadataStandard.ISO_19115.asValueMap(…)</code>,
-ont une représentation sous forme de texte particulière,
-et sont associés à un mécanisme permettant de transformer des coordonnées d’un référentiel vers un autre.
-</p>
-</section>
-</section>
-
-
-<section>
-<header>
-<h1 id="Coverage"><span class="section-number">3.</span> Couvertures de données (<i>Coverages</i>)</h1>
-</header>
-<p>
-Les images, souvent nommées <i>rasters</i> en anglais, sont des cas particuliers
-d’une structure de données appelée <i>coverages</i>.
-On pourrait traduire ce terme anglais par « couverture de données ».
-Le titre du standard les décrivant, « <i>Coverage geometry and functions</i> »
-(<abbr title="International Organization for Standardization">ISO</abbr> 19123), résume bien les deux éléments essentiels des couvertures de données:
-</p>
-<ul>
-<li>
-<p>
-Un <i>coverage</i> est une fonction qui, à partir d’une coordonnée spécifiée en entrée,
-retourne une valeur d’attribut. L’ensemble des valeurs pouvant être données en entrée est appelé le domaine
-(<i>domain</i> en anglais), alors que l’ensemble des valeurs pouvant être retournées est appelé <i>range</i> en anglais.
-Le domaine est souvent l’espace spatio-temporel couvert par les données,
-mais rien dans <abbr title="Spatial Information System">SIS</abbr> n’empêche les couvertures de s’étendre à d’autres dimensions.
-Par exemple les études en thermodynamique utilisent souvent un espace dont les dimensions sont la température et la pression.
-</p>
-<div class="example"><p><b>Exemple:</b>
-les valeurs des pixels d’une image pourraient contenir des mesures d’élévation du terrain.
-Si une fonction <var>h</var> = <var>f</var>(φ,λ) permet d’obtenir (éventuellement à l’aide d’interpolations)
-l’élévation <var>h</var> en fonction d’une coordonnée géographique (φ,λ), alors
-l’enveloppe géographique de l’image définie le <i>domain</i>, la fonction <var>f</var> est le <i>coverage</i>,
-et l’ensemble des valeurs de <var>h</var> que peut retourner cette fonction est le <i>range</i>.
-</p></div>
-</li>
-<li>
-<p>
-Les différents types de couvertures peuvent se caractériser par la géométrie de leurs cellules.
-En particulier, une couverture n’est pas nécessairement composée de cellules quadrilatérales.
-Toutefois les cellules quadrilatérales étant de loin les plus fréquentes (puisque c’est la géométrie classique des pixels des images),
-on utilisera souvent le terme <i>grid coverage</i> pour désigner les couvertures composées de telles cellules.
-Dans <abbr>SIS</abbr>, la géométrie de ces couvertures est décrite par la classe <code class="SIS">GridGeometry</code>.
-</p>
-</li>
-</ul>
-<p>
-Les caractéristiques du domaine spatial sont définies par le standard <abbr>ISO</abbr> 19123,
-alors que les caractéristiques du <i>range</i> ne font pas parties du standard.
-Le standard mentionne simplement que les <i>ranges</i> peuvent être finis ou infinis,
-et ne sont pas nécessairement numériques.
-Par exemple les valeurs retournées par une couverture peuvent provenir d’une énumération
-(« ceci est une forêt », « ceci est un lac », <i>etc.</i>).
-Toutefois, le standard définit deux grands types de couvertures qui ont un impact
-sur les types de <i>ranges</i> autorisés:
-les couvertures <i>discrètes</i> et les couvertures <i>continues</i>.
-Présentées simplement, les couvertures continues sont des fonctions pouvant utiliser des méthodes d’interpolations.
-Or, les interpolations n’étant possibles qu’avec des valeurs numériques, les <i>ranges</i> de valeurs
-non-numériques ne peuvent être utilisés qu’avec des couvertures de type <code class="OGC">CV_DiscreteCoverage</code>.
-En revanche, les <i>ranges</i> de valeurs numériques peuvent
-être utilisés aussi avec des couvertures de type <code class="OGC">CV_ContinuousCoverage</code>.
-</p>
-<aside>
-<h2>La classe <code class="SIS">Range</code> de SIS et sa relation avec les standards</h2>
-<p>
-La distinction entre les plages de tout type de valeurs et les plages de valeurs numériques est représentée dans <abbr title="Spatial Information System">SIS</abbr>
-par les classes <code class="SIS">Range</code> et <code class="SIS">NumberRange</code> respectivement.
-La classe <code class="SIS">NumberRange</code> est la plus utilisée, et elle est aussi celle qui se rapproche le plus de la
-<a href="http://fr.wikipedia.org/wiki/Intervalle_%28math%C3%A9matiques%29">notion mathématique usuelle d’un intervalle</a>.
-Se représentation textuelle se rapproche des spécifications du standard <abbr title="International Organization for Standardization">ISO</abbr> 31-11,
-excepté que la virgule est remplacée par le caractère “…” comme séparateur des valeurs minimales et maximales.
-Par exemple “[0 … 256)” représente la plage des valeurs 0 inclusivement à 256 exclusivement.
-</p>
-<p>
-Les objets <code class="SIS">Range</code> ne sont associés aux <i>coverages</i> que indirectement.
-Dans <abbr>SIS</abbr>, les valeurs que peuvent retourner les couvertures sont décrites par des
-objets de type <code class="SIS">SampleDimension</code>. Ce sont ces derniers qui contiendront
-des instances de <code class="SIS">Range</code> ainsi que d’autres informations telles qu’une
-<i>fonction de transfert</i> (décrite plus loin).
-</p>
-</aside>
-<div class="warning">
-Cette section est incomplète. Voyez la version anglaise pour une version éventuellement plus complète.
-</div>
-</section>
-
-
-<section>
-<header>
-<h1 id="Geometry"><span class="section-number">4.</span> Géométries</h1>
-</header>
-<p>
-Ce chapitre introduit quelques aspects de la norme <abbr title="International Organization for Standardization">ISO</abbr> 19107 (<i>Spatial schema</i>)
-et les classes de Apache <abbr title="Spatial Information System">SIS</abbr> qui les implémentent.
-</p>
-
-
-
-
-<section>
-<header>
-<h2 id="GeometryBase"><span class="section-number">4.1.</span> Classes de base</h2>
-</header>
-<p>
-Chaque objet géométrique est considéré comme un ensemble infini de points.
-En tant qu’ensemble, leurs opérations les plus fondamentales sont de même nature que les opérations standards des collections du Java.
-On pourrait donc voir une géométrie comme une sorte de <code>java.util.Set</code> dont les éléments seraient des points,
-à ceci près que le nombre d’éléments contenus dans cet ensemble est infini (à l’exception des géométries représentant un simple point).
-Pour mieux représenter ce concept, la norme <abbr title="International Organization for Standardization">ISO</abbr> et GeoAPI définissent une interface <code class="OGC">TransfiniteSet</code>
-que l’on peut voir comme un <code>Set</code> de taille infini. Bien qu’un lien de parenté existe conceptuellement entre ces interfaces,
-GeoAPI ne définit pas <code class="GeoAPI">TransfiniteSet</code> comme une sous-interface de <code>java.util.Set</code>
-car la définition de certaines méthodes telles que <code>size()</code> et <code>iterator()</code> serait problématique.
-On y retrouve toutefois des méthodes très similaires telles que <code class="GeoAPI">contains(…)</code> et <code class="GeoAPI">intersects(…)</code>.
-</p>
-<p>
-Toutes les géométries sont des spécialisations de <code class="GeoAPI">TransfiniteSet</code>.
-La classe parente de toutes ces géométries est appelée <code class="OGC">GM_Object</code> dans la norme <abbr>ISO</abbr> 19107.
-Les interfaces de GeoAPI utilisent plutôt le nom <code class="GeoAPI">Geometry</code>, car l’omission du préfixe <code class="OGC">GM_</code>
-(comme le veut la convention dans GeoAPI) aurait laissé un nom trop proche de la classe <code>Object</code> du Java.
-</p>
-
-
-
-<h3 id="DirectPosition"><span class="section-number">4.1.1.</span> Points et positions directes</h3>
-<p>
-<abbr title="International Organization for Standardization">ISO</abbr> 19107 définit deux types de structures pour représenter un point:
-<code class="OGC">GM_Point</code> et <code class="OGC">DirectPosition</code>.
-Le premier type est une véritable géométrie et peut donc être relativement lourd, selon les implémentations.
-Le second type n’est pas considéré formellement comme une géométrie;
-il n’étend ni <code class="OGC">GM_Object</code> ni <code class="OGC">TransfiniteSet</code>.
-Il ne définit pratiquement pas d’opérations autres que le stockage d’une séquence de nombres représentant une coordonnée.
-Il peut donc être un objet plus léger.
-</p>
-<p>
-Afin de permettre à l’<abbr title="Application Programming Interface">API</abbr> de travailler indifféremment avec ces deux types de positions,
-<abbr>ISO</abbr> 19107 définit <code class="OGC">Position</code> comme une <cite>union</cite> de
-<code class="OGC">DirectPosition</code> et <code class="OGC">GM_Point</code>.
-Il s’agit d’une union au sens du C/C++. Pour le langage Java, GeoAPI obtient le même effet en définissant
-<code class="GeoAPI">Position</code> comme l’interface parente de <code class="GeoAPI">DirectPosition</code> et <code class="GeoAPI">Point</code>.
-Dans la pratique, la grande majorité des <abbr>API</abbr> de Apache <abbr title="Spatial Information System">SIS</abbr> travaillent sur des <code class="GeoAPI">DirectPosition</code>,
-ou occasionnellement des <code class="GeoAPI">Position</code> quand il semble utile d’autoriser aussi des points géométriques.
-</p>
-
-
-
-<h3 id="Envelope"><span class="section-number">4.1.2.</span> Enveloppes</h3>
-<p>
-Les enveloppes stockent les valeurs minimales et maximales des coordonnées d’une géométrie.
-Les enveloppes <em>ne sont pas</em> elles-mêmes des géométries; ce ne sont pas des ensembles
-infinis de points (<code class="OGC">TransfiniteSet</code>). Il n’y a aucune garantie
-que toutes les positions contenues dans les limites d’une enveloppe soient géographiquement valides.
-Il faut voir les enveloppes comme une information sur les valeurs extrêmes que peuvent prendre les
-coordonnées d’une géométrie en faisant comme si chaque dimension était indépendante des autres,
-rien de plus. Nous assimilons néanmoins les enveloppes à des rectangles, cubes ou hyper-cubes
-(selon le nombre de dimensions) afin de faciliter la discussion, mais en gardant à l’esprit leur
-nature non-géométrique.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Nous pouvons tester si une position est à l’intérieur des limites de l’enveloppe.
-Un résultat positif ne garantie pas que la position est à l’intérieur de la géométrie délimitée par l’enveloppe,
-mais un résultat négatif garantie qu’elle est à l’extérieur. De même on peut effectuer des tests d’intersections.
-En revanche appliquer une rotation n’a pas beaucoup de sens pour une enveloppe, car le résultat peut être très différent
-de celui que nous aurions obtenu en effectuant une rotation de la géométrie originale, puis en recalculant son enveloppe.
-</p></div>
-<p>
-Une enveloppe peut être représentée par deux positions correspondant à deux coins opposés
-d’un rectangle, cube ou hyper-cube. On prend souvent comme premier coin celui dont toutes
-les ordonnées ont la valeur minimale (<code class="OGC">lowerCorner</code>), et comme second
-coin celui dont toutes les ordonnées ont la valeur maximale (<code class="OGC">upperCorner</code>).
-Lors d’un affichage utilisant un système de coordonnées classique (valeurs de l’axe des <var>y</var> augmentant vers le haut),
-ces deux positions apparaissent respectivement dans le coin inférieur gauche et dans le coin supérieur droit d’un rectangle.
-Attention toutefois aux différents systèmes de coordonnées, qui peuvent faire varier les positions de ces coins à l’écran.
-Les expressions <i>lower corner</i> et <i>upper corner</i>
-doivent être comprises au sens mathématique plutôt que visuel.
-</p>
-
-
-
-<h4 id="AntiMeridian"><span class="section-number">4.1.2.1.</span> Enveloppes traversant l’antiméridien</h4>
-<p>
-Les minimums et maximums sont les valeurs les plus souvent assignées aux <code class="OGC">lowerCorner</code>
-et <code class="OGC">upperCorner</code>. Mais les choses se compliquent dans le cas d’une enveloppe traversant
-l’antiméridien (-180° ou 180° de longitude). Par exemple, une enveloppe de 10° de largeur peut commencer à 175° de longitude et
-se terminer à -175°. Dans ce cas, la valeur de longitude assignée au <code class="OGC">lowerCorner</code> est
-supérieure à celle qui est assignée à l’<code class="OGC">upperCorner</code>.
-Apache <abbr title="Spatial Information System">SIS</abbr> emploie donc une définition légèrement différente de ces deux coins:
-</p>
-<ul>
-<li><b><code class="SIS">lowerCorner</code>:</b>
-le point de départ lorsque l’on parcourt l’intérieur de l’enveloppe dans la direction des valeurs croissantes.
-</li>
-<li><b><code class="SIS">upperCorner</code>:</b>
-le point d’arrivé lorsque l’on a parcouru l’intérieur de l’enveloppe dans la direction des valeurs croissantes.
-</li>
-</ul>
-<p>
-Lorsque l’enveloppe ne traverse par l’antiméridien, ces deux définitions sont équivalentes à la sélection
-des valeurs minimales et maximales respectivement. C’est le cas du rectangle vert dans la figure ci-dessous.
-Lorsque l’enveloppe traverse l’antiméridien, les coins <code class="SIS">lowerCorner</code>
-et <code class="SIS">upperCorner</code> apparaissent encore en bas et en haut du rectangle
-(en supposant un système de coordonnées classique), donc leurs noms restent appropriés d’un point de vue visuel.
-Mais les positions gauche et droite sont interchangées.
-Ce cas est représenté par le rectangle rouge dans la figure ci-dessous.
-</p>
-<p style="text-align:center">
-<img alt="Exemples d’enveloppes avec et sans croisement de l’antiméridien." src="../../apidocs/org/apache/sis/geometry/doc-files/AntiMeridian.png"/>
-</p>
-<p>
-Les notions d’inclusion et d’intersection s’interprètent toutefois de manière légèrement différente dans ces deux cas.
-Dans le cas habituel où l’on ne traverse pas l’antiméridien, le rectangle vert délimite bien une région d’inclusion.
-Les régions exclues de ce rectangle se propagent à l’infini dans toutes les directions.
-En d’autres mots, la région d’inclusion n’est pas répétée tous les 360°.
-Mais dans le cas du rectangle rouge, l’information fournie par l’enveloppe délimite plutôt la région d’exclusion qui
-se trouve entre les deux bords du rectangle. La région d’inclusion se propage à l’infini des côtés gauche et droit.
-Nous pourrions stipuler que toute longitude inférieure à -180° ou supérieure à 180° est considérée exclue,
-mais ça serait une décision arbitraire qui ne serait pas un reflet symétrique du cas habituel (rectangle vert).
-Un développeur pourrait vouloir utiliser ces valeurs, par exemple dans une mosaïque où la carte du monde
-est répétée plusieurs fois horizontalement tout en considérant chaque répétition comme distincte des autres.
-Si un développeur souhaite effectuer des opérations comme si les régions d’inclusions ou d’exclusions étaient
-répétées tous les 360°, alors il doit lui-même ramener ses valeurs de longitudes entre -180° et 180° au préalable.
-Toutes les fonctions <code class="SIS">add(…)</code>, <code class="SIS">contains(…)</code>,
-<code class="SIS">intersect(…)</code>, <i>etc.</i> de toutes les enveloppes
-définies dans le paquet <code class="SIS">org.apache.sis.geometry</code> effectuent leurs calculs selon cette convention.
-</p>
-<aside>
-<h5>Généralisation à d’autres types d’axes</h5>
-<p>
-Cette section nomme spécifiquement la longitude car il constitue le cas le plus courant d’axe cyclique.
-Mais dans les enveloppes de Apache <abbr title="Spatial Information System">SIS</abbr>, il n’est fait nul part mention explicite du cas de la longitude, ni de son cycle de 360°.
-Les caractéristiques de la plage de valeurs de chaque axe (ses extremums, unités, type de cycle, <i>etc.</i>)
-sont des attributs des objets <code class="GeoAPI">CoordinateSystemAxis</code>, indirectement associés aux enveloppes via le système de référence des coordonnées.
-Apache <abbr>SIS</abbr> inspecte ces attributs pour déterminer de quelle façon il doit effectuer ses opérations.
-Ainsi, tout axe associé au code <code class="GeoAPI">RangeMeaning.WRAPAROUND</code> bénéficiera du même traitement que la longitude.
-Cela pourrait être par exemple un axe du temps dans des données climatologiques
-(une “année” représentant la température moyenne de tous les mois de janvier, suivit de la moyenne de tous les mois de février,
-<i>etc.</i>).
-Cette généralisation s’applique aussi aux axes de longitudes définis par une plage de 0° à 360° plutôt que de -180° à 180°.
-</p>
-</aside>
-<p>
-Pour que les fonctions telles que <code class="SIS">add(…)</code> fonctionnent correctement,
-tous les objets impliqués doivent utiliser le même système de référence des coordonnées, y compris
-la même plage de valeurs. Ainsi, une enveloppe exprimant les longitudes dans la plage [-180 … +180]°
-n’est pas compatible avec une enveloppe exprimant les longitudes dans la plage [0 … 360]°.
-Les conversions, si nécessaires, sont à la charge de l’utilisateur
-(la classe <code class="SIS">Envelopes</code> fournit des méthodes de commodités pour ce faire).
-En outre, les coordonnées de l’enveloppe doivent être comprises dans les limites du système de coordonnées,
-sauf si le développeur souhaite volontairement considérer (par exemple) 300° de longitude
-comme un position distincte de -60°. La classe <code class="SIS">GeneralEnvelope</code>
-fournit une méthode <code class="SIS">normalize()</code> pour ramener les coordonnées
-dans les limites attendues, au prix parfois de valeurs <cite><i>lower</i></cite>
-supérieures à la valeur <cite><i>upper</i></cite>.
-</p>
-<aside>
-<h5>Le cas particulier de la plage [+0 … -0]</h5>
-<p>
-le Java (ou de manière plus générale, la norme IEEE 754) définit deux valeurs distinctes de zéro:
-un zéro positif et un zéro négatif. Ces deux valeurs sont considérées égales lorsqu’on les compares avec l’opérateur <code>==</code> du Java.
-Mais dans les enveloppes de <abbr title="Spatial Information System">SIS</abbr>, ils peuvent mener à des résultats opposés pour les axes ayant <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
-Une enveloppe dont la plage est [0 … 0], [-0 … -0] ou [-0 … +0] sera bien considérée comme une enveloppe vide,
-mais la page [+0 … -0] sera au contraire considérée comme incluant la totalité des valeurs, jusqu’à l’infini.
-Ce comportement est conforme à la définition de <code class="SIS">lowerCorner</code> et <code class="SIS">upperCorner</code>
-qui considère +0 comme le point de départ, et -0 comme le point d’arrivé après avoir fait le tour des valeurs possibles.
-Un tel comportement ne se produit que pour la paire de valeurs +0 et -0, et seulement dans cet ordre.
-Pour toutes les autres valeurs réelles, si la condition <code>lower</code> <code>==</code> <code>upper</code>
-est vrai, alors il est garanti que l’enveloppe est vide.
-</p>
-</aside>
-</section>
-</section>
-
-
-<section>
-<header>
-<h1 id="Referencing"><span class="section-number">5.</span> 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
-— 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é telles que les latitudes et longitudes
-— on parle alors de références spatiales par <cite>coordonnées</cite>.
-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 dit 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 title="Spatial Information System">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>
-<li>Rester dans la zone de validité du système telle que donnée par <code class="GeoAPI">ReferenceSystem.getDomainOfValidity()</code>.</li>
-<li>Savoir que les mesures de distances dans une projection cartographique donnée ne sont vraies qu’à certains endroits,
-appelés par exemple « parallèles standards ».</li>
-<li>Vérifier la précision des transformations de coordonnées, par exemple avec
-<code class="GeoAPI">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 class="OGC">TOWGS84</code>) n’est souvent pas suffisant.</li>
-</ul>
-<article>
-<header>
-<h2>Bibliothèques de type « early binding » versus « late binding »</h2>
-</header>
-<p>
-Le caractère universel du système <abbr title="World Geodetic System 1984">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 class="GeoAPI">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 class="OGC">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 class="GeoAPI">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 class="OGC">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 class="OGC">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 title="Spatial Information System">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 class="SIS">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 class="SIS">sis-referencing</code> de Apache <abbr>SIS</abbr> fournit un ensemble de classes implémentant
-les différentes spécialisations de l’interface <code class="GeoAPI">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.
-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 class="GeoAPI">CoordinateOperation</code>.
-Ces classes seront discutées dans <a href="#CoordinateOperations">une autre section</a>.
-</p>
-
-
-
-
-
-<section>
-<header>
-<h2 id="ComponentsOfCRS"><span class="section-number">5.1.</span> Composantes d’un système de références par coordonnées</h2>
-</header>
-<p>
-Les systèmes de références spatiales par coordonnées fournissent les informations nécessaires pour faire
-correspondre des coordonnées numériques à des positions dans le monde réel. Dans Apache <abbr title="Spatial Information System">SIS</abbr>,
-ils sont pratiquement tous représentés par des classes dont le nom se termine en <abbr>CRS</abbr>
-(l’abréviation de <i>Coordinate Reference System</i> en anglais). Ces objets contiennent:
-</p>
-<ul>
-<li>Un référentiel (<i>datum</i> en anglais),
-qui indique entre autres quel ellipsoïde utiliser comme approximation de la forme de la terre.</li>
-<li>Une description de chaque axe (nom, direction, unité de mesure, limites).</li>
-<li>Parfois une liste de paramètres permettant de convertir les coordonnées d’un autre système.
-C’est le cas notamment lorsqu’on utilise des projections cartographiques.</li>
-</ul>
-<p>
-Ces systèmes sont décrits par la norme <abbr title="International Organization for Standardization">ISO</abbr> 19111 (<i>Referencing by Coordinates</i>),
-qui remplace en grande partie une norme plus ancienne mais encore utilisée pour certains aspects,
-<abbr>OGC 01-009</abbr> (<i>Coordinate Transformation Services</i>).
-Ces normes sont complétées par deux autres standards définissant des formats d’échanges:
-<abbr>ISO</abbr> 19136 et 19162 pour respectivement
-le <cite>Geographic Markup Language</cite> (<abbr>GML</abbr>) — un format <abbr>XML</abbr> précis mais verbeux —
-et le <cite>Well-Known Text</cite> (<abbr>WKT</abbr>) — un format texte plus facile à lire par les humains.
-</p>
-
-<h3 id="Ellipsoid"><span class="section-number">5.1.1.</span> Géoïde et ellipsoïde</h3>
-<p>
-La surface topographique réelle étant difficile à représenter mathématiquement, elle n’est pas utilisée directement en cartographie.
-Une autre surface un peu plus facilement utilisable est le géoïde,
-une surface sur laquelle la force gravitationnelle a partout la même valeur (surface équipotentielle du champ de gravité terrestre).
-Cette surface est en tout point perpendiculaire à la direction indiquée par un fil à plomb (verticale du lieu).
-Le géoïde coïnciderait avec le niveau moyen des mers s’il n’y avait ni vent ni courants marins permanents comme le Gulf Stream.
-</p><p>
-Tout en étant nettement plus lisse que la surface topographique,
-le géoïde présente des creux et des bosses liés à l’inégale distribution des masses de la Terre.
-Pour une utilisation mathématiquement plus aisée, le géoïde est donc approximé par un ellipsoïde.
-Cette « figure de la Terre » est représentée dans GeoAPI par l’interface <code class="GeoAPI">Ellipsoid</code>,
-qui constitue un élément fondamental des systèmes de références de type <code class="GeoAPI">GeographicCRS</code> et <code class="GeoAPI">ProjectedCRS</code>.
-Plusieurs dizaines d’ellipsoïdes sont couramment employés pour la définition de référentiels.
-Certains offrent une excellente approximation pour une région précise
-au détriment des régions pour lesquelles le référentiel n’a pas été conçu,
-et d’autres offrant un compromis pour l’ensemble de la planète.
-</p>
-<div class="example"><p><b>Exemple:</b>
-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>
-<p>
-Les principales propriétés que l’on peut obtenir d’un ellipsoïde sont montrées ci-dessous.
-La longueur de l’axe semi-majeur est parfois appelée <cite>rayon équatorial</cite>
-et la longueur de l’axe semi-mineur <cite>rayon polaire</cite>.
-Le facteur d’aplatissement inverse (<cite>inverse flattening factor</cite> en anglais)
-peut sembler superflu puisqu’il se calcule à partir des autres propriétés,
-mais plusieurs définitions d’ellipsoïdes fournissent ce facteur plutôt que la longueur de l’axe semi-mineur.
-</p>
-
-<pre><code>Unit<Length> units = ellipsoid.<code class="GeoAPI">getAxisUnit()</code>;
-<b>double</b> semiMajor = ellipsoid.<code class="GeoAPI">getSemiMajorAxis()</code>; <code class="comment">// Avec les unités de mesures ci-haut.</code>
-<b>double</b> semiMinor = ellipsoid.<code class="GeoAPI">getSemiMinorAxis()</code>; <code class="comment">// Avec les unités de mesures ci-haut.</code>
-<b>double</b> ivf = ellipsoid.<code class="GeoAPI">getInverseFlattening()</code>; <code class="comment">// = semiMajor / (semiMajor - semiMinor).</code>
-</code></pre>
-
-
-<h3 id="GeodeticDatum"><span class="section-number">5.1.2.</span> Référentiel géodésique</h3>
-<p>
-Pour définir un système géodésique dans un pays, l’état met en place un ellipsoïde de référence
-qui épouse au mieux sur l’ensemble du pays la forme locale du géoïde.
-L’écart entre cet ellipsoïde de référence et les creux et les bosses du géoïde reste généralement inférieur à 100 mètres.
-Les paramètres qui permettent de lier un <code class="GeoAPI">Ellipsoid</code> à la surface de la Terre (par exemple la position de son centre)
-sont représentées par un objet de type <code class="GeoAPI">GeodeticDatum</code>, que l’on traduit en français par « référentiel géodésique ».
-Plusieurs <code class="GeoAPI">GeodeticDatum</code> peuvent utiliser le même <code class="GeoAPI">Ellipsoid</code>, mais centré ou orienté différemment.
-</p><p>
-Avant l’avènement des satellites, les mesures géodésiques se déroulaient exclusivement à la surface de la terre.
-En conséquence, deux îles ou continents qui ne sont pas à portée visuelle l’un de l’autre n’étaient pas rattachés géodésiquement entre eux.
-Ainsi les référentiels <cite>North American Datum 1983</cite> (<abbr>NAD83</abbr>) et
-<cite>European Datum 1950</cite> (<abbr>ED50</abbr>) sont indépendants l’un de l’autre:
-leurs ellipsoïdes de référence ont des centres distincts et des dimensions différentes.
-Une même coordonnée géographique correspondra à des positions différentes dans le monde réel
-selon que la coordonnée se réfère à l’un ou l’autre de ces référentiels.
-</p><p>
-L’invention du <abbr title="Global Positioning System">GPS</abbr> a précipité la création d’un système géodésique mondial,
-nommé <abbr title="World Geodetic System 1984">WGS84</abbr>.
-L’ellipsoïde de référence est alors unique et centré au centre de gravité de la terre.
-Les <abbr>GPS</abbr> donnent à tout moment la position absolue du récepteur rapportée à ce système géodésique.
-Mais <abbr>WGS84</abbr> étant un système mondial, il peut diverger significativement des systèmes locaux.
-Par exemple l’écart entre <abbr>WGS84</abbr> et le système européen <abbr>ED50</abbr> est de l’ordre de 150 mètres,
-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 class="GeoAPI">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 class="GeoAPI">Transformation</code> pour les données récentes, mais ne l’élimine pas complètement.
-La Terre bouge sous l’effet de la tectonique des plaques et de nouveaux systèmes sont définis chaque année pour en tenir compte.
-Par exemple bien que le référentiel <abbr>NAD83</abbr> a été défini à l’origine comme pratiquement équivalent à <abbr>WGS84</abbr>,
-il existe maintenant (en 2016) un écart d’environ 1.5 mètres entre ces deux systèmes.
-Le référentiel <cite>Japanese Geodetic Datum 2000</cite> était aussi défini comme pratiquement équivalent à <abbr>WGS84</abbr>,
-mais le nouveau référentiel <cite>Japanese Geodetic Datum 2011</cite> s’en écarte.
-Le référentiel <abbr>WGS84</abbr> lui-même, sensé correspondre à une définition à un instant donné,
-a subit des révisions dues notamment à l’amélioration de la précision des instruments.
-Ainsi il existe aujourd’hui au moins six versions de <abbr>WGS84</abbr>.
-En outre beaucoups de bordures ont été définies légalement dans des référentiels plus anciens, par exemple <abbr>NAD27</abbr> aux États-Unis.
-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><p>
-Contrairement aux autres types d’objets introduits dans cette section,
-il n’y a pas beaucoup d’information utile que l’on peut extraire d’une instance de <code class="GeoAPI">Datum</code> à part son nom.
-Traduire en langage de programmation comment un référentiel est lié à la Terre est difficile.
-On se contente en général de considérer que si deux référentiels ont des noms différents,
-alors la même position sur la Terre aura des coordonnées différentes selon ces deux référentiels (même si l’ellipsoïde est identique)
-et la transformation des coordonnées d’un référentiel à l’autre nécessitera l’utilisation d’une base de données.
-</p>
-
-<h3 id="CoordinateSystem"><span class="section-number">5.1.3.</span> Systèmes de coordonnées</h3>
-<p>
-Un système de coordonnées (<abbr title="Coordinate System">CS</abbr>) définit l’ensemble des axes couvrant un espace de coordonnées.
-Chaque axe définit sa direction approximative (nord, sud, est, ouest, haut, bas, bâbord, tribord, passé, futur, <i>etc.</i>),
-ses unités de mesures, les valeurs minimales et maximales permises et ce qui se passe lorsqu’on atteint ces extremums.
-Par exemple dans le cas de la longitude, après +180° on revient à −180°.
-Mais de telles boucles peuvent aussi exister dans l’axe du temps.
-Par exemple dans des données climatologiques de la température normale,
-après le mois de décembre on revient au mois de janvier. Ces mois ne sont associés à aucune année en particulier.
-Les axes ayant ce genre de comportement sont reconnaissables à la propriété <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
-</p><p>
-Les principales propriétés que l’on peut obtenir d’un système de coordonnées sont montrées ci-dessous.
-Les axes sont numérotés de 0 à <code>cs.getDimension()-1</code> inclusivement:
-</p>
-
-<pre><code><code class="GeoAPI">CoordinateSystem</code> cs = crs.getCoordinateSystem();
-<code class="GeoAPI">CoordinateSystemAxis</code> secondAxe = cs.getAxis(1); <code class="comment">// Pour un système géographique, c’est habituellement la longitude géodétique.</code>
-String abréviation = secondAxe.getAbbreviation(); <code class="comment">// Pour l’axe des longitudes, c’est habituellement "λ", "L" ou "lon".</code>
-<code class="GeoAPI">AxisDirection</code> direction = secondAxe.getDirection(); <code class="comment">// Pour l’axe des longitudes, c’est habituellement EAST ou parfois WEST.</code>
-Unit<?> unités = secondAxe.getUnit(); <code class="comment">// Pour l’axe des longitudes, c’est habituellement Units.DEGREE.</code>
-<b>double</b> minimum = secondAxe.getMinimumValue(); <code class="comment">// Pour l’axe des longitudes, c’est habituellement −180° ou parfois 0°.</code>
-<b>double</b> maximum = secondAxe.getMaximumValue(); <code class="comment">// Pour l’axe des longitudes, c’est habituellement +180° ou parfois 360°.</code>
-<code class="GeoAPI">RangeMeaning</code> auxBouts = secondAxe.getRangeMeaning(); <code class="comment">// Pour l’axe des longitudes, c’est WRAPAROUND.</code>
-</code></pre>
-<p>
-En plus de la définition des axes, une autre caractéristique importante des systèmes de coordonnées est leur type
-(<code class="GeoAPI">CartesianCS</code>, <code class="GeoAPI">SphericalCS</code>, <i>etc.</i>). Ce type implique un ensemble de règles mathématiques
-pour calculer des quantités géométriques telles que les angles, distances et surfaces.
-Les divers sous-types de <abbr>CS</abbr> ne définissent habituellement pas de nouvelle méthodes Java comparativement au type parent,
-mais sont néanmoins importants.
-Par exemple plusieurs calculs ou associations ne sont valides qu’avec des axes perpendiculaires entre eux.
-Dans ce cas, le système de coordonnées sera restreint au type <code class="GeoAPI">CartesianCS</code> dans la signature des méthodes.
-</p><p>
-Les systèmes de coordonnées sont des concepts mathématiques;
-ils ne contiennent aucune information indiquant où sur la Terre se trouve leur origine.
-En conséquence, les systèmes de coordonnées seuls ne permettent pas de décrire une position terrestre;
-ils doivent être combinés avec un <cite>référentiel</cite>.
-Ces combinaisons forment les <cite>systèmes de références des coordonnées</cite> décrits dans les sections suivantes.
-</p>
-
-<h4 id="AxisOrder"><span class="section-number">5.1.3.1.</span> Ordre des axes</h4>
-<p>
-L’ordre des axes est spécifié par l’autorité (typiquement une agence nationale) qui définit le
-<cite>système de référence des coordonnées</cite> (<abbr>CRS</abbr>).
-L’ordre dépend du type de <abbr>CRS</abbr> ainsi que du pays qui l’a définit.
-Dans le cas des <abbr>CRS</abbr> de type géographique,
-l’ordre (<var>latitude</var>, <var>longitude</var>) est utilisé par les géographes et les pilotes depuis des siècles.
-Toutefois des développeurs de logiciels tendent à préférer l’ordre (<var>x</var>, <var>y</var>) pour tous systèmes de coordonnées.
-Ces différentes pratiques entraînent des définitions contradictoires de l’ordre des axes pour pratiquement tous les <abbr>CRS</abbr>
-de type <code class="GeoAPI">GeographicCRS</code>, pour certains <code class="GeoAPI">ProjectedCRS</code> dans l’hémisphère sud (Afrique du Sud, Australie, <i>etc.</i>)
-et pour certaines projections polaires entre autres.
-</p><p>
-Les standards <abbr title="Open Geospatial Consortium">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 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 title="Spatial Information System">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>.
-Ces <abbr>CRS</abbr> sont construits par des appels à la méthode <code>CRS.forCode(String)</code>,
-et l’ordre des axes effectif peut être vérifié après la création du <abbr>CRS</abbr> par un appel à <code>System.out.println(crs)</code>.
-Mais si l’ordre (<var>x</var>, <var>y</var>) est désiré pour des raisons de compatibilité avec d’anciens standards <abbr>OGC</abbr> ou avec d’autres logiciels,
-alors les <abbr>CRS</abbr> peuvent être modifiés de manière à avoir la longitude en premier avec un appel à la méthode suivante:
-</p>
-
-<pre><code><code class="GeoAPI">CoordinateReferenceSystem</code> crs = …; <code class="comment">// CRS obtenu de n’importe quelle façon.</code>
-crs = <code class="SIS">AbstractCRS</code>.<code class="SIS">castOrCopy</code>(crs).<code class="SIS">forConvention</code>(<code class="SIS">AxesConvention</code>.<code class="SIS">RIGHT_HANDED</code>)</code></pre>
-
-<p>
-Parmi les anciens standards de l’<abbr>OGC</abbr> qui utilisaient un ordre des axes non-conforme,
-un standard influent était la version 1 du format <cite>Well Known Text</cite> (<abbr>WKT</abbr>).
-D’après ce format largement utilisé, les définitions <abbr>WKT</abbr> 1 sans éléments <code class="OGC">AXIS[…]</code> explicites
-doivent être interprétés comme ayant ses axes dans l’ordre (<var>longitude</var>, <var>latitude</var>) ou (<var>x</var>, <var>y</var>).
-Dans la version 2 du format <abbr>WKT</abbr>, les éléments <code class="OGC">AXIS[…]</code> ne sont plus optionnel
-et devrait contenir explicitement un sous-élément <code class="OGC">ORDER[…]</code> pour rendre l’ordre voulu encore plus évident.
-Mais si les éléments <code class="OGC">AXIS[…]</code> sont malgré tout omis dans une définition <abbr>WKT</abbr> 2,
-alors Apache <abbr>SIS</abbr> utilise l’ordre (<var>latitude</var>, <var>longitude</var>) par défaut.
-Pour résumer:
-</p>
-<ul>
-<li>L’ordre par défaut d’un <abbr>CRS</abbr> géographique en <abbr>WKT</abbr> 1 est (<var>longitude</var>, <var>latitude</var>) tel que spécifié par le standard <abbr>OGC</abbr> 01-009.</li>
-<li>L’ordre par défaut d’un <abbr>CRS</abbr> géographique en <abbr>WKT</abbr> 2 est (<var>latitude</var>, <var>longitude</var>), mais c’est une interprétation spécifique de <abbr>SIS</abbr>
-vu que la norme <abbr title="International Organization for Standardization">ISO</abbr> 19162 ne mentionne pas de comportement par défaut.</li>
-</ul>
-<p>
-Pour éviter des ambiguïtés, les utilisateurs sont encouragés à toujours fournir explicitement les éléments <code class="OGC">AXIS[…]</code> dans leurs <abbr>WKT</abbr>.
-Le format <abbr>WKT</abbr> sera présenté plus en détails dans les sections suivantes.
-</p>
-
-<h3 id="GeographicCRS"><span class="section-number">5.1.4.</span> Systèmes géographiques</h3>
-<p>
-Il y a plusieurs sortes de latitudes et de longitudes.
-Deux sortes courantes que supporte Apache <abbr title="Spatial Information System">SIS</abbr> sont les latitudes <cite>géodésiques</cite> et <cite>géocentriques</cite>.
-Ces deux types d’angles diffèrent légèrement dans la façon dont ils interceptent la surface de l’ellipsoïde.
-Sur la surface de la Terre, la différence entre ces deux types de latitudes varient de 0 à environ 20 km.
-</p><p>
-Lorsque les gens parlent de latitudes et de longitudes, ils sous-entendent généralement des latitudes <em>géodésiques</em>.
-Un système de référence des coordonnées utilisant de telles latitudes et longitudes est dit <cite>géographique</cite>
-et est représenté par l’interface <code class="GeoAPI">GeographicCRS</code>.
-Les systèmes utilisant les autres sortes de latitudes sont représentés par d’autres interfaces <abbr>CRS</abbr>.
-</p>
-
-<h3 id="ProjectedCRS"><span class="section-number">5.1.5.</span> Projections cartographiques</h3>
-<p>
-Les projections cartographiques représentent une surface courbe (la Terre) sur une surface plane (une carte ou un écran d’ordinateur)
-en contrôlant les déformations: on peut préserver les angles ou les surfaces, mais pas les deux à la fois.
-Les propriétés géométriques à conserver dépendent de l’objet d’étude et du travail à effectuer.
-Par exemple les pays plutôt allongés dans le sens Est-Ouest utilisent souvent une projection de Lambert,
-alors que les pays plutôt allongés dans le sens Nord-Sud préfèrent une projection de Mercator Transverse.
-</p>
-<div class="warning">
-Cette section est incomplète. Voyez la version anglaise pour une version éventuellement plus complète.
-</div>
-</section>
-
-
-<section>
-<header>
-<h2 id="CoordinateOperations"><span class="section-number">5.2.</span> Opérations sur les coordonnées</h2>
-</header>
-<p>
-Étant donné un système de référence des coordonnées (<abbr>CRS</abbr>) <em>source</em> selon lequel sont exprimés des coordonnées existantes
-et un système de référence des coordonnées <em>destination</em> selon lequel les coordonnées sont désirées,
-Apache <abbr title="Spatial Information System">SIS</abbr> peut fournir une <em>opération sur les coordonnées</em> qui effectuera le travail de conversion ou de transformation.
-La recherche d’une opération peut utiliser un troisième argument, optionnel mais recommandé: la région géographique des données à transformer.
-Ce dernier argument est recommandé parce que les opérations sur les coordonnées sont souvent valides seulement dans une région géographique
-(typiquement un pays ou une province particulière), et plusieurs transformations peuvent exister pour la même paire de <abbr>CRS</abbr>
-source et destination mais avec des domaines de validité différents.
-Il peut aussi y avoir des différentes transformations qui sont différents compromis entre la précision et le domaine de validité,
-de sorte que spécifier à Apache <abbr>SIS</abbr> qu’on s’intéresse à une région plus petite
-peut lui permettre de sélectionner une opération plus précise.
-</p>
-<div class="example"><p><b>Exemple:</b>
-la base de données géodésiques <abbr>EPSG</abbr> (dans sa version 7.9) définit 77 opérations sur les coordonnées
-allant du système géographique <cite>North American Datum 1927</cite> (EPSG:4267)
-vers le système <cite>World Geodetic System 1984</cite> (EPSG:4326).
-Il y a une opération valide seulement pour la transformation de coordonnées au Québec,
-une autre opération valide pour la transformation de coordonnées au Texas mais à l’ouest de 100°W,
-une autre opération pour le même état mais à l’est de 100°W, <i>etc</i>.
-Si l’utilisateur ne spécifie pas la région géographique qui l’intéresse,
-alors le comportement par défaut de Apache <abbr>SIS</abbr> est de sélectionner l’opération valide dans la plus grande région géographique.
-Dans cet exemple, ce critère entraîne la sélection d’une opération valide pour le Canada, mais qui n’est pas valide pour les États-Unis.</p>
-</div>
-
-
-<h3 id="CRS.findOperation"><span class="section-number">5.2.1.</span> Obtention d’une opération sur les coordonnées</h3>
-<p>
-La façon la plus facile d’obtenir une opération sur les coordonnées à partir des informations présentées ci-dessus
-est d’utiliser la classe de commodité <code class="SIS">org.apache.sis.referencing.CRS</code>:
-</p>
-
-<pre><code><code class="GeoAPI">CoordinateOperation</code> cop = <code class="SIS">CRS.findOperation</code>(sourceCRS, targetCRS, areaOfInterest);</code></pre>
-
-<p>
-Parmi les information fournies par l’objet <code class="GeoAPI">CoordinateOperation</code> obtenu, on note en particulier:
-</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>
-<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 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>
-Lorsque l’opération sur les coordonnées est une instance de <code class="GeoAPI">Transformation</code>,
-il est possible que l’instance choisie par <abbr title="Spatial Information System">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 class="GeoAPI">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"><span class="section-number">5.2.2.</span> Exécution de opérations</h3>
-<p>
-L’objet <code class="GeoAPI">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 class="GeoAPI">CoordinateOperation.getMathTransform()</code>.
-Contrairement aux instances de <code class="GeoAPI">CoordinateOperation</code>, les instances de <code class="GeoAPI">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 class="GeoAPI">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 class="GeoAPI">MathTransform</code> peut être implémentée d’une manière très différente à ce que <code class="GeoAPI">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 class="GeoAPI">MathTransform</code> comme des <a href="#AffineTransform">transformations affines</a>
-et concaténées pour des raisons d’efficacité, même si <code class="GeoAPI">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 title="World Geodetic System 1984">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 class="SIS">CommonCRS</code>.
-Mais des applications plus avancées voudront souvent utiliser des codes <abbr>EPSG</abbr> plutôt.
-Notons que toutes les coordonnées géographiques dans ce code ont la latitude avant la longitude.
-</p>
-
-<pre><code><b>import</b> org.opengis.geometry.<code class="GeoAPI">DirectPosition</code>;
-<b>import</b> org.opengis.referencing.crs.<code class="GeoAPI">CoordinateReferenceSystem</code>;
-<b>import</b> org.opengis.referencing.operation.<code class="GeoAPI">CoordinateOperation</code>;
-<b>import</b> org.opengis.referencing.operation.<code class="GeoAPI">TransformException</code>;
-<b>import</b> org.opengis.util.<code class="GeoAPI">FactoryException</code>;
-<b>import</b> org.apache.sis.referencing.CRS;
-<b>import</b> org.apache.sis.referencing.<code class="SIS">CommonCRS</code>;
-<b>import</b> org.apache.sis.geometry.<code class="SIS">DirectPosition2D</code>;
-
-<b>public</b> <b>class</b> MyApp {
- <b>public</b> <b>static</b> <b>void</b> main(String[] args) <b>throws</b> <code class="GeoAPI">FactoryException</code>, <code class="GeoAPI">TransformException</code> {
- <code class="GeoAPI">CoordinateReferenceSystem</code> sourceCRS = <code class="SIS">CommonCRS</code>.WGS84.geographic();
- <code class="GeoAPI">CoordinateReferenceSystem</code> targetCRS = <code class="SIS">CommonCRS</code>.WGS84.universal(40, 14); <code class="comment">// Obtient la zone valide pour 14°E.</code>
- <code class="GeoAPI">CoordinateOperation</code> operation = <code class="SIS">CRS.findOperation</code>(sourceCRS, targetCRS, <b>null</b>);
-
- <code class="comment">// Les lignes précédentes sont coûteuses et ne devraient être exécutées qu’une seule fois avant</code>
- <code class="comment">// de transformer plusieurs points. Dans cet exemple, l’opération que nous obtenons est valide</code>
- <code class="comment">// pour des coordonnées dans la région géographique allant de 12°E à 18°E (zone 33) et 0°N à 84°N.</code>
-
- <code class="GeoAPI">DirectPosition</code> ptSrc = <b>new</b> <code class="SIS">DirectPosition2D</code>(40, 14); <code class="comment">// 40°N 14°E</code>
- <code class="GeoAPI">DirectPosition</code> ptDst = operation.getMathTransform().transform(ptSrc, <b>null</b>);
-
- System.out.println(<i>"Source: "</i> + ptSrc);
- System.out.println(<i>"Target: "</i> + ptDst);
- }
-}</code></pre>
-
-
-<h3 id="TransformDerivative"><span class="section-number">5.2.3.</span> Dérivées partielles des opérations</h3>
-<p>
-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="https://www.ogc.org/standards/ct">OGC 01-009</a>, aujourd’hui un peu oubliée mais pourtant encore utile.
-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>
-
-<div class="row-of-boxes">
-<div style="min-width:350px; padding-right:60px">
-<div class="caption">Équation</div>
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<mi>P</mi><mo>(</mo><mi>φ</mi><mo>,</mo><mi>λ</mi><mo>)</mo>
-<mo>=</mo>
-<mrow>
-<mo>[</mo>
-<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>
-<mo>]</mo>
-</mrow>
-</math>
-</div>
-<div style="min-width:500px; padding-left:60px">
-<div class="caption">Code Java</div>
-<pre style="margin:0"><code><code class="GeoAPI">DirectPosition</code> geographic = <b>new</b> <code class="SIS">DirectPosition2D</code>(<var>φ</var>, <var>λ</var>);
-<code class="GeoAPI">DirectPosition</code> projected = <var><b>P</b></var>.transform(geographic, <b>null</b>);
-<b>double</b> <var>x</var> = projected.getOrdinate(0);
-<b>double</b> <var>y</var> = projected.getOrdinate(1);</code></pre>
-</div>
-</div>
-
-<p>La dérivée de la projection cartographique en ce même point peut se représenter par une matrice Jacobienne:</p>
-
-<div class="row-of-boxes">
-<div style="min-width:350px; padding-right:60px">
-<div class="caption">Équation</div>
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<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>
-<mrow>
-<mo>[</mo>
-<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>
-<mo>]</mo>
-</mrow>
-</math>
-</div>
-<div style="min-width:500px; padding-left:60px">
-<div class="caption">Code Java</div>
-<pre style="margin:0"><code><code class="GeoAPI">DirectPosition</code> geographic = <b>new</b> <code class="SIS">DirectPosition2D</code>(<var>φ</var>, <var>λ</var>);
-<code class="GeoAPI">Matrix</code> jacobian = <var><b>P</b></var>.derivative(geographic);
-<b>double</b> dx_dλ = jacobian.getElement(0,1);
-<b>double</b> dy_dφ = jacobian.getElement(1,0);</code></pre>
-</div>
-</div>
-
-<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 Jacobiennes.
-</p>
-
-<div class="row-of-boxes">
-<div>
-<img alt="Exemple de dérivées d’une projection cartographique" src="../images/Derivatives.png" style="border: solid 1px"/>
-</div><div>
-<p>où les vecteurs sont reliés à la matrice par:</p>
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<mtable><mtr>
-<mtd>
-<mover><mi>U</mi><mo>→</mo></mover><mo>=</mo>
-<mrow>
-<mo>[</mo>
-<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>
-<mo>]</mo>
-</mrow>
-</mtd>
-<mtd><mtext>et</mtext></mtd>
-<mtd>
-<mover><mi>V</mi><mo>→</mo></mover><mo>=</mo>
-<mrow>
-<mo>[</mo>
-<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>
-<mo>]</mo>
-</mrow>
-</mtd>
-</mtr></mtable>
-</math>
-</div>
-</div>
-
-<p>
-Cette figure nous montre déjà une utilisation possible des dérivées:
-elles donnent la direction des parallèles et des méridiens à une position donnée dans une projection cartographique.
-Par extension, on peut aussi s’en servir pour déterminer si des axes sont interchangés,
-ou si la direction d’un axe est renversée. Mais l’intérêt des dérivées ne s’arrête pas là.
-</p>
-
-<h4 id="DerivativeAndEnvelope"><span class="section-number">5.2.3.1.</span> Utilité des dérivées pour la reprojection d’enveloppes</h4>
-<p>
-Les systèmes d’information géographiques ont très fréquemment besoin de projeter une enveloppe.
-Mais l’approche naïve, qui consisterait à projeter chacun des 4 coins du rectangle, ne suffit pas.
-La figure ci-dessous montre une enveloppe avant le projection, et la forme géométrique que l’on obtiendrait
-si on projetait finement l’enveloppe (pas seulement les 4 coins). Cette forme géométrique est plus complexe
-qu’un simple rectangle à cause des courbures induites par la projection cartographique.
-Construire une enveloppe rectangulaire qui engloberait les 4 coins de cette forme géométrique ne suffit pas,
-car la surface en bas de la forme est plus basse que les 2 coins du bas.
-Cette surface serait donc en dehors du rectangle.
-</p>
-<div class="row-of-boxes">
-<div>
-<div class="caption">Enveloppe avant la projection</div>
-<img alt="Enveloppe dans un CRS géographique" src="../images/GeographicArea.png" style="border: solid 1px; margin-right: 15px"/>
-</div><div>
-<div class="caption">Forme géométrique après la projection</div>
-<img alt="Forme géométrique dans un CRS projeté" src="../images/ConicArea.png" style="border: solid 1px; margin-left: 15px"/>
-</div>
-</div>
-<p>
-Une façon simple d’atténuer le problème est d’échantillonner un plus grand nombre de points sur chacun des
-bords de la forme géométrique. On trouve ainsi des bibliothèques de <abbr>SIG</abbr> qui vont par exemple
-échantillonner 40 points sur chaque bord, et construire un rectangle qui englobe tout ces points.
-Mais même avec 40 points, les échantillons les plus proches peuvent encore être légèrement à côté du point le plus bas de la figure.
-Une petite portion de la forme géométrique peut donc toujours se trouver en dehors du rectangle.
-Il est tentant de considérer cette légère erreur comme négligeable, mais quelques pixels manquants
-entraînent divers artefacts comme une apparence de quadrillage lors de l’affichage d’images tuilées,
-ou une “pointe de tarte” manquante lors de la projection d’images sur un pôle.
-Augmenter artificiellement d’un certain pourcentage la taille de l’enveloppe projetée peut éliminer ces artefacts dans certains cas.
-Mais un pourcentage trop élevé fera traiter plus de données que nécessaire
-(en particulier lorsque cela entraîne le chargement de nouvelles tuiles d’images),
-alors qu’un pourcentage trop faible laissera quelques artefacts.
-</p><p>
-Les dérivées des projections cartographiques permettent de résoudre ce problème d’une manière plus efficace que la force brute.
-La figure ci-dessous reprend la forme projetée en exagérant des déformations.
-L’approche consiste à calculer la projection cartographiques des 4 coins comme dans l’approche naïve,
-mais en récupérant aussi les dérivées de la projection de ces 4 coins.
-Entre deux coins et avec leurs dérivées, on peut faire passer une et une seule courbe cubique
-(de la forme <i>f(<var>x</var>)</i> = <var>C</var>₀ + <var>C</var>₁<var>x</var> + <var>C</var>₂<var>x</var>² + <var>C</var>₃<var>x</var>³),
-dont on peut calculer les coefficients <var>C</var>.
-Cette approximation (représentée en rouge ci-dessous) ne correspond pas tout-à-fait à la courbe désirée (en bleue) mais s’en rapproche.
-Ce qui nous intéresse n’est pas vraiment les valeurs de l’approximation, mais plutôt la position de son minimum,
-en particulier la longitude λ où se trouve ce minimum dans notre exemple (ligne pointillée verte).
-L’avantage est que la position du minimum d’une courbe cubique est facile à calculer lorsque l’on connaît les valeurs de <var>C</var>.
-En supposant que la longitude du minimum de la courbe cubique est proche de la longitude du minimum de la courbe réelle,
-il suffit de calculer la projection cartographique d’un point à cette longitude plutôt que d’échantillonner 40 points sur le bord de l’enveloppe.
-</p>
-<div class="row-of-boxes">
-<div>
-<img alt="Approximation cubique d’un bord d’une enveloppe" src="../images/Approximation.png"/>
-</div><div>
-Légende:
-<ul>
-<li><b>En bleue:</b> la forme géométrique correspondant à la projection de l’enveloppe.
-C’est la forme dont on souhaite avoir le rectangle englobant.</li>
-<li><b>En rouge</b> (sous les hachures): L’approximation
-<var>y</var> = <var>C</var>₀ + <var>C</var>₁λ + <var>C</var>₂λ² + <var>C</var>₃λ³.</li>
-<li><b>En vert</b> (pointillés): La position λ<sub>m</sub> du minimum de l’approximation, trouvée en résolvant
-0 = <var>C</var>₁ + 2<var>C</var>₂λ<sub>m</sub> + 3<var>C</var>₃λ<sub>m</sub>².
-Il peut y avoir jusqu’à deux minimums pour une même courbe cubique.</li>
-</ul>
-</div>
-</div>
-<p>
-Dans la pratique Apache <abbr title="Spatial Information System">SIS</abbr> utilise 8 points, soit les 4 coins plus un point au centre de chaque bord du rectangle à projeter,
-afin de réduire le risque d’erreur qu’induirait une courbe trop tordue entre deux points.
-Selon nos tests, l’utilisation de ces seuls 8 points avec leurs dérivées comme décrit ci-haut
-donne un résultat plus précis que l’approche « force brute » utilisant un échantillonnage de 160 points sur les 4 bords du rectangle.
-La précision de <abbr>SIS</abbr> pourrait être encore améliorée en répétant le processus à partir du minimum trouvée
-(une ou deux itérations suffiraient peut-être).
-</p><p>
-Une économie de 150 points n’est pas énorme vu les performances des ordinateurs d’aujourd’hui.
-Mais toute la discussion précédente utilisait une forme géométrique à deux dimensions en guise d’exemple,
-alors que l’algorithme est applicable dans un espace à <var>n</var> dimensions.
-Et de fait, l’implémentation de Apache SIS fonctionne pour un nombre arbitraire de dimensions.
-Les économies apportées par cet algorithme par rapport à la force brute augmentent de manière exponentielle avec le nombre de dimensions.
-</p><p>
-L’approche décrite dans cette section est implémentée dans Apache <abbr>SIS</abbr>
-par la méthode statique <code class="SIS">Envelopes.transform(CoordinateOperation, Envelope)</code>.
-Une méthode <code class="SIS">Envelopes.transform(MathTransform, Envelope)</code> existe aussi comme alternative,
-mais cette dernière ne devrait être utilisée que si on ne connaît pas l’objet <code class="GeoAPI">CoordinateOperation</code> utilisé.
-La raison est que les objets de type <code class="GeoAPI">MathTransform</code> ne contiennent pas d’information sur le système de coordonnées sous-jasent,
-ce qui empêche la méthode <code class="SIS">Envelopes.transform(…)</code> de savoir comment gérer les points aux pôles.
-</p>
-
-
-<h4 id="DerivativeAndRaster"><span class="section-number">5.2.3.2.</span> Utilité des dérivées pour la reprojection d’images</h4>
-<p>
-La projection cartographique d’une image s’effectue en préparant une image initialement vide qui contiendra le résultat de l’opération,
-puis à remplir cette image en itérant sur tous les pixels. Pour chaque pixel de l’image <em>destination</em>, on obtient la coordonnées
-du pixel correspondant dans l’image source en utilisant <em>l’inverse</em> de la projection cartographique que l’on souhaite appliquer.
-La position obtenue ne sera pas nécessairement au centre du pixel de l’image source, ce qui implique qu’une interpolation de la valeur
-(ou de la couleur dans l’image ci-dessous) peut être nécessaire.
-</p>
-<div style="display:flex; flex-direction:column; align-items:center">
-<div style="display:flex; justify-content:space-between; width:564px">
-<div class="caption">Image source</div>
-<div class="caption">Image destination</div>
-</div>
-<img alt="Reprojection d’images" src="../images/RasterProjection.png"/>
-</div>
-<p>
-Toutefois, calculer la projection inverse pour chacun des pixels peut être relativement lent.
-Afin d’accélérer les calculs, on utilise parfois une <cite>grille d’interpolation</cite>
-dans laquelle on a pré-calculé les <em>coordonnées</em> de la projection inverse de seulement quelques points.
-Les coordonnées des autres points se calculent alors par des interpolations bilinéaires entre les points pré-calculés,
-calculs qui pourraient éventuellement tirer parti d’accélérations matérielles sous forme de <cite>transformations affines</cite>.
-Cette approche est implémentée par exemple dans la bibliothèque <cite>Java Advanced Imaging</cite> avec l’objet <code>WarpGrid</code>.
-Elle offre en outre l’avantage de permettre de réutiliser la grille autant de fois que l’on veut si on a plusieurs images de même
-taille à projeter aux mêmes coordonnées géographiques.
-</p><p>
-Mais une difficulté de cette approche est de déterminer combien de points il faut pré-calculer pour que l’erreur
-(la différence entre une position interpolée et la position réelle) ne dépasse pas un certain seuil (par exemple ¼ de pixel).
-On peut procéder en commençant par une grille de taille 3×3, puis en augmentant le nombre de points de manière itérative:
-</p>
-<div class="row-of-boxes">
-<div>
-<img alt="Warp grid" src="../images/WarpGrid.png"/>
-</div><div>
-Légende:
-<ul>
-<li><b>Points bleus:</b> première itération (9 points).</li>
-<li><b>Points verts:</b> seconde itération (25 points, dont 16 nouveaux).</li>
-<li><b>Points rouges:</b> troisième itération (81 points, dont 56 nouveaux).</li>
-</ul>
-Si l’on continue…
-<ul>
-<li>Quatrième itération: 289 points, dont 208 nouveaux.</li>
-<li>Cinquième itération: 1089 points, dont 800 nouveaux.</li>
-<li>Sixième itération: 4225 points, dont 3136 nouveaux.</li>
-<li>…</li>
-</ul>
-</div>
-</div>
-<p>
-L’itération s’arrête lorsque, après avoir calculé de nouveaux points, on a vérifié que la différence entre les
-coordonnées projetées et les coordonnées interpolées de ces nouveaux points est inférieure au seuil qu’on s’est fixé.
-Malheureusement cette approche nous permet seulement de déterminer <strong>après</strong> avoir calculé de nouveaux points…
-que ce n’était pas la peine de les calculer. C’est un peu dommage vu que le nombre de nouveaux points requis par chaque itération
-est environ 3 fois la <em>somme</em> du nombre de nouveaux points de <em>toutes</em> les itérations précédentes.
-</p><p>
-Les dérivées des projections cartographiques nous permettent d’améliorer cette situation en estimant
-si c’est la peine d’effectuer une nouvelle itération <strong>avant</strong> de la faire.
-L’idée de base est de vérifier si les dérivées de deux points voisins sont presque pareilles,
-auquel cas on présumera que la transformation entre ces deux points est pratiquement linéaire.
-Pour quantifier « presque pareil », on procède en calculant l’intersection entre les tangentes aux deux points
-(une information fournie par les dérivées), et en calculant la distance entre cette intersection et la droite
-qui relie les deux points (la ligne pointillée dans la figure ci-dessous).
-</p>
-<p style="text-align:center"><img alt="Intersection of derivatives" src="../images/IntersectionOfDerivatives.png" style="border: solid 1px"/></p>
-<p>
-Dans l’approche sans dérivées, l’itération s’arrête lorsque la distance entre la ligne pointillée (positions interpolées)
-et la ligne rouge (positions projetées) est inférieure au seuil de tolérance, ce qui implique de calculer la position projetée.
-Dans l’approche avec dérivées, on remplace la position projetée par l’intersection des deux tangentes (carré bleu foncé).
-Si la courbe n’est pas trop tordue – ce qui ne devrait pas être le cas entre deux points suffisamment proches –
-la courbe réelle passera à quelque part entre la droite pointillée et l’intersection.
-On s’évite ainsi des projections cartographiques, en apparence une seule dans cette illustration,
-mais en fait beaucoup plus dans une grille de transformation d’image (3× la somme des itérations précédentes).
-</p>
-
-<h4 id="GetDerivative"><span class="section-number">5.2.3.3.</span> Obtention de la dérivée en un point</h4>
-<p>
-Cette discussion n’aurait pas un grand intérêt si le coût du calcul des dérivées des projections cartographiques
-était élevé par rapport aux coût de la projection des points. Mais lorsque l’on dérive analytiquement les équations
-des projections, on constate que les calculs des positions et de leurs dérivées ont souvent plusieurs termes en commun.
-En outre le calcul des dérivées est simplifié lorsque le code Java effectuant les projections ne se concentre que sur le « noyau » non-linéaire,
-après s’être déchargé des parties linéaires en les déléguant aux transformations affines comme le fait <abbr title="Spatial Information System">SIS</abbr>.
-Les implémentations des projections cartographiques dans Apache <abbr>SIS</abbr> tirent parti de ces propriétés
-en ne calculant les dérivées que si elles sont demandées,
-et en offrant une méthode qui permet de projeter un point et obtenir sa dérivée en une seule opération
-afin de permettre à <abbr>SIS</abbr> de réutiliser un maximum de termes communs.
-Exemple:</p>
-
-<pre><code><code class="SIS">AbstractMathTransform</code> projection = ...; <code class="comment">// Une projection cartographique de Apache SIS.</code>
-<b>double</b>[] sourcePoint = {longitude, latitude}; <code class="comment">// La coordonnée géographique que l’on veut projeter.</code>
-<b>double</b>[] targetPoint = <b>new</b> <b>double</b>[2]; <code class="comment">// Là où on mémorisera le résultat de la projection.</code>
-<code class="GeoAPI">Matrix</code> derivative = projection.<code class="SIS">transform</code>(sourcePoint, 0, targetPoint, 0, <b>true</b>);</code></pre>
-
-<p>
-Si seule la matrice Jacobienne est désirée (sans la projection du point), alors la méthode
-<code class="GeoAPI">MathTransform.derivative(DirectPosition)</code> offre une alternative plus lisible.
-</p><p>
-Apache <abbr>SIS</abbr> est capable combiner les dérivées des projections cartographiques de la même façon que pour les projections de coordonnées:
-concaténation d’une chaîne de transformations, inversion, opérer sur un sous-ensemble des dimensions, <i>etc.</i>
-Les opérations inverses (des systèmes projetés vers géographiques)
-sont souvent beaucoup plus compliquées à implémenter que les opérations originales (des systèmes géographiques vers projetés),
-mais par chance la matrice Jacobienne d’une fonction inverse est simplement l’inverse de la matrice Jacobienne de la fonction originale.
-Une fonction inverse peut donc implémenter le calcul de sa dérivée comme suit:
-</p>
-
-<pre><code>@Override
-<b>public</b> <code class="GeoAPI">Matrix</code> derivative(<code class="GeoAPI">DirectPosition</code> p) <b>throws</b> <code class="GeoAPI">TransformException</code> {
- <code class="GeoAPI">Matrix</code> jac = inverse().derivative(transform(p));
- <b>return</b> <code class="SIS">Matrices</code>.inverse(jac);
-}</code></pre>
-
-</section>
-<div class="warning">
-Ce chapitre est incomplet. Voyez la version anglaise pour une version plus complète.
-</div>
-</section>
-
-
-<section>
-<header>
-<h2 id="Formats"><span class="section-number">5.3.</span> Formats de stockage des données</h2>
-</header>
-<p>
-Apache <abbr title="Spatial Information System">SIS</abbr> peut lire et écrire des données spatiales et leurs méta-données associées dans différents formats.
-
-</p>
-
-
-
-
-<section>
-<header>
-<h2 id="XML-ISO"><span class="section-number">5.4.</span> Représentation des objets en <abbr>XML</abbr></h2>
-</header>
-<p>
-Les objets définis par les standards <abbr title="Open Geospatial Consortium">OGC</abbr>/<abbr title="International Organization for Standardization">ISO</abbr> doivent pouvoir être échangés sur internet
-entre des machines distantes, utilisant des logiciels différents écrits dans des langages différents.
-Quelques uns des formats les plus connus sont
-le <abbr>WKT</abbr> (<i>Well-Known Text</i>) et
-le <abbr>WKB</abbr> (<i>Well-Known Binary</i>).
-Mais le format le plus exhaustif et souvent considéré comme la référence est le <abbr>XML</abbr>,
-au point où la façon de représenter les objets <abbr>ISO</abbr> dans ce format fait parfois l’objet d’un standard international à part entière.
-Ainsi, les classes de méta-données sont décrites dans le standard <abbr>ISO</abbr> 19115-1 (une spécification dite <i>abstraite</i>),
-alors que la représentation de ces classes en <abbr>XML</abbr> est décrite par les standards <abbr>ISO</abbr> 19115-3 et 19139.
-</p>
-<p>
-Les différents standards <abbr>OGC</abbr>/<abbr>ISO</abbr> n’emploient pas tous la même stratégie pour exprimer les objets en <abbr>XML</abbr>.
-Le standard <abbr>ISO</abbr> 19115-3 en particulier emploie une approche plus verbeuse que les autres normes,
-et fera l’objet d’une <a href="#XML-ISO-19115">section particulière</a>.
-Mais la plupart des formats <abbr>XML</abbr> ont en commun de définir des types et des attributs supplémentaires
-qui ne font pas partie des spécifications abstraites d’origines.
-Ces attributs supplémentaires sont habituellement propres au <abbr>XML</abbr> et peuvent ne pas apparaître directement dans l’<abbr title="Application Programming Interface">API</abbr> de Apache <abbr title="Spatial Information System">SIS</abbr>.
-Certains de ces attributs, notamment <code class="OGC">id</code>, <code class="OGC">uuid</code> et <code>xlink:href</code>,
-restent toutefois accessibles sous forme de paires clé-valeurs.
-</p>
-<p>
-Les documents <abbr>XML</abbr> peuvent employer les préfixes de leur choix,
-mais les préfixes suivants sont couramment employés dans la pratique.
-Ils apparaissent donc par défaut dans les documents produits par Apache <abbr>SIS</abbr>.
-Ces préfixes sont définis dans la classe <code class="SIS">org.apache.sis.xml.Namespaces</code>.
-</p>
-<table>
-<caption>Préfixes d’espaces de noms <abbr>XML</abbr> courants</caption>
-<tr>
-<th>Préfixe</th>
-<th>Espace de nom</th>
-</tr>
-<tr>
-<td><code class="OGC">gco</code></td>
-<td><code>http://www.isotc211.org/2005/gco</code></td>
-</tr>
-<tr>
-<td><code class="OGC">gfc</code></td>
-<td><code>http://www.isotc211.org/2005/gfc</code></td>
-</tr>
-<tr>
-<td><code class="OGC">gmd</code></td>
-<td><code>http://www.isotc211.org/2005/gmd</code></td>
-</tr>
-<tr>
-<td><code class="OGC">gmi</code></td>
-<td><code>http://www.isotc211.org/2005/gmi</code></td>
-</tr>
-<tr>
-<td><code class="OGC">gmx</code></td>
-<td><code>http://www.isotc211.org/2005/gmx</code></td>
-</tr>
-<tr>
-<td><code class="OGC">gml</code></td>
-<td><code>http://www.opengis.net/gml/3.2</code></td>
-</tr>
-<tr>
-<td><code>xlink</code></td>
-<td><code>http://www.w3.org/1999/xlink</code></td>
-</tr>
-</table>
-
-<aside>
-<h2>Outils de lecture et d’écriture de documents <abbr>XML</abbr></h2>
-<p>
-Apache <abbr title="Spatial Information System">SIS</abbr> emploie différentes bibliothèques pour lire et écrire différents type d’objets.
-La bibliothèque utilisée dépend de la complexité de l’objet et des contraintes de performances.
-Par exemple les annotations de <abbr title="Java Architecture for XML Binding">JAXB</abbr> ont l’avantage d’être proches du code,
-ce qui facilite la maintenance de la correspondance entre le Java et le <abbr>XML</abbr>.
-En revanche <abbr title="Simple API for XML">SAX</abbr> a l’avantage d’être performant.
-De manière générale, Apache <abbr>SIS</abbr> emploie:
-</p>
-<ul>
-<li>
-<abbr>JAXB</abbr> pour les objets qui ne sont pas répétés très souvent dans le document
-mais dont la structure est complexe, avec des arborescences profondes.
-L’ensemble des méta-données <abbr title="International Organization for Standardization">ISO</abbr> 19115-3 est un exemple typique.
-</li>
-<li>
-<abbr>SAX</abbr> pour les objets relativement simples mais pouvant exister en très grand nombre.
-L’ensemble des points dans une géométrie est un exemple typique.
-</li>
-<li>
-<abbr title="Document Object Model">DOM</abbr> comme une alternative à <abbr>JAXB</abbr>
-lorsque les éléments <abbr>XML</abbr> ne correspondent pas directement à des attributs Java.
-Les <i>features</i> en sont un exemple, car leur structure est dynamique.
-</li>
-</ul>
-</aside>
-
-
-
-
-<section>
-<header>
-<h3 id="XML-ISO-19115"><span class="section-number">5.4.1.</span> Représentation des méta-données selon <abbr title="International Organization for Standardization">ISO</abbr> 19115-3</h3>
-</header>
-<p>
-Pour chaque classe de méta-donnée, il existe un type <abbr>XML</abbr> portant le même nom que dans la spécification abstraite
-(par exemple <code class="OGC">mdb:MD_Metadata</code> et <code class="OGC">cit:CI_Citation</code>).
-Tous ces types peuvent être employés comme racine d’un document <abbr>XML</abbr>.
-Ainsi, il est possible d’écrire un document représentant un objet <code class="OGC">MD_Metadata</code> complet,
-ou d’écrire un document représentant seulement un objet <code class="OGC">CI_Citation</code>.
-</p>
-<p>
-Le standard <abbr>ISO</abbr> 19139 dispose le contenu de ces objets d’une manière inhabituelle:
-pour chaque propriété dont le type de la valeur est lui-même une autre classe du standard <abbr>ISO</abbr> 19139,
-la valeur est enveloppée dans un élément qui représente son type plutôt que d’être écrite directement.
-Par exemple dans un objet de type <code class="OGC">CI_Citation</code>,
-la valeur de la propriété <code class="OGC">citedResponsibleParty</code>
-est enveloppée dans un élément <code class="OGC">CI_Responsibility</code>.
-Cette pratique double la profondeur de l’arborescence, en introduisant une duplication
-à tous les niveaux pour chaque valeur, comme dans l’exemple suivant:
-</p>
-
-<pre><samp class="xml"><b><MD_Metadata></b>
- <identificationInfo>
- <b><MD_DataIdentification></b>
- <citation>
- <b><CI_Citation></b>
- <citedResponsibleParty>
- <b><CI_Responsibility></b>
- <party>
- <b><CI_Party></b>
- <contactInfo>
- <b><CI_Contact></b>
- <onlineResource>
- <b><CI_OnlineResource></b>
- <linkage>
- <URL>https://www.ogc.org</URL>
- </linkage>
- <b></CI_OnlineResource></b>
- </onlineResource>
- <b></CI_Contact></b>
- </contactInfo>
- <b></CI_Party></b>
- </party>
- <b></CI_Responsibility></b>
- </citedResponsibleParty>
- <b></CI_Citation></b>
- </citation>
- <b></MD_DataIdentification></b>
- </identificationInfo>
-<b></MD_Metadata></b></samp></pre>
-
-<p>
-L’exemple précédent, comme tous les documents conformes à <abbr>ISO</abbr> 19139,
-est donc constitué d’une alternance systématique de deux types d’éléments <abbr>XML</abbr> imbriqués:
-</p>
-<ol>
-<li><p>
-Il y a d’abord le nom de la propriété, qui commence toujours par une lettre minuscule (en ignorant les préfixes).
-Dans les <abbr title="Application Programming Interface">API</abbr> Java, chaque propriété correspond à une méthode de la classe englobante.
-Dans l’exemple ci-haut, <code class="OGC">mdb:identificationInfo</code> (une propriété de la classe <code class="OGC">MD_Metadata</code>)
-correspond à la méthode <code class="GeoAPI">Metadata.getIdentificationInfo()</code>.
-</p></li>
-<li><p>
-Sous chaque propriété se trouve le type de la valeur, sauf si elle a été remplacée par une référence
-(la <a href="#gco-id">sous-section suivante</a> suivante approfondira ce sujet).
-Le type de la valeur est un élément <abbr>XML</abbr> dont le nom commence toujours par une lettre majuscule, en ignorant les préfixes.
-Dans l’exemple ci-haut nous avions <code class="OGC">MD_DataIdentification</code>, qui correspond à l’interface Java <code class="GeoAPI">DataIdentification</code>.
-C’est cet élément <abbr>XML</abbr> qui contient les valeurs de la propriété.
-</p></li>
-</ol>
-
-<p>
-Afin de réduire la complexité des bibliothèques, GeoAPI et Apache <abbr title="Spatial Information System">SIS</abbr>
-n’exposent publiquement qu’une vision unifiée de ces deux types d’éléments.
-L’<abbr>API</abbr> public correspond essentiellement au deuxième groupe.
-Toutefois, lors de l’écriture d’un document <abbr>XML</abbr>, des éléments du premier groupe doivent être temporairement recréés.
-Les classes qui y correspondent sont définies dans des paquets internes de <abbr>SIS</abbr>.
-Ces classes peuvent être ignorées, sauf si le développeur souhaite implémenter ses propres classes
-dont les instances devront être lues et écrites par <abbr title="Java Architecture for XML Binding">JAXB</abbr>.
-</p>
-
-<aside id="XML-SIS">
-<h3>Stratégie d’implémentation dans Apache <abbr title="Spatial Information System">SIS</abbr></h3>
-<p>
-Les paquets <code class="SIS">org.apache.sis.internal.jaxb.*</code> (non-publiques)
-définissent des adaptateurs <abbr title="Java Architecture for XML Binding">JAXB</abbr> pour tous les types d’objet <abbr title="International Organization for Standardization">ISO</abbr>.
-Ces adaptateurs sont de toute façon nécessaires pour permettre à <abbr>JAXB</abbr>
-d’obtenir les classes <abbr>SIS</abbr> implémentant les interfaces de GeoAPI.
-De manière opportuniste, <abbr>SIS</abbr> en fait à la fois des adaptateurs <abbr>JAXB</abbr>
-et des objets enveloppants le “vrai” objet à lire ou écrire.
-Cette utilisation double permet d’éviter d’avoir à doubler le nombre de classes
-(déjà très élevé) présents dans les paquets internes.
-</p>
-<h4>Convention de nommage dans les schémas <abbr title="XML Schema Definition">XSD</abbr></h4>
-<p>
-Les schémas <abbr>XSD</abbr> de l’<abbr title="Open Geospatial Consortium">OGC</abbr> définissent pour chaque élément du premier groupe
-un type dont le nom se termine par “<code class="OGC">_PropertyType</code>”.
-Pour le second groupe, chaque élément a un type dont le nom se termine par “<code class="OGC">_Type</code>”.
-Les “<code class="OGC">_PropertyType</code>” peuvent avoir un groupe d’attributs
-(notamment <code class="OGC">gco:uuidref</code> et <code>xlink:href</code>)
-que les schémas <abbr>XSD</abbr> nomment collectivement <code class="OGC">gco:ObjectReference</code>.
-Ces attributs n’ont pas de méthodes Java dédiées, mais sont accessibles indirectement via l’interface
-<code class="SIS">IdentifiedObject</code> décrite dans la sous-section suivante.
-</p>
-</aside>
-
-
-<h4 id="gco-id"><span class="section-number">5.4.1.1.</span> Identification d’instances déjà définies</h4>
-<p>
-L’élément englobant peut contenir un attribut <code class="OGC">id</code> ou <code class="OGC">uuid</code>.
-Si un de ces attributs est présent, l’élément englobé peut être complètement omis;
-il sera remplacé au moment de la lecture par l’élément référencé par l’attribut.
-Dans l’exemple suivant, la partie gauche définie un élément associé à l’identifiant “<code>mon_id</code>”,
-alors que la partie droite référence cet élément:
-</p>
-
-<div class="row-of-boxes">
-<div>
-<div class="caption">Définir un identifiant</div>
-<pre style="margin-top: 6pt"><samp class="xml"><MD_MetaData>
- <identificationInfo>
- <MD_DataIdentification id=<i>"<b>mon_id</b>"</i>>
- <code class="comment"><!-- insérer ici des propriétés filles --></code>
- </MD_DataIdentification>
- </identificationInfo>
-</MD_MetaData></samp></pre>
-</div>
-<div>
-<div class="caption">Utiliser l’identifiant défini</div>
-<pre style="margin-top: 6pt"><samp class="xml"><MD_MetaData>
- <identificationInfo xlink:href=<i>"<b>#mon_id</b>"</i>/>
-</MD_MetaData></samp></pre>
-</div>
-</div>
-
-<p>
-Le choix de l’attribut à utiliser dépend de la portée de l’élément référencé:
-</p>
-<ul>
-<li>
-<code class="OGC">id</code> n’est valide qu’à l’intérieur du document <abbr>XML</abbr>
-qui définit l’objet ainsi référencé.
-</li>
-<li>
-<code class="OGC">uuid</code> peut être valide à l’extérieur du document <abbr>XML</abbr>,
-mais quelqu’un doit maintenir une base de données fournissant les objets pour chaque UUID donnés.
-</li>
-<li>
-<code>xlink:href</code> peut faire référence à un autre document <abbr>XML</abbr> accessible sur internet.
-</li>
-</ul>
-<p>
-Dans la bibliothèque <abbr title="Spatial Information System">SIS</abbr>, tous les objets susceptibles d’être identifiés dans un document <abbr>XML</abbr>
-implémentent l’interface <code class="SIS">org.apache.sis.xml.IdentifiedObject</code>.
-Chaque instance de cette interface fournit une vue de ses identifiants sous forme de <code>Map<Citation,String></code>,
-dans lequel la clé <code class="GeoAPI">Citation</code> identifie le type d’identifiant et la valeur est l’identifiant lui-même.
-Quelques constantes représentant différents types d’identifiants sont énumérées dans <code class="SIS">IdentifierSpace</code>,
-notamment <code class="SIS">ID</code>, <code class="SIS">UUID</code> et <code class="SIS">HREF</code>.
-Chacune de ces clés peut être associée à une valeur d’un type différent (habituellement <code>String</code>,
-<code>UUID</code> ou <code>URI</code>) selon la clé.
-Par exemple le code suivant définit une valeur pour l’attribut <code class="OGC">uuid</code>:
-</p>
-
-<pre><code><b>import</b> org.apache.sis.metadata.iso.<code class="SIS">DefaultMetadata</code>;
-<b>import</b> org.apache.sis.xml.<code class="SIS">IdentifierSpace</code>;
-<b>import</b> java.util.UUID;
-
-<b>public</b> <b>class</b> MyClass {
- <b>public</b> <b>void</b> myMethod() {
- UUID identifier = UUID.randomUUID();
- <code class="SIS"><code class="SIS">DefaultMetadata</code></code> metadata = <b>new</b> <code class="SIS"><code class="SIS">DefaultMetadata</code></code>();
- metadata.<code class="SIS">getIdentifierMap().putSpecialized</code>(<code class="SIS">IdentifierSpace</code>.UUID, identifier);
- }
-}</code></pre>
-
-<p>
-Bien que ce mécanisme aie été définit dans le but de mieux supporter les représentations des
-attributs <abbr>XML</abbr> du groupe <code class="OGC">gco:ObjectIdentification</code>,
-il permet aussi de manière opportuniste de manipuler d’autres types d’identifiants.
-Par exemple les attributs <code class="GeoAPI">ISBN</code> et <code class="GeoAPI">ISSN</code>
-de <code class="GeoAPI">Citation</code> peuvent être manipulés de cette manière.
-Les méthodes de l’interface <code class="SIS">IdentifiedObject</code> fournissent donc un endroit unique
-où peuvent être manipulés tous types d’identifiants (pas seulement <abbr>XML</abbr>) associés à un objet.
-</p>
-
-
-
-<h4 id="nilReason"><span class="section-number">5.4.1.2.</span> Représentation de valeurs manquantes</h4>
-<p>
-Lorsqu’une propriété n’est pas définie, la méthode correspondante de GeoAPI retourne généralement <code>null</code>.
-Toutefois les choses se compliquent lorsque la propriété manquante est une valeur considérée comme obligatoire par le standard <abbr title="International Organization for Standardization">ISO</abbr> 19115.
-Le standard <abbr>ISO</abbr> 19139 autorise l’omission de propriétés obligatoires à la condition d’indiquer pourquoi la valeur est manquante.
-Les raisons peuvent être que la propriété ne s’applique pas (<code class="OGC">inapplicable</code>),
-que la valeur existe probablement mais n’est pas connue (<code class="OGC">unknown</code>),
-que la valeur pourrait ne pas exister (<code class="OGC">missing</code>),
-qu’elle ne peut pas être divulguée (<code class="OGC">withheld</code>), <i>etc.</i>
-La transmission de cette information nécessite l’utilisation d’un objet non-nul même lorsque la valeur est manquante.
-<abbr title="Spatial Information System">SIS</abbr> procède en retournant un objet qui, en plus d’implémenter l’interface GeoAPI attendue,
-implémente aussi l’interface <code class="SIS">org.apache.sis.xml.NilObject</code>.
-Cette interface marque les instances dont toutes les méthodes retournent une collection vide,
-un tableau vide, <code>null</code>, <code>NaN</code>, <code>0</code> ou <code>false</code>,
-dans cet ordre de préférence selon ce que les types de retours des méthodes permettent.
-Chaque instance implémentant <code class="SIS">NilObject</code> fournit une méthode
-<code class="SIS">getNilReason()</code> indiquant pourquoi l’objet est nul.
-</p>
-<p>
-Dans l’exemple suivant, la partie gauche montre un élément <code class="OGC">CI_Citation</code>
-contenant un élément <code class="OGC">CI_Series</code>, alors que dans la partie droite la série est inconnue.
-Si l’élément <code class="OGC">CI_Series</code> avait été complètement omis,
-alors la méthode <code class="GeoAPI">Citation.getSeries()</code> retournerait <code>null</code> en Java.
-Mais en présence d’un attribut <code class="OGC">nilReason</code>, l’implémentation <abbr>SIS</abbr>
-de <code class="SIS">getSeries()</code> retournera plutôt un objet implémentant à la fois les interfaces
-<code class="GeoAPI">Series</code> et <code class="SIS">NilReason</code>,
-et dont la méthode <code class="SIS">getNilReason()</code> retournera la constante <code class="SIS">UNKNOWN</code>.
-</p>
-
-<div class="row-of-boxes">
-<div>
-<div class="caption">Information présente</div>
-<pre style="margin-top: 6pt"><samp class="xml"><CI_Citation>
- <series>
- <CI_Series>
- <code class="comment"><!-- insérer ici des propriétés filles --></code>
- </CI_Series>
- </series>
-</CI_Citation></samp></pre>
-</div>
-<div>
-<div class="caption">Information absente</div>
-<pre style="margin-top: 6pt"><samp class="xml"><CI_Citation>
- <series nilReason=<i>"unknown"</i>/>
-</CI_Citation></samp></pre>
-</div>
-</div>
-</section>
-</section>
-</section>
-
-
-<section>
-<header>
-<h1 id="Utilities"><span class="section-number">6.</span> Classes et méthodes utilitaires</h1>
-</header>
-<p>
-Ce chapitre décrit des aspects de Apache <abbr title="Spatial Information System">SIS</abbr> qui s’appliquent à l’ensemble de la bibliothèque.
-La plupart de ces utilitaires ne sont pas spécifiques aux systèmes d’information spatiales.
-</p>
-
-
-
-
-
-
-<section>
-<header>
-<h2 id="ComparisonModes"><span class="section-number">6.1.</span> Modes de comparaisons des objets</h2>
-</header>
-<p>
-Il existe différentes opinions sur la façon d’implémenter la méthode <code>Object.equals(Object)</code> du Java standard.
-Selon certains, il doit être possible de comparer différentes implémentations d’une même interface ou classe de base.
-Mais cette politique nécessite que chaque interface ou classe de base définisse entièrement dans sa Javadoc les critères ou calculs
-que doivent employer les méthodes <code>equals(Object)</code> et <code>hashCode()</code> dans toutes les implémentations.
-Cette approche est choisie notamment par <code>java.util.Collection</code> et ses interfaces filles.
-La transposition de cette approche aux centaines d’interfaces de GeoAPI serait toutefois une entreprise ardue,
-qui risquerait d’être assez peu suivie par les diverses implémentations.
-En outre, elle se fait au détriment de la possibilité de prendre en compte des attributs supplémentaires dans les interfaces filles
-si cette possibilité n’a pas été spécifiée dans l’interface parente.
-Cette contrainte découle des points suivants du contrat des méthodes <code>equals(Object)</code> et <code>hashCode()</code>:
-</p>
-<ul>
-<li><code>A.equals(B)</code> implique <code>B.equals(A)</code> (symétrie);</li>
-<li><code>A.equals(B)</code> et <code>B.equals(C)</code> implique <code>A.equals(C)</code> (transitivité);</li>
-<li><code>A.equals(B)</code> implique <code>A.hashCode() == B.hashCode()</code>.</li>
-</ul>
-<p>
-Par exemple ces trois contraintes sont violées si <var>A</var> (et éventuellement <var>C</var>)
-peuvent contenir des attributs que <var>B</var> ignore.
-Pour contourner cette difficulté, une approche alternative consiste à exiger que les objets comparés par la méthode
-<code>Object.equals(Object)</code> soient exactement de la même classe, c’est-à-dire que <code>A.getClass() == B.getClass()</code>.
-Cette approche est parfois considérée contraire aux principes de la programmation orientée objets.
-Dans la pratique, pour des applications relativement complexes, l’importance accordée à ces principes dépend du contexte dans lequel les objets sont comparés:
-si les objets sont ajoutés à un <code>HashSet</code> ou utilisés comme clés dans un <code>HashMap</code>,
-alors nous avons besoin d’un strict respect du contrat de <code>equals(Object)</code> et <code>hashCode()</code>.
-Mais si le développeur compare les objets lui-même, par exemple pour vérifier si des informations qui l’intéresse ont changées,
-alors les contraintes de symétrie, transitivité ou de cohérence avec les valeurs de hachages peuvent ne pas être pertinentes pour lui.
-Des comparaisons plus permissives peuvent être souhaitables, allant parfois jusqu’à tolérer de légers écarts dans les valeurs numériques.
-</p>
-<p>
-Afin de donner une certaine flexibilité aux développeurs, un grand nombre de classes de la bibliothèque <abbr title="Spatial Information System">SIS</abbr>
-implémentent l’interface <code class="SIS">org.apache.sis.util.LenientComparable</code>, qui défini une méthode <code class="SIS">equals(Object, ComparisonMode)</code>.
-Les principaux modes de comparaisons sont:
-</p>
-<ul>
-<li><p>
-<b><code class="SIS">STRICT</code></b> — Les objets comparés doivent être de la même classe
-et tous leurs attributs strictement égaux, y compris d’éventuels attributs publics propres à l’implémentation.
-</p></li>
-<li><p>
-<b><code class="SIS">BY_CONTRACT</code></b> — Les objets comparés doivent implémenter la même interface de GeoAPI (ou tout autre standard),
-mais n’ont pas besoin d’être de la même classe d’implémentation. Seuls les attributs définis dans l’interface sont comparés;
-tout autres attributs propres à l’implémentation — même s’ils sont publics — sont ignorés.
-</p></li>
-<li><p>
-<b><code class="SIS">IGNORE_METADATA</code></b> — Comme <code class="SIS">BY_CONTRACT</code>,
-mais ne compare que les attributs qui influencent les opérations (calculs numériques ou autre) effectuées par l’objet.
-Par exemple dans un référentiel géodésique, la longitude (par rapport à Greenwich) du méridien d’origine sera pris en compte
-alors que le nom de ce méridien sera ignoré.
-</p></li>
-<li><p>
-<b><code class="SIS">APPROXIMATIVE</code></b> — Comme <code class="SIS">IGNORE_METADATA</code>,
-mais tolère de légères différences dans les valeurs numériques.
-</p></li>
-</ul>
-<p>
-Le mode par défaut, utilisé par les toutes les méthodes <code>equals(Object)</code> de <abbr>SIS</abbr>,
-est <code class="SIS">STRICT</code>. Ce mode est choisi pour une utilisation sécuritaire — notamment avec <code>HashMap</code> —
-sans nécessiter de définitions rigoureuses des méthodes <code>equals(Object)</code> et <code>hashCode()</code> dans toutes les interfaces.
-Avec ce mode, l’ordre des objets (<code>A.equals(B)</code> ou <code>B.equals(A)</code>) n’a pas d’importance.
-C’est toutefois le seul mode à offrir cette garantie.
-Dans l’expression <code>A.equals(B)</code>, le mode <code class="SIS">BY_CONTRACT</code>
-(et donc par extension tous les autres modes qui en dépendent) ne comparera que les propriétés connues de <code>A</code>,
-sans se soucier de savoir si <code>B</code> en connaît davantage.
-</p>
-</section>
-
-
-<section>
-<header>
-<h2 id="ObjectConverters"><span class="section-number">6.2.</span> Convertisseurs d’objets</h2>
-</header>
-<p>
-Il est parfois nécessaire de convertir une instance d’un type source <code><S></code> vers un type destination <code><T></code>
-alors que ces types ne sont pas connus au moment de la compilation.
-Divers projets (Apache Common Convert, Spring, <i>etc.</i>)
-ont créé leur propres interfaces pour effectuer des conversions d’objets entre des types connus seulement au moment de l’exécution.
-Les détails varient, mais ces interfaces ressemblent typiquement à l’interface suivante:
-</p>
-
-<pre><code><b>interface</b> <code class="SIS">ObjectConverter</code><S,T> { <code class="comment">// Certains projets utilisent seulement "Converter" comme nom d’interface.</code>
- T apply(S object); <code class="comment">// Un autre nom de méthode souvent utilisé par les autres projets est "convert".</code>
-}</code></pre>
-
-<p>
-Comme d’autres projets, Apache <abbr title="Spatial Information System">SIS</abbr> définit sa propre interface <code class="SIS">ObjectConverter</code>.
-La principale différence entre l’interface de <abbr>SIS</abbr> est celle que l’on retrouve dans d’autres projets
-est que <abbr>SIS</abbr> fournit des informations à propos de certaines propriétés mathématiques des convertisseurs.
-Un convertisseur de Apache <abbr>SIS</abbr> peut avoir aucune, une ou plusieurs des propriétés suivantes:
-</p>
-<dl>
-<dt><dfn>Injective</dfn></dt>
-<dd>Une fonction est injective si aucune paire de valeurs de <var>S</var> ne peut produire la même valeur de <var>T</var>.
-<div class="example"><p><b>Exemple:</b>
-la conversion <code>Integer</code> → <code>String</code> effectuée par <code>Integer.toString()</code>
-est une fonction <cite>injective</cite> car si deux valeurs de type <code>Integer</code> ne sont pas égales,
-alors il est garanti que leurs conversions produiront différentes valeurs de <code>String</code>.
-En revanche la conversion <code>String</code> → <code>Integer</code> effectuée par <code>Integer.valueOf(String)</code>
-n’est <strong>pas</strong> une fonction injective
-parce que plusieurs valeurs distinctes de type <code>String</code> peuvent être converties vers la même valeur de type <code>Integer</code>.
-Par exemple les conversions des chaînes de caractères "42", "+42" et "0042" donnent toutes la même valeur entière 42.
-</p></div>
-</dd>
-
-<dt><dfn>Surjective</dfn></dt>
-<dd>Une fonction est surjective si chaque valeur de <var>T</var> peut être produite à partir d’au moins une valeur de <var>S</var>.
-<div class="example"><p><b>Exemple:</b>
-la conversion <code>String</code> → <code>Integer</code> effectuée par <code>Integer.valueOf(String)</code>
-est une fonction <cite>surjective</cite> car chaque valeur de type <code>Integer</code> peut être produite
-à partir d’un moins une valeur de <code>String</code>.
-En revanche la conversion <code>Integer</code> → <code>String</code> effectuée par <code>Integer.toString()</code>
-n’est <strong>pas</strong> une fonction surjective parce qu’elle ne peut pas produire toutes les valeurs possibles de type <code>String</code>.
-Par exemple il n’y a aucun moyen de produire la valeur "ABC" avec la méthode <code>Integer.toString()</code>.
-</p></div>
-</dd>
-
-<dt><dfn>Bijective</dfn></dt>
-<dd>Une fonction est bijective s’il y a une relation de un-à-un entre les valeurs de <var>S</var> et de <var>T</var>.
-<div class="example"><p><b>Note:</b>
-la propriété <cite>bijective</cite> est définie ici pour des raisons de clarté,
-mais en fait n’a pas d’item explicite dans l’énumération <code>FunctionProperty</code> de Apache <abbr>SIS</abbr>.
-Ce n’est pas nécessaire puisqu’une fonction qui est à la fois <cite>injective</cite> et <cite>surjective</cite>
-est nécessairement bijective.
-</p></div>
-</dd>
-
-<dt><dfn>Préservant l’ordre</dfn></dt>
-<dd>Une fonction préserve l’ordre si toute séquence de valeurs <var>S</var> croissantes correspond à une séquence de valeurs <var>T</var> croissantes.
-<div class="example"><p><b>Exemple:</b>
-la conversion du type <code>Integer</code> vers <code>Long</code> préserve l’ordre naturel des éléments.
-Toutefois la conversion du type <code>Integer</code> vers <code>String</code> ne préserve <strong>pas</strong> l’ordre naturel,
-parce que des séquences des nombres entiers croissants ont un ordre différents
-lorsque les chaînes de caractères sont classées par ordre lexicographique.
-Par exemple 1, 2, 10 devient "1", "10", "2".
-</p></div>
-</dd>
-
-<dt><dfn>Renversant l’ordre</dfn></dt>
-<dd>Une fonction renverse l’ordre si toute séquence de valeurs <var>S</var> croissantes correspond à une séquence de valeurs <var>T</var> décroissantes.
-<div class="example"><p><b>Exemple:</b>
-une conversion qui inverse le signe des nombres.
-</p></div>
-</dd>
-</dl>
-<p>
-Ces informations peuvent sembler inutiles lorsque l’on convertit des valeurs sans tenir compte du contexte où elles apparaissent.
-Mais lorsque la valeur à convertir fait parti d’un objet plus gros, alors ces informations peuvent impacter la façon dont la valeur convertie sera utilisée.
-Par exemple la conversion d’une plage de valeurs représentée par [<var>min</var> … <var>max</var>] est directe lorsque la fonction de conversion préserve l’ordre.
-Mais si la fonction de conversion renverse l’ordre, alors les valeurs minimale et maximale doivent être interchangées.
-Par exemple si la fonction de conversion inverse le signe des valeurs, alors la plage convertie sera [-<var>max</var> … -<var>min</var>].
-Si la fonction de conversion ne préserve ni ne renverse l’ordre, alors la plage de valeurs ne peut pas être convertie du tout
-(parce qu’elle ne contiendrait plus le même ensemble de valeurs) même si les valeurs individuelles auraient pu être converties.
-</p>
-</section>
-
-
-<section>
-<header>
-<h2 id="Internationalization"><span class="section-number">6.3.</span> Internationalisation</h2>
-</header>
-<p>
-Dans une architecture où un programme exécuté sur un serveur fournit ses données à plusieurs clients,
-les conventions locales du serveur ne sont pas nécessairement les mêmes que celles des clients.
-Les conventions peuvent différer par la langue, mais aussi par la façon d’écrire les valeurs numériques
-(même entre deux pays parlant la même langue) ainsi que par le fuseau horaire.
-Pour produire des messages conformes aux conventions du client, <abbr title="Spatial Information System">SIS</abbr> emploie
-deux approches qui diffèrent par leur niveau de granularité: au niveau des messages eux-mêmes,
-ou au niveau des objets produisant les messages. L’approche utilisée détermine aussi s’il est
-possible de partager une même instance d’un objet pour toutes les langues.
-</p>
-
-<h3 id="LocalizedString"><span class="section-number">6.3.1.</span> Chaînes de caractères distinctes pour chaque conventions locales</h3>
-<p>
-Certaines classes ne sont conçues que pour fonctionner selon une convention locale à la fois.
-C’est évidemment le cas des implémentations standards de <code>java.text.Format</code>,
-puisqu’elles sont entièrement dédiées au travail d’internationalisation.
-Mais c’est aussi le cas de d’autres classes moins évidentes comme
-<code>javax.imageio.ImageReader</code> et <code>ImageWriter</code>.
-Lorsque une de ces classes est implémentée par <abbr title="Spatial Information System">SIS</abbr>,
-nous l’identifions en implémentant l’interface <code class="SIS">org.apache.sis.util.Localized</code>.
-La méthode <code class="SIS">getLocale()</code> de cette interface permet alors de déterminer
-selon quelles conventions locales l’instance produira ses messages.
-</p>
-<p>
-Une autre classe qui fournit différentes méthodes pour différentes langues est <code>java.lang.Throwable</code>.
-L’<abbr title="Application Programming Interface">API</abbr> standard du Java définie deux méthodes pour obtenir un message d’erreur:
-<code>getMessage()</code> et <code>getLocalizedMessage()</code>.
-Habituellement, ces deux méthodes retournent la même chaîne de caractères.
-Toutefois certaines exceptions lancées par Apache <abbr>SIS</abbr> peuvent utiliser différentes langues.
-La politique que <abbr>SIS</abbr> tente d’appliquer autant que possible est:
-</p>
-<ul>
-<li><code>getMessage()</code> retourne le message dans la langue par défaut de la <abbr title="Java Virtual Machine">JVM</abbr>.
-Dans une architecture client-serveur, c’est souvent la langue du système hébergeant le serveur.
-C’est la méthode recommandée pour enregistrer des messages dans le journal des événements,
-à l’intention des administrateurs systèmes.</li>
-<li><code>getLocalizedMessage()</code> retourne le message dans une langue qui dépend du contexte dans lequel l’exception s’est produite.
-C’est souvent la langue qui a été configurée pour une instance particulière de <code class="GeoAPI">Format</code> ou <code class="SIS">DataStore</code>,
-que l’on peut présumer être la langue du client se connectant au serveur.
-C’est la méthode recommandée pour afficher un message dans une fenêtre sur le poste de l’utilisateur.</li>
-</ul>
-
-<div class="example"><p><b>Exemple:</b>
-Si une erreur s’est produite alors qu’un client japonais s’est connecté à un serveur européen,
-le message fournit par <code>getLocalizedMessage()</code> pourra être envoyé à l’utilisateur au Japon
-alors que le message fournit par <code>getMessage()</code> pourra être enregistré dans le journal des événements du serveur.
-Ainsi, l’administrateur système pourra plus facilement analyser l’erreur même s’il ne connaît pas la langue du client.
-</p></div>
-<p>
-La classe utilitaire <code class="SIS">org.apache.sis.util.Exceptions</code> fournit
-des méthodes de commodité pour obtenir des messages selon des conventions locales spécifiées
-lorsque cette information est disponible.
-</p>
-
-
-
-<h3 id="InternationalString"><span class="section-number">6.3.2.</span> Instance unique pour toutes les conventions locales</h3>
-<p>
-Les <abbr title="Application Programming Interface">API</abbr> définit par <abbr title="Spatial Information System">SIS</abbr> ou hérités de GeoAPI privilégient plutôt l’utilisation du type
-<code class="GeoAPI">InternationalString</code> là où une valeur de type <code>String</code> serait susceptible d’être localisée.
-Cette approche permet de différer le processus d’internationalisation au moment d’obtenir
-une chaîne de caractères plutôt qu’au moment de construire l’objet qui les contient.
-C’est particulièrement utile pour les classes immuables qui serviront à créer des instances uniques
-indépendamment des conventions locales.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Il existe dans <abbr>SIS</abbr> une seule instance de type
-<code class="GeoAPI">OperationMethod</code> représentant la projection de Mercator, quelle que soit la langue du client.
-Mais sa méthode <code class="GeoAPI">getName()</code> fournit (indirectement)
-une instance de <code class="GeoAPI">InternationalString</code> telle que
-<code>toString(Locale.ENGLISH)</code> retourne <cite>Mercator Projection</cite>
-alors que <code>toString(Locale.FRENCH)</code> retourne <cite>Projection de Mercator</cite>.
-</p></div>
-<p>
-En définissant des objets spatiaux indépendemment des conventions locales, on réduit les risques de sur-coûts de calculs.
-Par exemple il est plus facile de détecter que deux cartes emploient la même projection cartographique si cette dernière
-est représentée par la même instance de <code class="GeoAPI">CoordinateOperation</code>, même si la projection
-porte différents noms selon les pays. En outre, certain types de <code class="GeoAPI">CoordinateOperation</code>
-peuvent nécessiter des grilles de transformation de coordonnées, ce qui accroît l’intérêt de partager une instance unique
-pour des raisons d’économie de mémoire.
-</p>
-
-
-
-<h3 id="Locale.ROOT"><span class="section-number">6.3.3.</span> Convention <code>Locale.ROOT</code></h3>
-<p>
-Toutes les méthodes <abbr title="Spatial Information System">SIS</abbr> recevant ou retournant une valeur de type <code>Locale</code>
-acceptent la valeur <code>Locale.ROOT</code>. Cette valeur est interprétée comme signifiant de ne pas localiser le texte.
-La notion de <cite>texte non-localisé</cite> est un peu fausse, puisqu’il faut bien choisir une convention de format.
-Mais cette convention, bien que très proche de l’anglais, sera généralement légèrement différente.
-Par exemple:
-</p>
-<ul>
-<li>
-Les identifiants sont écrits tels qu’ils apparaissent dans les diagrammes <abbr title="Unified Modeling Language">UML</abbr>,
-par exemple <cite>blurredImage</cite> au lieu de <cite>Blurred image</cite>.
-</li>
-<li>
-Les dates sont écrites selon le format <abbr title="International Organization for Standardization">ISO</abbr> 8601,
-qui ne correspond pas aux conventions anglaises.
-</li>
-<li>
-Les nombres sont écrits à l’aide de leurs méthodes <code>toString()</code> plutôt qu’à l’aide d’un <code>java.text.NumberFormat</code>.
-Il en résulte des différences dans le nombre de chiffres significatifs, l’utilisation de la notation exponentielle et l’absence de séparateur des milliers.
-</li>
-</ul>
-
-
-
-<h3 id="UnicodePoint"><span class="section-number">6.3.4.</span> Traitement des caractères</h3>
-<p>
-Les chaînes de caractères en Java utilisent l’encodage UTF-16. Il existe une correspondance directe
-entre les valeurs de type <code>char</code> et la très grande majorité des caractères, ce
-qui facilite l’utilisation des chaînes lorsque ces caractères suffisent.
-Mais certains caractères Unicode ne sont pas représentables par un seul <code>char</code>.
-Ces <i>caractères supplémentaires</i> comprennent certains idéogrammes,
-mais aussi des symboles routiers et géographiques dans la plage 1F680 à 1F700.
-Le support de ces caractères supplémentaires nécessite des itérations un peu plus complexes
-que le cas classique où l’on supposait une correspondance directe.
-Ainsi, au lieu de la boucle de gauche ci-dessous, les applications internationales devraient
-généralement utiliser la boucle de droite:
-</p>
-
-<div class="row-of-boxes">
-<div>
-<div class="caption">Boucle à éviter</div>
-<pre style="margin-top: 6pt"><code><b>for</b> (<b>int</b> i=0; i<string.length(); i++) {
- <b>char</b> c = string.charAt(i);
- <b>if</b> (Character.isWhitespace(c)) {
- <code class="comment">// Un espace blanc a été trouvé.</code>
- }
-}</code></pre>
-</div>
-<div>
-<div class="caption">Boucle recommandée</div>
-<pre style="margin-top: 6pt"><code><b>for</b> (<b>int</b> i=0; i<string.length();) {
- <b>int</b> c = string.codePointAt(i);
- <b>if</b> (Character.isWhitespace(c)) {
- <code class="comment">// Un espace blanc a été trouvé.</code>
- }
- i += Character.charCount(c);
-}</code></pre>
-</div>
-<div>
-<div class="caption">Exemples de caractères supplémentaires</div>
-<center>(l’affichage dépend des capacités du navigateur)</center>
-<p style="font-size: 40px">🚉 🚥 🚧 🚫
-🚯 🚸 🚺 🚹 🛄 🚭</p>
-</div>
-</div>
-
-<p>
-<abbr title="Spatial Information System">SIS</abbr> supporte les caractères supplémentaires en utilisant la boucle de droite lorsque nécessaire.
-Mais la boucle de gauche reste occasionnellement utilisée lorsqu’il est connu que les caractères recherchés ne sont
-pas des caractères supplémentaires, même si la chaîne dans laquelle on fait la recherche peut en contenir.
-</p>
-
-
-
-<h4 id="Whitespaces"><span class="section-number">6.3.4.1.</span> Interprétation des espaces blancs</h4>
-<p>
-Le Java standard fournit deux méthodes pour déterminer si un caractères est un espace blanc:
-<code>Character.isWhitespace(…)</code> et <code>Character.isSpaceChar(…)</code>.
-Ces deux méthodes diffèrent dans leurs interprétations des espaces insécables, des tabulations et des retours à la ligne.
-La première méthode est conforme à l’interprétation couramment utilisée dans des langages telles que le Java, C/C++ et <abbr>XML</abbr>,
-qui considère les tabulations et retours à la ligne comme des espaces blancs,
-alors que les espaces insécables sont interprétés comme des caractères non-blanc.
-La seconde méthode — strictement conforme à la définition Unicode — fait l’interprétation inverse.
-</p>
-<p>
-<abbr title="Spatial Information System">SIS</abbr> emploie ces deux méthodes dans des contextes différents.
-<code>isWhitespace(…)</code> est utilisée pour <em>séparer</em> les éléments d’une liste (nombres, dates, mots, <i>etc.</i>),
-tandis que <code>isSpaceChar(…)</code> est utilisée pour ignorer les espaces blancs <em>à l’intérieur</em> d’un seul élément.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Supposons une liste de nombres représentés selon les conventions françaises.
-Chaque nombre peut contenir des <em>espace insécables</em> comme séparateurs des milliers,
-tandis que les différents nombres de la liste peuvent être séparés par des espaces ordinaires, des tabulations ou des retours à la ligne.
-Pendant l’analyse d’un nombre, on veut considérer les espaces insécables comme faisant partie du nombre,
-alors qu’une tabulation ou un retour à la ligne indique très probablement une séparation entre ce nombre et le nombre suivant.
-On utilisera donc <code>isSpaceChar(…)</code>.
-Inversement, lors de la séparation des nombres de la liste, on veut considérer les tabulations et
-les retours à la ligne comme des séparateurs mais pas les espaces insécables.
-On utilisera donc <code>isWhitespace(…)</code>.
-Le rôle des espaces ordinaires, qui pourraient s’appliquer aux deux cas, doit être décidé en amont.
-</p></div>
-<p>
-Dans la pratique, cette distinction se traduit pas une utilisation de <code>isSpaceChar(…)</code>
-dans les implémentations de <code>java.text.Format</code>,
-et une utilisation de <code>isWhitespace(…)</code> dans pratiquement tout le reste
-de la bibliothèque <abbr>SIS</abbr>.
-</p>
-</section>
-</section>
-
-
-<section>
-<header>
-<h1 id="GeoAPI-details"><span class="section-number">7.</span> Relation entre GeoAPI et les standards</h1>
-</header>
-
-<p>
-Le projet GeoAPI a été brièvement présenté <a href="#GeoAPI">en introduction</a> de ce document.
-Cet annexe donne plus de détails à propos de la relation entre GeoAPI et les standards internationaux.
-L’objectif est de permettre aux développeurs qui le souhaite de prendre un peu plus d’indépendance
-par rapport aux spécificités de GeoAPI ou de l’implémentation d’Apache SIS.
-</p>
-
-
-
-
-
-
-<section>
-<header>
-<h2 id="GeoAPI-modules"><span class="section-number">7.1.</span> Les modules de GeoAPI</h2>
-</header>
-<p>
-Le projet GeoAPI est composé d’une partie standardisée (<code class="GeoAPI">geoapi</code>) et
-d’une partie expérimentale (<code class="GeoAPI">geoapi-pending</code>). Ces deux parties étant
-mutuellement exclusives, les utilisateurs doivent veiller à ne pas les mélanger dans un même projet.
-Cette séparation est garantie pour tous les projets qui ne dépendent que du dépôt central de Maven
-(incluant les versions finales de Apache <abbr title="Spatial Information System">SIS</abbr>),
-car le module <code class="GeoAPI">geoapi-pending</code> n’est jamais déployé sur ce dépôt central.
-En revanche certaines branches de développement de <abbr>SIS</abbr> peuvent dépendre de <code class="GeoAPI">geoapi-pending</code>.
-</p><p>
-Les modules de GeoAPI sont:
-</p>
-<ul>
-<li><p>
-<b><code class="GeoAPI">geoapi</code></b> — contient les interfaces couvertes par le
-<a href="https://www.ogc.org/standards/geoapi">standard GeoAPI de l’<abbr title="Open Geospatial Consortium">OGC</abbr></a>.
-Les versions finales de Apache <abbr>SIS</abbr> dépendent de ce module.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-pending</code></b> — contient une
-<em>copie</em> de toutes les interfaces du module <code class="GeoAPI">geoapi</code>
-(non pas une dépendance) avec des ajouts qui n’ont pas encore été approuvés comme un standard <abbr>OGC</abbr>.
-Certains ajouts apparaissent dans des interfaces normalement définies par le module <code class="GeoAPI">geoapi</code>,
-d’où la nécessité de les copier.
-Les branches de développement de Apache <abbr>SIS</abbr> dépendent de ce module,
-mais cette dépendance est transformée en une dépendance vers le module <code class="GeoAPI">geoapi</code>
-standard au moment de fusionner les branches avec la branche principale.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-conformance</code></b> — contient
-une suite de tests JUnit que les développeurs peuvent utiliser pour tester leurs implémentations.
-</p></li>
-<li><p>
-<b><code class="GeoAPI">geoapi-examples</code></b> — contient des
-exemples d’implémentations relativement simples. Ces exemples sont placés dans le domaine public
-afin d’encourager les utilisateurs à les copier et les adapter à leurs besoins si les services
-de Apache <abbr>SIS</abbr> ne conviennent pas.
-</p></li>
-</ul>
-</section>
-
-
-<section>
-<header>
-<h2 id="SpecificationToInterfaces"><span class="section-number">7.2.</span> Des spécifications de l’<abbr title="Open Geospatial Consortium">OGC</abbr> aux interfaces Java</h2>
-</header>
-<p>
-Les interfaces Java du projet GeoAPI sont parfois générées à partir d’autres fichiers fournis par l’<abbr>OGC</abbr>,
-tels que les fichiers <abbr title="XML Schema Definition">XSD</abbr>. Mais il y a toujours une révision manuelle, et très souvent des modifications
-par rapport aux fichiers générés par des processus automatiques.
-Il aurait été possible de générer automatiquement des interfaces Java à partir des standards de l’<abbr>OGC</abbr> à l’aide d’outils existants.
-Par exemple une des approches les plus utilisées est de transformer les <a href="http://schemas.opengis.net/gml/3.3/">schémas <abbr>XSD</abbr></a>
-en interfaces Java à l’aide de l’utilitaire en ligne de commande <code>xjc</code>.
-Cet utilitaire étant fournit avec la plupart des distributions du Java (il fait partie des outils de <a href="http://jaxb.java.net"><abbr title="Java Architecture for XML Binding">JAXB</abbr></a>),
-cette approche est choisie par plusieurs projets que l’on trouve sur internet.
-D’autres approches utilisent des outils intégrés à l’environnement de développement Eclipse,
-ou prennent comme point de départ les schémas <abbr title="Unified Modeling Language">UML</abbr> plutôt que <abbr>XSD</abbr>.
-Une approche similaire avait été tentée dans les débuts du projet GeoAPI, mais a été rapidement abandonnée.
-Nous avons privilégié une approche manuelle pour les raisons suivantes:
-</p>
-<ul>
-<li>
-<p>
-Certains schémas <abbr>XSD</abbr> sont beaucoup plus verbeux que les schémas <abbr>UML</abbr> d’origines.
-Une conversion à partir des schémas <abbr>XSD</abbr> introduit, au moins dans le cas des méta-données,
-près du double du nombre d’interfaces réellement définies par le standard, sans que cela n’apporte de nouvelles fonctionnalités.
-Les schémas <abbr>XSD</abbr> définissent aussi des attributs propres aux documents <abbr>XML</abbr>
-(<code class="OGC">id</code>, <code class="OGC">uuid</code>, <code>xlink:href</code>, <i>etc.</i>),
-qui n’existent pas dans les diagrammes <abbr>UML</abbr> originaux et que l’on ne souhaite pas forcément exposer dans un <abbr title="Application Programming Interface">API</abbr> Java.
-Une conversion à partir des schémas <abbr>UML</abbr> évite ce problème, mais les outils capable d’effectuer cette opération sont plus rares.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Les schémas <abbr>XSD</abbr> des méta-données insèrent
-un élément <code class="OGC"><cit:CI_Citation></code> à l’intérieur de <code class="OGC"><cit:citation></code>,
-un élément <code class="OGC"><cit:CI_OnlineResource></code> à l’intérieur de <code class="OGC"><cit:onlineResource></code>,
-et ainsi de suite pour la centaine de classes définies dans le standard <abbr title="International Organization for Standardization">ISO</abbr> 19115.
-Cette redondance n’est absolument pas nécessaire à un programme Java.
-</p></div>
-</li>
-<li>
-<p>
-Les standards de l’<abbr>OGC</abbr> utilisent des conventions de nommage qui sont différentes de celles du Java.
-En particulier les noms de presque toutes les classes de l’<abbr>OGC</abbr> commencent par un préfixe de deux lettres,
-comme dans <code class="OGC">MD_Identifier</code>. Ces préfixes jouent le même rôle que les noms de paquets en Java.
-GeoAPI adapte cette pratique en utilisant des noms d’interfaces sans préfixes,
-et en plaçant ces interfaces dans des paquets correspondants aux préfixes mais avec des noms plus descriptifs.
-Occasionnellement nous changeons aussi les noms, par exemple pour éviter des acronymes
-ou pour se conformer à une convention établie telle que <i>Java beans</i>.
-</p>
-<div class="example"><p><b>Exemple:</b>
-la classe <code class="OGC">MD_Identifier</code> de l’<abbr>OGC</abbr> devient
-l’interface <code class="GeoAPI">Identifier</code> dans le paquet <code class="GeoAPI">org.opengis.metadata</code>.
-La classe <code class="OGC">SC_CRS</code> de l’<abbr>OGC</abbr> devient l’interface <code class="GeoAPI">CoordinateReferenceSystem</code>,
-et l’association <code class="OGC">usesDatum</code> devient une méthode <code class="GeoAPI">getDatum()</code> — et non pas
-« <code>getUsesDatum()</code> » comme aurait fait un outil de conversion automatique.
-Nous ne laissons pas des programmes appliquer aveuglement des règles qui ignorent les conventions de la communauté dont on traduit les schémas.
-</p></div>
-</li>
-<li>
-<p>
-Les standards contiennent parfois des structures qui n’ont pas d’équivalent direct en Java,
-notamment les unions telles qu’on peut trouver en C/C++.
-La stratégie employée pour obtenir une fonctionnalité équivalente en Java dépend du contexte:
-multi-héritage des interfaces, modification de la hiérarchie ou simplement omettre l’union.
-Les décisions se font au cas-par-cas en fonction de l’analyse des besoins.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Le standard <abbr>ISO</abbr> 19111 définit différents types de systèmes de coordonnées, tels que sphérique, cylindrique, polaire ou cartésien.
-Puis, il définit différents <em>sous-ensembles</em> de ces types de systèmes de coordonnées.
-Ces sous-ensembles, représentés par des unions, servent à spécifier qu’une classe peut être associée à seulement tel ou tel type de système de coordonnées.
-Par exemple l’union des types pouvant être associés à une image, nommée <code class="OGC">CS_ImageCS</code>,
-ne contient que <code class="OGC">CS_CartesianCS</code> et <code class="OGC">CS_AffineCS</code>.
-Dans ce cas particulier, nous obtenons en Java l’effet souhaité par une modification de la hiérarchie des classes:
-nous définissons l’interface <code class="GeoAPI">CartesianCS</code> comme une spécialisation de <code class="GeoAPI">AffineCS</code>, ce qui est sémantiquement correct.
-Mais il n’est pas possible d’appliquer une stratégie similaire pour les autres unions sans violer la sémantique.
-</p></div>
-</li>
-<li>
-<p>
-Plusieurs spécifications se chevauchent. GeoAPI effectue un travail d’intégration en remplaçant certaines
-structures qui font doublons par des références vers les structures équivalentes du standard qui les définies le mieux.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Le standard <abbr>ISO</abbr> 19115, qui définit des structures de méta-données, s’aventure aussi à décrire quelques
-structures représentant les systèmes de références des coordonnées (<abbr title="Coordinate Reference System">CRS</abbr>).
-Or ces derniers sont le sujet à part entière d’un autre standard: <abbr>ISO</abbr> 19111.
-D’ailleurs le standard <abbr>ISO</abbr> 19111:2007 stipule, dans sa section 3, qu’il réutilise tous les éléments
-de <abbr>ISO</abbr> 19115 à l’exclusion de <code class="OGC">MD_CRS</code> et de ses composantes.
-Les interfaces de GeoAPI réduisent la redondance en appliquant à l’ensemble du projet l’exclusion recommandée par <abbr>ISO</abbr> 19111.
-</p></div>
-</li>
-<li>
-<p>
-Certains standards ont vu leur complexité s’accroître pour des raisons historiques plutôt que techniques,
-liées au processus de standardisation. GeoAPI réduit la dette technique en concevant les interfaces comme
-si chaque élément avait pu être intégré à sa place, sans les contraintes liées à l’ordre chronologique
-dans lequel les standards ont été publiés.
-</p>
-<div class="example"><p><b>Exemple:</b>
-Le standard <abbr>ISO</abbr> 19115-2 est une extension du standard <abbr>ISO</abbr> 19115-1 ajoutant des structures de méta-données d’images.
-Ces méta-données ont été définies dans un standard séparé parce qu’elles n’ont pas été prêtes à temps pour la publication de la première partie du standard.
-Comme il n’était pas possible, pour des raisons administratives, d’ajouter des attributs dans les classes déjà publiées,
-les nouveaux attributs ont été ajoutées dans une sous-classe portant quasiment le même nom.
-Ainsi, le standard <abbr>ISO</abbr> 19115-2 définit une classe <code class="OGC">MI_Band</code> qui étend la
-classe <code class="OGC">MD_Band</code> du standard <abbr>ISO</abbr> 19115-1 en y ajoutant les attributs qui
-auraient dû apparaître directement dans la classe parente s’ils avaient été prêts à temps.
-Dans GeoAPI, nous avons choisis de « réparer » ces anomalies en fusionnant ces deux classes en une seule interface.
-</p></div>
-</li>
-</ul>
-<p>
-Les écarts par rapport aux normes sont documentés dans chaque classe et chaque méthode concernées.
-Chaque mention d’un écart est aussi recopiée dans <a href="http://www.geoapi.org/3.0/javadoc/departures.html">une page unique</a>,
-pour donner une vue d’ensemble.
-Étant donné que ces écarts brouillent les liens qui existent entre les standards et certaines interfaces Java,
-la correspondance entre ces langages est explicitée par des annotations <code class="GeoAPI">@UML</code>
-et des fichiers de propriétés, décrits dans la section suivante.
-</p>
-
-
-
-<h3 id="UML-annotation"><span class="section-number">7.2.1.</span> Correspondances explicites entre GeoAPI et les spécifications abstraites</h3>
-<p>
-Pour chaque classe, méthode et constante définie à partir d’un standard <abbr title="Open Geospatial Consortium">OGC</abbr> ou <abbr title="International Organization for Standardization">ISO</abbr>,
-GeoAPI indique sa provenance à l’aide d’annotations définies dans le paquet <code class="GeoAPI">org.opengis.annotation</code>.
-En particulier l’annotation <code class="GeoAPI">@UML</code> indique le standard,
-le nom de l’élément dans ce standard ainsi que son niveau d’obligation.
-Par exemple dans l’extrait de code suivant, la première annotation <code class="GeoAPI">@UML</code> indique
-que l’interface Java qui la suit (<code class="GeoAPI">ProjectedCRS</code>) est définie à partir du type
-<code class="OGC">SC_ProjectedCRS</code> du standard <abbr>ISO</abbr> 19111.
-La seconde annotation <code class="GeoAPI">@UML</code>, appliquée cette fois à la méthode
-<code class="GeoAPI">getCoordinateSystem()</code>, indique que la méthode est définie
-à partir de l’association <code class="OGC">coordinateSystem</code> du standard <abbr>ISO</abbr> 19111,
-et que cette association est obligatoire — ce qui, traduit en Java, signifie que la méthode n’est
-pas autorisée à retourner la valeur <code>null</code>.
-</p>
-
-<pre><code><b>package</b> <code class="GeoAPI">org.opengis.referencing.crs</code>;
-
-<code class="comment">/**
- * A 2D coordinate reference system used to approximate the shape of the earth on a planar surface.
- */</code>
-@<code class="GeoAPI">UML</code>(specification=ISO_19111, identifier=<i>"<code class="OGC">SC_ProjectedCRS</code>"</i>)
-<b>public</b> <b>interface</b> <code class="GeoAPI">ProjectedCRS</code> <b>extends</b> <code class="GeoAPI">GeneralDerivedCRS</code> {
- <code class="comment">/**
- * Returns the coordinate system, which must be Cartesian.
- */</code>
- @<code class="GeoAPI">UML</code>(obligation=MANDATORY, specification=ISO_19111, identifier=<i>"<code class="OGC">coordinateSystem</code>"</i>)
- <code class="GeoAPI">CartesianCS</code> <code class="GeoAPI">getCoordinateSystem()</code>;
-}</code></pre>
-
-<p>
-Les méthodes d’introspections du Java permettent d’accéder à ces informations pendant l’exécution d’une application.
-C’est utile pour obtenir les noms à afficher à des utilisateurs familiers avec les normes de l’<abbr>OGC</abbr>,
-ou pour écrire des éléments dans un document <abbr>XML</abbr>.
-La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit des méthodes de commodité
-telles que <code class="SIS">getStandardName(Class)</code> pour effectuer cette opération.
-Par exemple le code suivant affichera
-« Le nom standard du type <code class="GeoAPI">org.opengis.referencing.crs.ProjectedCRS</code> est <code class="OGC">SC_ProjectedCRS</code> »:
-</p>
-
-<pre><code>Class<?> type = <code class="GeoAPI">ProjectedCRS</code>.<b>class</b>;
-System.out.println(<i>"Le nom standard du type "</i> + type.getName() + <i>" est "</i> + Types.getStandardName(type));</code></pre>
-
-<p>
-La méthode de commodité <code class="SIS">Types.forStandardName(String)</code> effectue l’opération inverse.
-Les applications qui souhaiteraient effectuer ces opérations sans utiliser les méthodes de commodités de Apache SIS
-trouveront des indications dans un <a href="#UML-annotation-geoapi">chapitre séparé</a>.
-</p>
-
-
-<h3 id="MappingToJDK"><span class="section-number">7.2.2.</span> Correspondances implicites avec le <abbr>JDK</abbr> standard</h3>
-<p>
-Certaines classes et méthodes n’ont ni annotation <code class="GeoAPI">@UML</code>,
-ni entrée dans le fichier <code class="GeoAPI">class-index.properties</code>.
-Il s’agit soit d’extensions de GeoAPI, ou soit de types définis dans d’autres bibliothèques,
-notamment le <abbr title="Java Development Kit">JDK</abbr> standard.
-Pour ce dernier cas, la correspondance avec les standards <abbr title="International Organization for Standardization">ISO</abbr> est implicite.
-Le tableau suivant décrit cette correspondance pour les types de la norme <abbr>ISO</abbr> 19103.
-Les types primitifs du Java standard sont préférés lorsqu’ils sont applicables,
-mais parfois leurs équivalents sous forme d’objets sont employés lorsqu’il est nécessaire d’autoriser des valeurs nulles.
-</p>
-<table>
-<caption>Correspondances entre <abbr>ISO</abbr> 19103 et <abbr>JDK</abbr></caption>
-<tr>
-<th>Type <abbr>ISO</abbr></th>
-<th>Type <abbr>JDK</abbr></th>
-<th>Remarques</th>
-</tr>
-<tr>
-<td class="separator" colspan="2">Nombres</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Integer</code></td>
-<td><code>int</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Integer</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Integer</code> (certains cas)</td>
-<td><code>long</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Long</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Real</code></td>
-<td><code>double</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Double</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Decimal</code></td>
-<td><code>java.math.BigDecimal</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Number</code></td>
-<td><code>java.lang.Number</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Textes</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">FreeText</code></td>
-<td>(pas d’équivalent)</td>
-<td class="leftBorder">Voir <code class="GeoAPI">org.opengis.util.InternationalString</code> ci-dessous.</td>
-</tr>
-<tr>
-<td><code class="OGC">CharacterString</code></td>
-<td><code>java.lang.String</code></td>
-<td class="leftBorder">Souvent <code class="GeoAPI">org.opengis.util.InternationalString</code> (voir ci-dessous).</td>
-</tr>
-<tr>
-<td><code class="OGC">LocalisedCharacterString</code></td>
-<td><code>java.lang.String</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Sequence<Character></code></td>
-<td><code>java.lang.CharSequence</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Character</code></td>
-<td><code>char</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Dates et heures</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Date</code></td>
-<td><code>java.util.Date</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Time</code></td>
-<td><code>java.util.Date</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">DateTime</code></td>
-<td><code>java.util.Date</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Collections</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Collection</code></td>
-<td><code>java.util.Collection</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Bag</code></td>
-<td><code>java.util.Collection</code></td>
-<td class="leftBorder">Un <code class="OGC">Bag</code> est similaire à un
-<code class="OGC">Set</code> sans la restriction d’unicité.</td>
-</tr>
-<tr>
-<td><code class="OGC">Set</code></td>
-<td><code>java.util.Set</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Sequence</code></td>
-<td><code>java.util.List</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Dictionary</code></td>
-<td><code>java.util.Map</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">KeyValuePair</code></td>
-<td><code>java.util.Map.Entry</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td class="separator" colspan="2">Énumérations</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Enumeration</code></td>
-<td><code>java.lang.Enum</code></td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">CodeList</code></td>
-<td>(pas d’équivalent)</td>
-<td class="leftBorder">Voir <code class="GeoAPI">org.opengis.util.CodeList</code> ci-dessous.</td>
-</tr>
-<tr>
-<td class="separator" colspan="2">Divers</td>
-<td class="leftBorder"/>
-</tr>
-<tr>
-<td><code class="OGC">Boolean</code></td>
-<td><code>boolean</code></td>
-<td class="leftBorder">Parfois <code>java.lang.Boolean</code> pour les attributs optionnels.</td>
-</tr>
-<tr>
-<td><code class="OGC">Any</code></td>
-<td><code>java.lang.Object</code></td>
-<td class="leftBorder"/>
-</tr>
-</table>
-
-<p>
-L’équivalent le plus direct de <code class="OGC">CharacterString</code> est la classe <code>String</code>,
-mais GeoAPI emploie souvent l’interface <code class="GeoAPI">InternationalString</code> pour permettre au client de choisir la langue.
-C’est utile par exemple sur un serveur fournissant simultanément des pages dans plusieurs langues.
-En reportant les traductions à l’utilisation des objets plutôt qu’au moment de leur création, on permet à la bibliothèque
-<abbr title="Spatial Information System">SIS</abbr> de fournir les mêmes instances de <code class="GeoAPI">Metadata</code>
-ou <code class="GeoAPI">Coverage</code> (par exemple) pour les mêmes données peu importe la langue du client.
-Les traductions peuvent être faites à la volée à l’aide d’un <code>ResourceBundle</code> de l’application,
-ou être fournies directement avec les données (cas des <code class="GeoAPI">Metadata</code> notamment).
-</p>
-<p>
-Les <code class="OGC">Enumeration</code> correspondent aux <code>Enum</code> du Java.
-Ils ont en commun de définir toutes les valeurs autorisées, sans permettre à l’utilisateur d’en ajouter.
-Les <code class="OGC">CodeList</code> sont similaires à ces énumérations, excepté que les utilisateurs peuvent y ajouter leurs propres éléments.
-Le <abbr>JDK</abbr> standard n’offrant pas cette possibilité,
-GeoAPI définit une classe abstraite <code class="GeoAPI">CodeList</code> reproduisant certaines fonctionnalités de <code>Enum</code> tout en étant extensible.
-Les extensions s’obtiennent par les méthodes statiques <code class="GeoAPI">valueOf(String)</code> qui,
-contrairement à celle de <code>Enum</code>, créeront de nouvelles instances si le nom donné ne correspond pas au nom d’une instance existante.
-</p>
-
-<pre><code>MediumName cdRom = MediumName.<code class="GeoAPI">CD_ROM;</code>
-MediumName usbKey = MediumName.<code class="GeoAPI">valueOf</code>(<i>"<code class="GeoAPI">USB_KEY</code>"</i>); <code class="comment">// Aucune constante n’existe pour cette valeur.</code>
-<b>assert</b> MediumName.<code class="GeoAPI">valueOf</code>(<i>"<code class="GeoAPI">CD_ROM</code>"</i>) == cdRom : <i>"valueOf doit retourner les constantes existantes."</i>;
-<b>assert</b> MediumName.<code class="GeoAPI">valueOf</code>(<i>"<code class="GeoAPI">USB_KEY</code>"</i>) == usbKey : <i>"valueOf doit cacher les valeurs précédemment demandées."</i>;</code></pre>
-</section>
-
-
-<section>
-<header>
-<h2 id="ReduceDependency"><span class="section-number">7.3.</span> Réduire la dépendance directe envers Apache SIS</h2>
-</header>
-<p>
-Les chapitres précédents utilisaient des méthodes statiques de Apache SIS par commodité.
-Dans certains cas, il est possible de remplacer ces méthodes statiques par du code ne faisant appel qu’à des méthodes de GeoAPI.
-Ces remplacements peuvent être intéressants pour les applications qui souhaiteraient limiter les dépendances directes envers Apache SIS,
-par exemple afin de faciliter d’éventuelles migrations entre SIS et d’autres implémentations de GeoAPI.
-Mais cela peut amener ces applications à écrire leur propres méthodes de commodités.
-Les sections suivantes donnent quelques pistes pour faciliter cette tâche.
-</p>
-
-<h3 id="UML-annotation-indep"><span class="section-number">7.3.1.</span> Correspondances entre GeoAPI et les spécifications abstraites</h3>
-<p>
-Pour chaque classe, méthode et constante définie à partir d’un standard <abbr title="Open Geospatial Consortium">OGC</abbr> ou <abbr title="International Organization for Standardization">ISO</abbr>,
-GeoAPI indique sa provenance à l’aide d’annotations définies dans le paquet <code class="GeoAPI">org.opengis.annotation</code>.
-Cette correspondante est décrite dans le <a href="#UML-annotation">chapitre à propos de GeoAPI</a>.
-Les méthodes d’introspections du Java permettent d’accéder à ces informations pendant l’exécution d’une application.
-La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit des méthodes de commodités telles que
-<code class="SIS">getStandardName(Class)</code> à cette fin, mais on peut éviter ces méthodes.
-L’exemple suivant affiche le nom standard de la méthode <code class="GeoAPI">getTitle()</code> de l’interface <code class="GeoAPI">Citation</code>:
-</p>
-
-<pre><code>Class<?> type = <code class="GeoAPI">Citation</code>.<b>class</b>;
-Method method = type.getMethod(<i>"<code class="GeoAPI">getTitle</code>"</i>, (Class<?>[]) <b>null</b>);
-<code class="GeoAPI">UML</code> annot = method.getAnnotation(<code class="GeoAPI">UML</code>.<b>class</b>);
-String id = annot.identifier();
-System.out.println(<i>"Le nom standard de la méthode "</i> + method.getName() + <i>" est "</i> + id);</code></pre>
-
-<p>
-L’opération inverse — obtenir la classe et méthode Java d’un nom standard — est un peu plus lourde.
-Elle nécessite la lecture du fichier <code class="GeoAPI">class-index.properties</code> fournit dans le
-paquet <code class="GeoAPI">org.opengis.annotation</code>. L’exemple suivant lit ce fichier juste avant
-de rechercher le nom de l’interface correspondant à <code class="OGC">CI_Citation</code>.
-Toutefois les utilisateurs sont encouragés à ne lire ce fichier qu’une fois et de conserver son contenu dans
-une cache de leur application.
-</p>
-
-<pre><code>Properties isoToGeoAPI = <b>new</b> Properties();
-<b>try</b> (InputStream in = <code class="GeoAPI">UML</code>.<b>class</b>.getResourceAsStream(<i>"<code class="GeoAPI">class-index.properties</code>"</i>)) {
- isoToGeoAPI.load(in);
-}
-String isoName = <i>"<code class="OGC">CI_Citation</code>"</i>;
-String geoName = isoToGeoAPI.getProperty(isoName);
-Class<?> type = Class.forName(geoName);
-System.out.println(<i>"L’interface GeoAPI pour le type <abbr>ISO</abbr> "</i> + isoName + <i>" est "</i> + type);</code></pre>
-
-<p>
-La méthode de commodité de <code class="SIS">org.apache.sis.util.iso.Types</code> correspondante à cette operation est
-<code class="SIS">forStandardName(String)</code>.
-</p>
-
-
-
-<h3 id="ServiceLoader"><span class="section-number">7.3.2.</span> Obtenir une implémentation des interfaces de GeoAPI</h3>
-<p>
-GeoAPI définit des fabriques (<code class="GeoAPI">Factory</code>) permettant de créer des implémentations de ses interfaces.
-Par exemple <code class="GeoAPI">DatumFactory</code> fournit des méthodes permettant de créer des instances
-implémentant les interfaces du paquet <code class="GeoAPI">org.opengis.referencing.datum</code>.
-Ces <code class="GeoAPI">Factory</code> doivent être implémentées par les bibliothèques géospatiales
-et déclarées comme <i>services</i> tel que défini par la classe standard <code>java.util.ServiceLoader</code>.
-La javadoc de <code>ServiceLoader</code> explique la façon de procéder.
-Mais pour résumer, les bibliothèques doivent créer dans le répertoire <code>META-INF/services/</code>
-un fichier dont le nom correspond au nom complet de l’interface de la fabrique
-(<code class="GeoAPI">org.opengis.referencing.datum.DatumFactory</code> dans l’exemple précédent).
-Ce fichier texte doit contenir sur une ligne le nom complet de la classe implémentant cette interface.
-Il peut s’agir d’une classe cachée aux yeux des utilisateurs, car ils n’ont pas besoin de connaître son existence.
-</p>
-<p>
-Si la bibliothèque a bien déclaré ses fabriques comme des services, alors
-les utilisateurs peuvent les obtenir en utilisant <code>ServiceLoader</code> comme dans l’exemple ci-dessous.
-Cet exemple ne prend que la première fabrique trouvée; s’il existe plusieurs fabriques,
-par exemple lorsque plusieurs bibliothèques cohabitent, alors le choix est laissé à l’utilisateur.
-</p>
-
-<pre><code><b>import</b> org.opengis.referencing.<code class="GeoAPI">GeodeticDatum</code>;
-<b>import</b> org.opengis.referencing.<code class="GeoAPI">DatumFactory</code>;
-<b>import</b> java.util.ServiceLoader;
-
-<b>public</b> <b>class</b> MyApplication {
- <b>public</b> <b>void</b> createMyDatum() {
- ServiceLoader loader = ServiceLoader.load(<code class="GeoAPI">DatumFactory</code>.<b>class</b>);
- <code class="GeoAPI">DatumFactory</code> factory = loader.iterator().next();
- <code class="GeoAPI">GeodeticDatum</code> myDatum = factory.<code class="GeoAPI">createGeodeticDatum</code>(…);
- }
-}</code></pre>
-
-
-
-<h4 id="GeoAPI-simple"><span class="section-number">7.3.2.1.</span> Fournir sa propre implémentation</h4>
-<p>
-Implémenter soi-même GeoAPI n’est pas si difficile si on se contente de besoins bien précis.
-Un développeur peut se concentrer sur une poignée d’interfaces parmi les centaines de disponibles,
-tout en disposant des autres interfaces comme autant de points d’extensions à éventuellement implémenter
-au gré des besoins.
-</p>
-<p>
-Le modèle conceptuel représenté par les interfaces est complexe. Mais cette complexité peut être réduite en combinant certaines interfaces.
-Par exemple plusieurs bibliothèques, même réputées, ne font pas la distinction entre <cite>Système de coordonnées</cite> (<abbr title="Coordinate System">CS</abbr>)
-et <cite>Système de <u>référence</u> des coordonnées</cite> (<abbr title="Coordinate Reference System">CRS</abbr>).
-Un développeur qui lui non-plus ne souhaite pas faire cette distinction peut implémenter ces deux interfaces par la même classe.
-Il peut en résulter une implémentation dont la hiérarchie de classes est plus simple que la hiérarchie des interfaces de GeoAPI.
-Le module <code class="GeoAPI">geoapi-examples</code>, discuté plus loin, fournit de telles combinaisons.
-Le tableau suivant énumère quelques combinaisons possibles:
-</p>
-<table>
-<tr>
-<th>Interface principale</th>
-<th>Interface auxiliaire</th>
-<th>Usage</th>
-</tr>
-<tr>
-<td><code class="GeoAPI">CoordinateReferenceSystem</code></td>
-<td><code class="GeoAPI">CoordinateSystem</code></td>
-<td>Description d’un système de référence spatial (<abbr>CRS</abbr>).</td>
-</tr>
-<tr>
-<td><code class="GeoAPI">GeodeticDatum</code></td>
-<td><code class="GeoAPI">Ellipsoid</code></td>
-<td>Description d’un référentiel geodétique.</td>
-</tr>
-<tr>
-<td><code class="GeoAPI">CoordinateOperation</code></td>
-<td><code class="GeoAPI">MathTransform</code></td>
-<td>Opération de transformation de coordonnées.</td>
-</tr>
-<tr>
-<td><code class="GeoAPI">IdentifiedObject</code></td>
-<td><code class="GeoAPI">ReferenceIdentifier</code></td>
-<td>Objet (typiquement un <abbr>CRS</abbr>) que l’on peut identifier par un code.</td>
-</tr>
-<tr>
-<td><code class="GeoAPI">Citation</code></td>
-<td><code class="GeoAPI">InternationalString</code></td>
-<td>Référence bibliographique composée d’un simple titre.</td>
-</tr>
-<tr>
-<td><code class="GeoAPI">GeographicBoundingBox</code></td>
-<td><code class="GeoAPI">Extent</code></td>
-<td>Étendue spatiale en degrés de longitude et de latitude.</td>
-</tr>
-<tr>
-<td><code class="GeoAPI">ParameterValue</code></td>
-<td><code class="GeoAPI">ParameterDescriptor</code></td>
-<td>Description d’un paramètre (nom, type) associée à sa valeur.</td>
-</tr>
-<tr>
-<td><code class="GeoAPI">ParameterValueGroup</code></td>
-<td><code class="GeoAPI">ParameterDescriptorGroup</code></td>
-<td>Description d’un ensemble de paramètres associés à leurs valeurs.</td>
-</tr>
-</table>
-<p id="GeoAPI-examples">
-Le module <code class="GeoAPI">geoapi-examples</code> fournit des exemples d’implémentations simples.
-Plusieurs de ces classes implémentent plus d’une interface à la fois afin de proposer un modèle conceptuel plus simple.
-La <a href="http://www.geoapi.org/geoapi-examples/apidocs/overview-summary.html">Javadoc de ce module</a>
-énumère les paquets et classes clés avec les combinaisons effectuées.
-Ce module illustre non-seulement comment GeoAPI peut-être implémenté, mais aussi comment l’implémentation
-peut être testée en utilisant <code class="GeoAPI">geoapi-conformance</code>.
-</p>
-<p>
-Bien que sa mission première soit de servir d’inspiration aux implémenteurs,
-<code class="GeoAPI">geoapi-examples</code> a tout-de-même été conçu de manière à être utilisable
-par des applications ayant des besoins très simples. Tous les exemples étant dans le domaine publique,
-les développeurs sont invités à adapter librement des copies de ces classes si nécessaires.
-Toutefois si des modifications sont apportées hors du cadre du projet GeoAPI, le bon usage veut que les copies
-modifiées soient placées dans un paquet portant un autre nom que <code class="GeoAPI">org.opengis</code>.
-</p>
-<p>
-Pour des besoins un peu plus poussés, les développeurs sont invités à examiner les modules
-<code class="GeoAPI">geoapi-proj4</code> et <code class="GeoAPI">geoapi-netcdf</code>.
-Ces deux modules fournissent des exemples d’adaptateurs permettant d’utiliser, via les interfaces de GeoAPI,
-une partie des fonctionnalités de bibliothèques externes (Proj.4 et <abbr title="Network Common Data Form">netCDF</abbr>).
-L’avantage de passer par ces interfaces est de disposer d’un modèle unifié pour exploiter deux <abbr title="Application Programming Interface">API</abbr> très différents,
-tout en se gardant la possibilité de basculer plus facilement à une autre bibliothèque si désiré.
-</p>
-</section>
-</section>
-
-
-<section>
-<header>
-<h1 id="Tests"><span class="section-number">8.</span> Les suites de tests</h1>
-</header>
-<p>
-En plus des tests propres au projet, Apache SIS utilise aussi des tests définis par GeoAPI.
-Ces tests ont l’avantage d’utiliser une source externe définissant ce que doivent être les résultats
-(par exemple les valeurs des coordonnées obtenues par une projection cartographique).
-On réduit ainsi le risque que des tests soient davantage des tests anti-régression que des tests de validité.
-Ces tests peuvent aussi être utilisés par des projets autres que Apache SIS.
-</p>
-
-
-
-
-<section>
-<header>
-<h2 id="GeoAPI-conformance"><span class="section-number">8.1.</span> Conformance avec GeoAPI</h2>
-</header>
-<p>
-Le module <code class="GeoAPI">geoapi-conformance</code> fournit des <i>validateurs</i>, une <i>suite de tests</i> JUnit
-et des <i>générateurs de rapports</i> sous forme de pages <abbr title="Hypertext Markup Language">HTML</abbr>.
-Ce module peut être utilisé avec n’importe quelle implémentation de GeoAPI.
-Pour les développeurs d’une bibliothèque géospatiale, il offre les avantages suivants:
-</p>
-<ul>
-<li>Réduire la fastidieuse tâche d’écriture des tests, en réutilisant des tests existants.</li>
-<li>Accroître la confiance en la validité des tests, du fait que <code class="GeoAPI">geoapi-conformance</code>
-a lui-même sa propre suite de tests et est appliqué à d’autres implémentations.</li>
-<li>Faciliter la comparaison avec les autres implémentations.</li>
-</ul>
-
-
-
-<h3 id="GeoAPI-validators"><span class="section-number">8.1.1.</span> Validations des instances</h3>
-<p>
-GeoAPI peut valider une instance de ses interfaces en vérifiant que certaines contraintes sont respectées.
-Certaines contraintes ne peuvent pas être exprimées dans la signature de la méthode. Ces contraintes sont
-généralement décrites textuellement dans les spécifications abstraites ou dans la javadoc.
-</p>
-<div class="example"><p><b>Exemple:</b>
-La conversion ou transformation d’une coordonnée (<code class="OGC">CC_CoordinateOperation</code>) peut nécessiter l’enchaînement de plusieurs étapes.
-Dans une telle chaîne d’opérations (<code class="OGC">CC_ConcatenatedOperation</code>),
-pour chaque étape (<code class="OGC">CC_SingleOperation</code>) le nombre de dimensions
-en sortie doit être égal au nombre de dimensions attendu en entré par l’opération suivante.
-Exprimée en langage Java, cette contrainte stipule que pour tout index
-0 < <var>i</var> < <var>n</var> où <var>n</var> est le nombre d’opérations, on a
-<code>coordOperation[i].targetDimensions == coordOperation[i-1].sourceDimensions</code>.
-</p></div>
-
-<p>
-La façon la plus simple d’effectuer ces vérifications est d’appeler les méthodes statiques
-<code class="GeoAPI">validate(…)</code> de la classe <code class="GeoAPI">org.opengis.test.Validators</code>.
-Ces méthodes portant toutes le même nom, il suffit d’écrire “<code>validate(<var>valeur</var>)</code>”
-et de laisser le compilateur choisir la méthode la plus appropriée en fonction du type d’objet donné en argument.
-Si le type d’objet n’est pas connu au moment de la compilation, alors la méthode <code class="GeoAPI">dispatch(Object)</code>
-peut se charger de rediriger le travail à la méthode <code class="GeoAPI">validate(…)</code> appropriée.
-</p>
-<p>
-Toutes les fonctions <code class="GeoAPI">validate(…)</code> suivent le fil des dépendances,
-c’est-à-dire qu’elles valideront aussi chaque composantes de l’objet à valider.
-Par exemple la validation d’un objet <code class="GeoAPI">GeographicCRS</code> impliquera
-la validation de sa composante <code class="GeoAPI">GeodeticDatum</code>, qui impliquera elle-même
-la validation de sa composante <code class="GeoAPI">Ellipsoid</code>, et ainsi de suite.
-Il est donc inutile de valider soi-même les composantes, à moins de vouloir isoler le test d’un élément souvent problématique.
-</p>
-<p>
-Par défaut, les validations sont aussi strictes que possible. Il est possible toutefois d’assouplir certaines règles.
-L’assouplissement le plus fréquent consiste à tolérer l’absence d’attributs qui étaient sensés être obligatoires.
-Cette règle et quelques autres peuvent être modifiées globalement pour tous les tests exécutés dans la
-<abbr title="Java Virtual Machine">JVM</abbr> courante comme dans l’exemple suivant:
-</p>
-
-<pre><code><b>import</b> org.opengis.metadata.<code class="GeoAPI">Metadata</code>;
-<b>import</b> org.opengis.test.<code class="GeoAPI">Validators</code>;
-<b>import</b> org.junit.Test;
-
-<b>public</b> <b>class</b> MyTest {
- <code class="comment">/*
- * Tolérer l’absence d’attributs obligatoires dans les paquets metadata et citation.
- * Cette modification s’appliquera à tous les tests exécutés dans la <abbr>JVM</abbr> courante.
- * S’il existe plusieurs classes de tests, cette initialisation peut être effectuée
- * dans une classe parente à toutes les classes de tests.
- */</code>
- <b>static</b> {
- <code class="GeoAPI">Validators</code>.<code class="GeoAPI">DEFAULT.metadata.requireMandatoryAttributes</code> = <b>false</b>;
- <code class="GeoAPI">Validators</code>.<code class="GeoAPI">DEFAULT.citation.requireMandatoryAttributes</code> = <b>false</b>;
- }
-
- @Test
- <b>public</b> <b>void</b> testMyMetadata() {
- <code class="GeoAPI">Metadata</code> myObject = …; <code class="comment">// Construisez un objet ici.</code>
- <code class="GeoAPI">Validators</code>.<code class="GeoAPI">validate</code>(myObject);
- }
-}</code></pre>
-
-<p>
-Les règles peuvent aussi être modifiées pour une suite de tests particulière,
-sans affecter la configuration par défaut de la <abbr>JVM</abbr> courante.
-Cette approche nécessite de créer une nouvelle instance du validateur dont on souhaite modifier la configuration.
-</p>
-
-<pre><code><b>import</b> org.opengis.metadata.<code class="GeoAPI">Metadata</code>;
-<b>import</b> org.opengis.test.<code class="GeoAPI">ValidatorContainer</code>;
-<b>import</b> org.junit.Test;
-
-<b>public</b> <b>class</b> MyTest {
- <b>private</b> <b>final</b> <code class="GeoAPI">ValidatorContainer</code> validators;
-
- <b>public</b> MyTest() {
- validators = <b>new</b> <code class="GeoAPI">ValidatorContainer</code>();
- validators.<code class="GeoAPI">metadata.requireMandatoryAttributes</code> = <b>false</b>;
- validators.<code class="GeoAPI">citation.requireMandatoryAttributes</code> = <b>false</b>;
- }
-
- @Test
- <b>public</b> <b>void</b> testMyMetadata() {
- <code class="GeoAPI">Metadata</code> myObject = …; <code class="comment">// Construisez un objet ici.</code>
- validators.<code class="GeoAPI">validate</code>(myObject);
- }
-}</code></pre>
-
-
-
-<h3 id="GeoAPI-tests"><span class="section-number">8.1.2.</span> Exécution des tests pré-définis</h3>
-<p>
-Des classes de tests JUnit sont définies dans des sous-paquets de <code class="GeoAPI">org.opengis.test</code>.
-Toutes les classes de tests portent un nom se terminant en "<code>Test</code>".
-GeoAPI définie aussi une classe <code class="GeoAPI">org.opengis.test.TestSuite</code> englobant l’ensemble
-des tests définis dans le module <code class="GeoAPI">geoapi-conformance</code>, mais Apache <abbr title="Spatial Information System">SIS</abbr> ne l’utilise pas.
-Apache <abbr>SIS</abbr> hérite plutôt des classes <code class="GeoAPI">*Test</code> de GeoAPI au cas-par-cas, dans les modules appropriés.
-L’exemple ci-dessous donne un exemple de test de GeoAPI personnalisé.
-La <a href="http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/referencing/ParameterizedTransformTest.html">Javadoc
-de la classe parente</a> documente en détails les tests effectués.
-Dans cet exemple, un seul test est modifié et tous les autres tests sont hérités tels quels
-(il n’est pas nécessaire de les répéter dans la sous-classe).
-Toutefois, cet exemple ajoute une vérification supplémentaire, annotée <code>@After</code>,
-qui sera exécutée après chacun des tests.
-</p>
-
-<pre><code><b>import</b> org.junit.*;
-<b>import</b> org.junit.runner.RunWith;
-<b>import</b> org.junit.runners.JUnit4;
-<b>import</b> org.opengis.test.referencing.<code class="GeoAPI">ParameterizedTransformTest</code>;
-<b>import</b> <b>static</b> org.junit.Assert.*;
-
-@RunWith(JUnit4.<b>class</b>)
-<b>public</b> <b>class</b> MyTest <b>extends</b> <code class="GeoAPI">ParameterizedTransformTest</code> {
- <code class="comment">/**
- * Spécifie aux tests de GeoAPI notre propre fabrique de transformations de coordonnées.
- * GeoAPI testera les objets construits par cette fabrique.
- */</code>
- <b>public</b> MyTest() {
- <b>super</b>(<b>new</b> MyMathTransformFactory());
- }
-
- <code class="comment">/**
- * Modifie le comportement d’un test. Cet exemple assouplit un peu les exigences de ce test,
- * en acceptant des erreurs jusqu’à 10 centimètres plutôt que la valeur par défaut de 1 cm.
- * Ce changement ne s’applique qu’à cette méthode est n’affecte pas les autres tests hérités.
- */</code>
- @Test
- @Override
- <b>public</b> <b>void</b> testLambertAzimuthalEqualArea() <b>throws</b> <code class="GeoAPI">FactoryException</code>, <code class="GeoAPI">TransformException</code> {
- <code class="GeoAPI">tolerance</code> = 0.1; <code class="comment">// Tolérance de 10 cm.</code>
- <b>super</b>.<code class="GeoAPI">testLambertAzimuthalEqualArea()</code>;
- }
-
- <code class="comment">/**
- * Vérification supplémentaire effectuée après chaque test, hérité ou non.
- * Dans cet exemple, nous vérifions que la transformation qui a été testée
- * travaillait bien dans des espaces bi-dimensionnels.
- */</code>
- @After
- <b>public</b> <b>void</b> ensureAllTransformAreMath2D() {
- assertTrue(<code class="GeoAPI">transform</code> <b>instanceof</b> <code class="GeoAPI">MathTransform2D</code>);
- }
-}</code></pre>
-</section>
-</section>
-
-
-<section>
-<header>
-<h1 id="DesignNotes"><span class="section-number">9.</span> Notes de design</h1>
-</header>
-<p>Les chapitres suivants expliquent les raisons derrières certains choix d’implémentation de Apache <abbr title="Spatial Information System">SIS</abbr>.</p>
-
-
-
-
-
-<section>
-<header>
-<h2 id="AffineTransform"><span class="section-number">9.1.</span> Utilisation des transformations affines</h2>
-</header>
-<p>
-Parmi les sortes d’opérations qu’un <abbr>SIG</abbr> doit effectuer sur les coordonnées spatiales,
-les <cite>transformations affines</cite> sont à la fois relativement simples et très fréquentes.
-Les transformations affines peuvent représenter n’importe quelle combinaison d’échelles, de cisaillements,
-de retournements, de rotations ou de translations, qui sont toutes des <cite>opérations linéaires</cite>.
-Les transformations affines ne peuvent pas effectuer des opérations <cite>non-linéaires</cite>
-telles que les projections cartographiques, mais couvrent néanmoins de nombreux autres cas:
-</p>
-<ul>
-<li>Changer l’ordre des axes, par exemple de (<var>latitude</var>, <var>longitude</var>) vers (<var>longitude</var>, <var>latitude</var>).</li>
-<li>Changer la direction des axes, par exemple l’axe des <var>y</var> qui pointe habituellement vers le bas dans les images.</li>
-<li>Changer le méridien d’origine, par exemple du méridien de <cite>Paris</cite> vers celui de <cite>Greenwich</cite>.</li>
-<li>Changer le nombre de dimensions, par exemple passer des coordonnées 3D vers 2D en supprimant la hauteur.</li>
-<li>Convertir des unités de mesures, par exemple convertir des pieds en mètres.</li>
-<li>Convertir des coordonnées pixels en coordonnées géographiques,
-par exemple la conversion exprimée dans les fichiers <code>.tfw</code> qui accompagnent certaines images <abbr>TIFF</abbr>.</li>
-<li>Prendre en charge une petite partie des projections cartographiques,
-par exemple les paramètres <cite>False Easting</cite>, <cite>False Northing</cite> et <cite>Scale factor</cite>.</li>
-</ul>
-<p>
-Les transformations affines peuvent se combiner efficacement.
-Peu importe le nombre de transformations affines que l’on enchaîne, le résultat sera exprimable par une seule transformation affine.
-Cette propriété est plus facilement visible lorsque les transformations affines sont exprimées sous forme de matrices:
-pour combiner les opérations, il suffit de multiplier les matrices.
-Le cas des conversions des coordonnées pixels en coordonnées géographiques ci-dessous donne un exemple.
-</p>
-
-<div class="example">
-<p><b>Exemple:</b>
-supposons que nous disposons d’une image dont les coordonnées des pixels sont représentées par (<var>x</var>,<var>y</var>).
-Supposons aussi que les contraintes suivantes sont respectées:
-</p>
-<ul>
-<li>Il n’y a ni cisaillement, ni rotation, ni retournement de l’image.</li>
-<li>Tous les pixels ont la même largeur en degrés de longitude.</li>
-<li>Tous les pixels ont la même hauteur en degrés de latitude.</li>
-<li>Les coordonnées des pixels commencent à (0,0) inclusivement.</li>
-</ul>
-<p>Alors la conversion des coordonnées pixels (<var>x</var>,<var>y</var>)
-vers les coordonnées géographiques (<var>λ</var>,<var>φ</var>)
-peut être représentée par les équations suivantes,
-où <var>N</var><sub><var>x</var></sub> est la largeur
-et <var>N</var><sub><var>y</var></sub> la hauteur de l’image en nombre de pixels.
-</p><p>
-
-
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<mtable>
-<mtr>
-<mtd><mo>λ</mo></mtd>
-<mtd><mo>=</mo></mtd>
-<mtd><msub><mi>S</mi><mrow>λ</mrow></msub><mi>x</mi><mo>+</mo><msub><mi>T</mi><mrow>λ</mrow></msub></mtd>
-<mtd><mtext> where </mtext></mtd>
-<mtd><msub><mi>S</mi><mrow>λ</mrow></msub></mtd>
-<mtd><mo>=</mo></mtd>
-<mtd>
-<mfrac>
-<mrow>
-<msub><mi>λ</mi><mrow>max</mrow></msub><mo>-</mo>
-<msub><mi>λ</mi><mrow>min</mrow></msub>
-</mrow><mrow>
-<msub><mi>N</mi><mrow><mi>x</mi></mrow></msub>
-</mrow>
-</mfrac>
-</mtd>
-<mtd><mtext> and </mtext></mtd>
-<mtd><msub><mi>T</mi><mrow>λ</mrow></msub></mtd>
-<mtd><mo>=</mo></mtd>
-<mtd><msub><mi>λ</mi><mrow>min</mrow></msub></mtd>
-</mtr>
-<mtr>
-<mtd><mo>φ</mo></mtd>
-<mtd><mo>=</mo></mtd>
-<mtd><msub><mi>S</mi><mrow>φ</mrow></msub><mi>y</mi><mo>+</mo><msub><mi>T</mi><mrow>φ</mrow></msub></mtd>
-<mtd><mtext> where </mtext></mtd>
-<mtd><msub><mi>S</mi><mrow>φ</mrow></msub></mtd>
-<mtd><mo>=</mo></mtd>
-<mtd>
-<mfrac>
-<mrow>
-<msub><mi>φ</mi><mrow>max</mrow></msub><mo>-</mo>
-<msub><mi>φ</mi><mrow>min</mrow></msub>
-</mrow><mrow>
-<msub><mi>N</mi><mrow><mi>y</mi></mrow></msub>
-</mrow>
-</mfrac>
-</mtd>
-<mtd><mtext> and </mtext></mtd>
-<mtd><msub><mi>T</mi><mrow>φ</mrow></msub></mtd>
-<mtd><mo>=</mo></mtd>
-<mtd><msub><mi>φ</mi><mrow>min</mrow></msub></mtd>
-</mtr>
-</mtable>
-</math>
-</p><p>
-Les équations ci-dessus peuvent être représentées sous forme de matrices comme ci-dessous:
-</p><p>
-
-
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr><mtd><mi>λ</mi></mtd></mtr>
-<mtr><mtd><mi>φ</mi></mtd></mtr>
-<mtr><mtd><mn>1</mn></mtd></mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-<mo>=</mo>
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr>
-<mtd><msub><mi>S</mi><mrow>λ</mrow></msub></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><msub><mi>T</mi><mrow>λ</mrow></msub></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><msub><mi>S</mi><mrow>φ</mrow></msub></mtd>
-<mtd><msub><mi>T</mi><mrow>φ</mrow></msub></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-</mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-<mo>×</mo>
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr><mtd><mi>x</mi></mtd></mtr>
-<mtr><mtd><mi>y</mi></mtd></mtr>
-<mtr><mtd><mn>1</mn></mtd></mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-</math>
-</p><p>
-Dans ce cas particulier, les facteurs d’échelles <var>S</var> correspondent à la taille des pixels en degrés
-et les termes de translations <var>T</var> correspondent aux coordonnées géographiques d’un coin de l’image
-(pas nécessairement le coin inférieur gauche si certains axes ont été retournés).
-Cette interprétation directe n’est possible que lorsque les contraintes énumérées plus haut sont respectées.
-Les coefficients des matrices deviennent plus complexes si l’image a un cisaillement ou une rotation,
-ou si les coordonnées des pixels ne commencent pas à (0,0).
-Toutefois il n’est pas nécessaire d’utiliser des équations plus complexes pour gérer des cas plus génériques.
-L’exemple ci-dessous prend comme point de départ la matrice d’une « conversion initiale »
-dans laquelle les coefficients <var>S</var> et <var>T</var> sont les valeurs relativement simples données ci-dessus.
-Ensuite la direction de l’axe des <var>y</var> est inversée de manière à correspondre
-à la convention habituelle des systèmes de coordonnées des images (changement 1),
-et les axes sont intervertis de manière à avoir la latitude avant la longitude (changement 2).
-Notez que les concaténations de transformations affines écrites sous forme de multiplications matricielles
-se lisent de droite à gauche:
-<var>A</var>×<var>B</var>×<var>C</var> est équivalent à d’abord appliquer l’opération <var>C</var>,
-suivit de l’opération <var>B</var> et finalement l’opération <var>A</var>.
-</p>
-<div style="display:table; margin:auto">
-<div style="display:table-row">
-<div class="caption" style="display:table-cell">Changement 2</div>
-<div class="caption" style="display:table-cell"> </div>
-<div class="caption" style="display:table-cell">Changement 1</div>
-<div class="caption" style="display:table-cell"> </div>
-<div class="caption" style="display:table-cell">Conversion initiale</div>
-<div class="caption" style="display:table-cell"> </div>
-<div class="caption" style="display:table-cell">Opérations combinées</div>
-</div>
-<div style="display:table-row">
-<div style="display:table-cell; vertical-align:middle">
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-<mtd><mn>0</mn></mtd>
-</mtr>
-<mtr>
-<mtd><mn>1</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-</mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-</math>
-</div>
-<div style="display:table-cell; vertical-align:middle; padding-left: 15px; padding-right: 15px">×</div>
-<div style="display:table-cell; vertical-align:middle">
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr>
-<mtd><mn>1</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>-1</mn></mtd>
-<msub><mi>N</mi><mrow><mi>y</mi></mrow></msub>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-</mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-</math>
-</div>
-<div style="display:table-cell; vertical-align:middle; padding-left: 15px; padding-right: 15px">×</div>
-<div style="display:table-cell; vertical-align:middle">
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr>
-<mtd><mfrac>
-<mrow>
-<msub><mi>λ</mi><mrow>max</mrow></msub><mo>-</mo>
-<msub><mi>λ</mi><mrow>min</mrow></msub>
-</mrow><mrow>
-<msub><mi>N</mi><mrow><mi>x</mi></mrow></msub>
-</mrow>
-</mfrac></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><msub><mi>λ</mi><mrow>min</mrow></msub></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mfrac>
-<mrow>
-<msub><mi>φ</mi><mrow>max</mrow></msub><mo>-</mo>
-<msub><mi>φ</mi><mrow>min</mrow></msub>
-</mrow><mrow>
-<msub><mi>N</mi><mrow><mi>y</mi></mrow></msub>
-</mrow>
-</mfrac></mtd>
-<mtd><msub><mi>φ</mi><mrow>min</mrow></msub></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-</mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-</math>
-</div>
-<div style="display:table-cell; vertical-align:middle; padding-left: 15px; padding-right: 15px">=</div>
-<div style="display:table-cell; vertical-align:middle">
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mo>-</mo><mfrac>
-<mrow>
-<msub><mi>φ</mi><mrow>max</mrow></msub><mo>-</mo>
-<msub><mi>φ</mi><mrow>min</mrow></msub>
-</mrow><mrow>
-<msub><mi>N</mi><mrow><mi>y</mi></mrow></msub>
-</mrow>
-</mfrac></mtd>
-<mtd><msub><mi>φ</mi><mrow>max</mrow></msub></mtd>
-</mtr>
-<mtr>
-<mtd><mfrac>
-<mrow>
-<msub><mi>λ</mi><mrow>max</mrow></msub><mo>-</mo>
-<msub><mi>λ</mi><mrow>min</mrow></msub>
-</mrow><mrow>
-<msub><mi>N</mi><mrow><mi>x</mi></mrow></msub>
-</mrow>
-</mfrac></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><msub><mi>λ</mi><mrow>min</mrow></msub></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-</mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-</math>
-</div>
-</div>
-</div>
-<p>
-Un principe clé est qu’il n’y a pas besoin d’écrire un code dédié à ce type d’opérations sur les axes.
-Ces opérations, et bien d’autres, sont prises en compte naturellement par l’algèbre matricielle.
-On y gagne en généricité du code et en performance.
-Apache <abbr title="Spatial Information System">SIS</abbr> suit ce principe en utilisant les tranformations affine pour toutes les opérations
-où elles peuvent s’appliquer.
-Il n’y a par exemple aucun code dédié au changement de l’ordre des ordonnées dans une coordonnée.
-</p>
-</div>
-
-<h3 id="AffineTransformAPI"><span class="section-number">9.1.1.</span> Intégration avec les bibliothèques graphiques</h3>
-<p>
-A peu près toutes les bibliothèques graphiques supportent une forme de transformation de coordonnées,
-souvent les <cite>transformations affines</cite> ou une légère généralisation.
-Chaque bibliothèque défini son propre <abbr title="Application Programming Interface">API</abbr>.
-Quelques exemples sont:
-</p>
-<table>
-<caption>Implémentations des transformations affines dans des bibliothèques graphiques</caption>
-<tr><th>Bibliothèque</th> <th>Implementation de la transformation</th> <th>Dimensions</th></tr>
-<tr><td>Java2D</td> <td><code>java.awt.geom.AffineTransform</code></td> <td>2</td></tr>
-<tr><td>Java3D</td> <td><code>javax.media.j3d.Transform3D</code></td> <td>3</td></tr>
-<tr><td>JavaFX</td> <td><code>javafx.scene.transform.Affine</code></td> <td>2 ou 3</td></tr>
-<tr><td>Java Advanced Imaging (<abbr>JAI</abbr>)</td> <td><code>javax.media.jai.PerspectiveTransform</code></td> <td>2</td></tr>
-<tr><td>Android</td> <td><code>android.graphics.Matrix</code></td> <td>2</td></tr>
-</table>
-<p>
-Toutefois dans plusieurs cas, les transformations affines sont les seuls types d’opérations supportées par la bibliothèque graphique.
-Apache <abbr title="Spatial Information System">SIS</abbr> a besoin de gérer un plus grand nombre de type d’opérations,
-parmi lesquelles les transformations affines ne sont que des cas particuliers.
-Les projections cartographiques et les changements de référentiels notamment,
-ne peuvent pas être représentés par des transformations affines.
-<abbr>SIS</abbr> a aussi besoin de transformer des points ayant un nombre arbitraire de dimensions,
-alors que les <abbr>API</abbr> cités ci-haut restreignent leur usage à un nombre fixe de dimensions.
-Pour ces raisons, <abbr>SIS</abbr> ne peut pas utiliser directement ces <abbr>API</abbr>.
-<abbr>SIS</abbr> utilise plutôt une interface plus abstraite, <code class="GeoAPI">org.opengis.referencing.transform.MathTransform</code>.
-Mais dans le cas particulier où la transformation est réellement affine, <abbr>SIS</abbr> peut essayer d’utiliser
-une implémentation existante, surtout Java2D.
-Par exemple le code suivant peut être utilisé dans les situations où un objet Java2D est désiré:
-</p>
-
-<pre><code><code class="GeoAPI">MathTransform</code> mt = ...; <code class="comment">// N’importe quelle instance créée par Apache SIS.</code>
-<b>if</b> (mt <b>instanceof</b> AffineTransform) {
- AffineTransform at = (AffineTransform) mt;
- <code class="comment">// Utiliser l’API de Java2D API à partir d’ici.</code>
-}</code></pre>
-
-<p>
-Toutefois <abbr>SIS</abbr> n’utilisera Java2D que sur une base opportuniste.
-Le forçage de type ci-haut n’est pas garantit de réussir, même si l’instance de
-<code class="GeoAPI">MathTransform</code> répond aux conditions qui devrait permettre un usage de Java2D.
-</p>
-</section>
-
-
-<section>
-<header>
-<h2 id="MatrixLibrary"><span class="section-number">9.2.</span> Particularités d’une bibliothèque de calculs matriciels pour un <abbr>SIG</abbr></h2>
-</header>
-<p>
-Les <abbr>SIG</abbr> font un usage intensif de matrices afin d’afficher leurs cartes ou transformer des coordonnées.
-On pourrait croire que le marché est suffisamment bien pourvu en excellentes bibliothèques de calculs matriciels, libres ou commerciales.
-Pourtant, les <abbr>SIG</abbr> ont des besoins spécifiques qui divergent un peu des objectifs de plusieurs bibliothèques existantes.
-Des manipulations de matrices comme celles décrites dans <a href="#AffineTransform">le chapitre sur les transformations affines</a>
-interviennent dans quasiment toutes les opérations appliquées par Apache <abbr title="Spatial Information System">SIS</abbr> sur des coordonnées.
-Mais l’analyse de ces opérations révèle quelques patterns:
-</p>
-<ul>
-<li><p>Ces matrices sont presque toujours de petites tailles, dépassant rarement 5 lignes par 5 colonnes.</p></li>
-<li><p>Les opérations matricielles « lourdes » (multiplications ou inversions de matrices) ne surviennent pas dans des endroits où la performance est importante.
-Dans la quasi-totalité des cas, elles ne sont effectuées qu’une fois pour toute, à la lecture d’un fichier,
-ou lors des étapes de préparation avant de convertir des coordonnées.
-Elles ne surviennent quasiment jamais dans la boucle convertissant chacune des coordonnées.</p></li>
-<li><p>Dans une succession de multiplications et d’inversions de matrices, les erreurs d’arrondissement s’accumulent et grandissent rapidement
-au point de se confondre avec certaines opérations légitimes, notamment les changements de référentiel.
-Ces dernières s’expriment souvent par un changement de la taille, position et orientation de l’ellipsoïde
-choisi comme approximation de la forme de la Terre.
-Or ces changements de taille s’expriment en parties par million et les rotations en arc-secondes.
-Retranscrites dans une matrice, ces valeurs sont donc assez petites.</p></li>
-<li><p>Il arrive fréquemment que des matrices s’annulent en tout ou en partie lorsqu’elles sont combinées,
-c’est-à-dire que leurs multiplications ramènent des facteurs d’échelles à 1 et des translations à 0.
-Toutefois les erreurs d’arrondissements font que les valeurs obtenues sont rarement exactes,
-mais plutôt des valeurs s’en rapprochant telles que 0,9999…97 à la place de 1.
-L’approche habituelle pour contourner ce problème est d’effectuer les comparaisons de nombres à virgule flottante en tolérant un léger écart.
-Mais il est difficile de choisir un seuil de tolérance qui gommera la plupart des erreurs d’arrondissement
-sans considérer à tord un changement de référentiel comme un artefact (voir point précédent).</p></li>
-</ul>
-<p>
-Ces points font que, pour un <abbr>SIG</abbr> comme Apache <abbr>SIS</abbr>, la précision d’une bibliothèque de calculs matriciels
-est plus importante que la performance. Paradoxalement, un bon moyen de gagner en performance est justement d’investir davantage de temps de CPU
-pour effectuer des opérations matricielles plus précises dans la phase de <em>préparation</em> (non d’<em>exécution</em>) de la transformation de coordonnées,
-car on augmente ainsi les chances de détecter correctement quelles opérations s’annulent.
-L’effort investit dans cette détection permet de sauver du temps là où ça compte: quand viendra le moment de boucler sur des millions de coordonnées à transformer.
-</p><p>
-Mais les bibliothèques dédiées aux calculs matriciels sont souvent conçues pour opérer de manière très performante
-sur des matrices de grandes tailles, ayant par exemple des milliers de lignes et colonnes.
-Elles sont ainsi conçues pour être capable de résoudre efficacement des systèmes d’équations linéaires comportant des centaines d’inconnues.
-Les problèmes qu’elles résolvent sont certes difficiles, mais assez différents de ceux qui intéressent Apache <abbr>SIS</abbr>.
-Pour cette raison, et aussi à cause d’un autre besoin spécifique détaillé dans les paragraphes suivants,
-Apache <abbr>SIS</abbr> utilise ses propres fonctions de calculs matriciels.
-Ces fonctions tentent de résoudre le problème de précision en utilisant l’arithmétique « double-double »
-(une technique permettant de simuler une précision d’environ 120 bits)
-au prix de la performance pendant une étape (la <em>préparation</em> de la transformation) où elle n’est pas jugée critique.
-</p>
-
-<h3 id="NonSquareMatrix"><span class="section-number">9.2.1.</span> Que faire des matrices qui ne sont pas carrées (et pourquoi)</h3>
-<p>
-Apache <abbr title="Spatial Information System">SIS</abbr> a très souvent besoin d’inverser des matrices,
-afin d’obtenir une conversion de coordonnées dans la direction inverse de la conversion originale.
-Mais on n’inverse habituellement que des matrices carrées.
-Or, <abbr>SIS</abbr> a besoin d’effectuer des inversions de matrices non-carrées.
-Selon que l’on ait plus de lignes ou plus de colonnes:
-</p>
-<ul>
-<li>Pour <abbr>SIS</abbr>, une matrice non-carrée est une conversion qui ajoute ou supprime une dimension aux coordonnées.</li>
-<li>Pour les bibliothèques d’algèbre linéaire, une matrice non-carrée est un système d’équations sous-déterminé ou surdéterminé.</li>
-</ul>
-<p>
-Pour mieux comprendre les difficultés que causerait une transposition trop directe des bibliothèques d’algèbre linéaire aux <abbr>SIG</abbr>,
-imaginons une conversion (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>) → (<var>φ₂</var>, <var>λ₂</var>)
-qui projetterait les points d’un espace 3D vers une surface 2D.
-Les termes <var>φ</var> sont des latitudes, <var>λ</var> des longitudes et
-(<var>φ₂</var>, <var>λ₂</var>) n’égale pas forcement (<var>φ₁</var>, <var>λ₁</var>) si la hauteur <var>h</var> n’est pas perpendiculaire à la surface.
-</p><p>
-
-
-<math xmlns="http://www.w3.org/1998/Math/MathML" alttext="MathML capable browser required" display="block">
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr><mtd><msub><mi>φ</mi><mrow><mn>2</mn></mrow></msub></mtd></mtr>
-<mtr><mtd><msub><mi>λ</mi><mrow><mn>2</mn></mrow></msub></mtd></mtr>
-<mtr><mtd><mn>1</mn></mtd></mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-<mo>=</mo>
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr>
-<mtd><mn>1</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-</mtr>
-<mtr>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>0</mn></mtd>
-<mtd><mn>1</mn></mtd>
-</mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-<mo>×</mo>
-<mrow>
-<mo>[</mo>
-<mtable>
-<mtr><mtd><msub><mi>φ</mi><mrow><mn>1</mn></mrow></msub></mtd></mtr>
-<mtr><mtd><msub><mi>λ</mi><mrow><mn>1</mn></mrow></msub></mtd></mtr>
-<mtr><mtd><mi>h</mi></mtd></mtr>
-<mtr><mtd><mn>1</mn></mtd></mtr>
-</mtable>
-<mo>]</mo>
-</mrow>
-</math>
-</p><p>
-Pour des bibliothèques d’algèbre linéaire, la matrice ci-dessus représente un système d’équations sous-déterminé, et donc insoluble.
-C’est-à-dire qu’on ne peut pas inverser cette conversion pour obtenir (<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>)
-puisqu’on ne sait pas quelle valeur donner à <var>h</var>,
-ce qui implique qu’on ne peut pas trouver (<var>φ₁</var>, <var>λ₁</var>) non-plus car ces valeurs dépendent peut-être de <var>h</var>.
-Toutefois dans le cas des <abbr>SIG</abbr>, l’axe des hauteurs ellipsoïdales <var>h</var> est perpendiculaire à la surface de l’ellipsoïde
-sur laquelle les latitudes et longitudes <em>géodésiques</em> (<var>φ</var>, <var>λ</var>) sont représentées
-(notez que cette affirmation ne s’applique pas aux latitudes et longitudes <em>géocentriques</em>).
-Cette perpendicularité rend <var>φ₁</var> et <var>λ₁</var> indépendants de <var>h</var>.
-Dans ce genre de cas, on peut encore sauver les meubles.
-</p><p>
-Apache <abbr>SIS</abbr> procède en vérifiant si les valeurs de <var>h</var> sont indépendantes des valeurs de <var>φ</var> et <var>λ</var>.
-Nous reconnaissons ce cas en vérifiant quels coefficients de la matrice ont la valeur zéro.
-Si <abbr>SIS</abbr> arrive à identifier des dimensions indépendantes,
-il peut les exclure temporairement de manière à inverser sans ambiguïté la conversion dans les dimensions restantes.
-S’il ne trouve pas de dimension indépendante, alors une exception est levée.
-Mais si une inversion a été possible, alors il reste à décider du sort des dimensions que <abbr>SIS</abbr> avait temporairement exclues.
-Par défaut, <abbr>SIS</abbr> assignera la valeur <code>NaN</code> (<cite>Not-a-Number</cite>) à ces dimensions.
-Toutefois dans le cas particulier des hauteurs ellipsoïdales <var>h</var> dans une opération (<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>),
-la valeur zéro peut aussi être appropriée dans l’hypothèse où les coordonnées sont habituellement proches de la surface de l’ellipsoïde.
-Mais dans tous les cas, le choix du coefficient à mettre à 0 ou <code>NaN</code> est basé sur la présomption que la matrice représente une transformation affine.
-Ce n’est pas une opération qui peut être effectuée sur des matrices arbitraires.
-</p><p>
-Le traitement particulier décrit ci-haut permet à Apache <abbr>SIS</abbr> de résoudre
-certains systèmes d’équations sous-déterminés que l’on rencontre couramment dans les <abbr>SIG</abbr>.
-Dans notre exemple utilisant <code>NaN</code> comme valeur par défaut, la coordonnée <var>h</var> reste inconnue
-– nous ne faisons pas surgir de l’information du néant – mais au moins les coordonnées (<var>φ</var>, <var>λ</var>) ont pu être récupérées.
-Le problème inverse, celui des systèmes surdéterminés, est plus subtil.
-Une approche classique des bibliothèques d’algèbre linéaire est de résoudre les systèmes surdéterminés par la méthode des moindres carrées.
-Transposée à notre exemple, cette approche proposerait une conversion (<var>φ₂</var>, <var>λ₂</var>, <var>h</var>) → (<var>φ₁</var>, <var>λ₁</var>)
-qui semble le meilleur compromis pour diverses valeurs de <var>φ₂</var>, <var>λ₂</var> et <var>h</var>,
-tout en n’étant (sauf cas particuliers) une solution exacte pour personne.
-De plus, les éventuelles combinaisons linéaires entre ces trois variables sont délicates compte tenu de l’hétérogénéité des unités de mesures,
-avec par exemple les <var>h</var> en mètres et (<var>φ</var>, <var>λ</var>) en degrés.
-Apache <abbr>SIS</abbr> procède plutôt comme pour les systèmes sous-déterminés: en exigeant que certaines dimensions soient indépendantes des autres,
-faute de quoi la matrice sera considérée non-inversible.
-En conséquence dans le cas des systèmes surdéterminés <abbr>SIS</abbr> refusera d’effectuer certaines opérations que les bibliothèques d’algèbre linéaire auraient faite,
-mais en cas de succès les conversions obtenues seront garanties exactes (aux erreurs d’arrondissement prêts).
-</p>
-
-<h3 id="MatrixLibrarySummary"><span class="section-number">9.2.2.</span> La bibliothèque matricielle de Apache <abbr title="Spatial Information System">SIS</abbr></h3>
-<p>
-En résumé, les besoins qui ont amené Apache <abbr>SIS</abbr> à fournir ses propres fonctions de calculs matriciels sont:
-</p>
-<ul>
-<li>Structure légère pour les petites matrices, particulièrement celles de taille 3×3.</li>
-<li>Précision accrue avec l’arithmétique « double-double », quitte à sacrifier un peu de performance dans des endroits où elle n’est pas critique.</li>
-<li>Traitement particulier de l’inversion des matrices non-carrées pour des conversions de coordonnées.</li>
-</ul>
-<p>
-Cette bibliothèque est fournie dans le paquet <code class="SIS">org.apache.sis.matrix</code> du module <code class="SIS">sis-referencing</code>.
-</p>
-</section>
-</section>
-</main>
-</body>
-</html>
\ No newline at end of file
diff --git a/coding-conventions.html b/coding-conventions.html
index 1cda975..5df22b8 100644
--- a/coding-conventions.html
+++ b/coding-conventions.html
@@ -250,7 +250,7 @@
A separated <code>@author</code> tag is added for each developer.
The intent is to allow other developers to know to who to ask questions if needed.</li>
</ul>
-<p>In addition, the <code>sis-build-helper</code> modules provides the following custom javadoc taglets:</p>
+<p>In addition, the Java code in <code>buildSrc</code> provides the following custom javadoc taglets:</p>
<table>
<thead>
<tr>
diff --git a/command-line.html b/command-line.html
index 48130da..b53f6d3 100644
--- a/command-line.html
+++ b/command-line.html
@@ -150,11 +150,14 @@
By default, the <code>lib</code> directory contains the <code>sis-*.jar</code> files together with GeoAPI, JAXB and Apache Derby dependencies.
However users can add other JAR files in that directory for the following optional dependencies:</p>
<ul>
+<li><strong>JAXB implementation —</strong>
+reading and writing XML documents requires a JAXB implementation such as Glassfish.</li>
<li><strong>UCAR netCDF library —</strong>
by default, SIS uses its own embedded netCDF reader which supports only the classical netCDF format, as standardized by OGC.
If there is a need to read files encoded in GRID or HDF formats, then copy the UCAR netCDF library in the <code>lib</code> sub-directory.
If presents, the UCAR library should be detected and used automatically when SIS cannot read a netCDF file by itself.</li>
</ul>
+<p>See <a href="https://issues.apache.org/jira/browse/SIS-545">issue SIS-545</a> for instructions on downloading optional dependencies.</p>
<h1 id="usage">Usage </h1>
<p>Invoking <code>sis</code> without argument shows a summary of available commands and all options.
For executing a command, the syntax is:</p>
diff --git a/downloads.html b/downloads.html
index c441546..f0fafab 100644
--- a/downloads.html
+++ b/downloads.html
@@ -200,7 +200,7 @@
</span></span><span class="line"><span class="cl"> <span class="nt"><dependency></span>
</span></span><span class="line"><span class="cl"> <span class="nt"><groupId></span>org.glassfish.jaxb<span class="nt"></groupId></span>
</span></span><span class="line"><span class="cl"> <span class="nt"><artifactId></span>jaxb-runtime<span class="nt"></artifactId></span>
-</span></span><span class="line"><span class="cl"> <span class="nt"><version></span>4.0.3<span class="nt"></version></span>
+</span></span><span class="line"><span class="cl"> <span class="nt"><version></span>4.0.4<span class="nt"></version></span>
</span></span><span class="line"><span class="cl"> <span class="nt"><scope></span>runtime<span class="nt"></scope></span>
</span></span><span class="line"><span class="cl"> <span class="nt"></dependency></span>
</span></span><span class="line"><span class="cl"><span class="nt"></dependencies></span></span></span></code></pre></div>
diff --git a/en/index.html b/en/index.html
deleted file mode 100644
index 3f39a0f..0000000
--- a/en/index.html
+++ /dev/null
@@ -1,10 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
- <head>
- <title>https://sis.apache.org</title>
- <link rel="canonical" href="https://sis.apache.org">
- <meta name="robots" content="noindex">
- <meta charset="utf-8">
- <meta http-equiv="refresh" content="0; url=https://sis.apache.org">
- </head>
-</html>
diff --git a/en/sitemap.xml b/en/sitemap.xml
deleted file mode 100644
index af5ab01..0000000
--- a/en/sitemap.xml
+++ /dev/null
@@ -1,178 +0,0 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?>
-<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
- xmlns:xhtml="http://www.w3.org/1999/xhtml">
- <url>
- <loc>https://sis.apache.org/downloads.html</loc>
- <lastmod>2023-10-13T00:29:13+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/team-list.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/source.html</loc>
- <lastmod>2023-10-03T18:22:46+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/coding-conventions.html</loc>
- <lastmod>2023-09-30T15:14:23+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/command-line.html</loc>
- <lastmod>2022-12-10T13:33:52+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/geodetic_paths.html</loc>
- <lastmod>2023-04-18T16:41:51+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/formats.html</loc>
- <lastmod>2022-12-26T23:26:50+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/crs_equality.html</loc>
- <lastmod>2023-04-17T12:04:43+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/faq.html</loc>
- <lastmod>2023-01-21T00:15:54+01:00</lastmod>
- <xhtml:link
- rel="alternate"
- hreflang="fr"
- href="https://sis.apache.org/fr/faq.html"
- />
- <xhtml:link
- rel="alternate"
- hreflang="en"
- href="https://sis.apache.org/faq.html"
- />
- </url><url>
- <loc>https://sis.apache.org/howto/datalake_to_datacube.html</loc>
- <lastmod>2023-09-28T11:41:25+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/export_metadata_to_xml.html</loc>
- <lastmod>2023-01-21T14:16:36+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/geographic_bounding_box.html</loc>
- <lastmod>2023-01-21T14:16:36+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/raster_values_at_geographic_coordinates.html</loc>
- <lastmod>2023-04-17T12:04:43+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/raster_values_at_pixel_coordinates.html</loc>
- <lastmod>2023-04-18T15:30:06+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/lookup_crs_urn.html</loc>
- <lastmod>2023-04-17T12:04:43+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/rasters_bigger_than_memory.html</loc>
- <lastmod>2023-04-18T12:19:12+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/epsg.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto.html</loc>
- <lastmod>2023-06-08T16:04:04+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/instantiate_utm_projection.html</loc>
- <lastmod>2023-01-21T00:15:54+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/javafx.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/fr.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/mail-lists.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/contributor.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/parallel_computation.html</loc>
- <lastmod>2023-04-18T15:30:06+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/parse_and_format_mgrs_codes.html</loc>
- <lastmod>2023-04-18T16:41:51+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/fr/faq.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/read_geotiff.html</loc>
- <lastmod>2023-09-28T11:41:25+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/read_netcdf.html</loc>
- <lastmod>2023-09-28T11:41:25+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/code-patterns.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-management.html</loc>
- <lastmod>2023-10-13T00:29:13+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes.html</loc>
- <lastmod>2023-10-02T17:36:51+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/resample_raster.html</loc>
- <lastmod>2023-04-18T15:30:06+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.1.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.2.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.3.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.4.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.5.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.6.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.7.html</loc>
- <lastmod>2023-08-19T16:17:41+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/0.8.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/1.0.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/1.1.html</loc>
- <lastmod>2023-08-19T16:17:41+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/1.2.html</loc>
- <lastmod>2022-12-12T22:21:04+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/1.3.html</loc>
- <lastmod>2023-10-02T23:31:58+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/release-notes/1.4.html</loc>
- <lastmod>2023-10-02T23:31:58+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/standards.html</loc>
- <lastmod>2023-10-18T22:37:15+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/</loc>
- <lastmod>2023-10-03T18:22:46+02:00</lastmod>
- <xhtml:link
- rel="alternate"
- hreflang="fr"
- href="https://sis.apache.org/fr/"
- />
- <xhtml:link
- rel="alternate"
- hreflang="en"
- href="https://sis.apache.org/"
- />
- </url><url>
- <loc>https://sis.apache.org/howto/transform_coordinates.html</loc>
- <lastmod>2023-01-21T00:15:54+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/transform_envelopes.html</loc>
- <lastmod>2023-08-19T16:17:41+02:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/envelopes_in_different_crs.html</loc>
- <lastmod>2023-01-21T14:16:36+01:00</lastmod>
- </url><url>
- <loc>https://sis.apache.org/howto/write_raster.html</loc>
- <lastmod>2023-09-28T11:41:25+02:00</lastmod>
- </url>
-</urlset>
diff --git a/fr/faq.html b/fr/faq.html
deleted file mode 100644
index 94bbf32..0000000
--- a/fr/faq.html
+++ /dev/null
@@ -1,412 +0,0 @@
-<!DOCTYPE html>
-<html lang="fr">
-<head>
-
-
- <title>Apache SIS - Questions fréquentes (FAQ)</title>
- <meta charset="utf-8">
- <meta name="viewport" content="width=device-width, initial-scale=1">
- <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.1.1/dist/css/bootstrap.min.css"
- rel="stylesheet" integrity="sha384-F3w7mX95PdgyTmZZMECAngseQB83DfGTowi0iMjiWaeVhAn4FJkqJByhZMI3AhiU" crossorigin="anonymous">
- <link rel="stylesheet" type="text/css" media="screen" href="../syntax.css">
- <link rel="stylesheet" type="text/css" media="screen" href="../sis.css">
-</head>
-
-<body>
-
-<nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark">
- <div class="container-fluid">
- <a class="navbar-brand" href="../index.html"> Apache SIS™</a>
- <ul class="navbar-nav me-auto mb-2 mb-md-0">
- <li class="nav-item dropdown">
- <a class="nav-link dropdown-toggle" id="menuAbout" data-bs-toggle="dropdown" aria-expanded="false">À propos de</a>
- <ul class="dropdown-menu" aria-labelledby="menuAbout">
- <li><a class="dropdown-item" href="http://www.apache.org/licenses/">Licence</a></li>
- <li><a class="dropdown-item" href="../index.html">Page d'accueil</a></li>
- </ul>
- </li>
- <li class="nav-item dropdown">
- <a class="nav-link dropdown-toggle" id="menuDocumentation" data-bs-toggle="dropdown" aria-expanded="false">Documentation</a>
- <ul class="dropdown-menu" aria-labelledby="menuDocumentation">
- <li><a class="dropdown-item" href="index.html">Sommaire</a></li>
- <li><a class="dropdown-item" href="../book/fr/developer-guide.html">Guide du développeur</a></li>
- <li><a class="dropdown-item" href="../openoffice/fr/index.html">Add-in OpenOffice</a></li>
- <li><a class="dropdown-item" href="faq.html">FAQ</a></li>
- </ul>
- </li>
- </ul>
- <ul class="navbar-nav ml-auto mb-2 mb-md-0">
- <li class="nav-item">
- <a href="https://www.apache.org/events/current-event.html">
- <img class="apache-con" src="https://www.apache.org/events/current-event-234x60.png" alt="ApacheCon"/>
- </a>
- </li>
- </ul>
- </div>
-</nav>
-
-
-<div class="row flex-nowrap">
- <div class="d-flex flex-column flex-shrink-0 p-3 text-white bg-dark" style="width:13rem; min-height:40rem">
- <ul class="nav nav-pills flex-column mb-auto position-fixed">
- <li><a class="nav-link text-white " href="index.html">Sommaire</a></li>
- <li><a class="nav-link text-white" href="http://www.apache.org/licenses/">Licence</a></li>
- <li><a class="nav-link text-white" href="../book/fr/developer-guide.html">Guide du développeur</a></li>
- <li><a class="nav-link text-white" href="../openoffice/fr/index.html">Add-in OpenOffice</a></li>
- <li><a class="nav-link active " href="faq.html">FAQ</a></li>
- <li><hr class="dropdown-divider"></li>
- <li><a class="nav-link text-white" href="../index.html">Anglais</a></li>
- </ul>
- </div>
- <div class="col">
- <main class="container">
- <article>
- <img src="../images/logo.png" class="sis-logo" align="left"/>
- <p class="page-title">Questions fréquentes (FAQ)</p>
-
- <div class="warning">
- Cette page est une traduction de la version anglaise du site d'Apache SIS.
- Ces traductions ne sont pas maintenues et peuvent être obsolètes.
- Pour des informations plus à jour, voir la version anglaise du site.
- </div>
- <p>Cette page liste quelques questions fréquemment posées à propos de Apache <abbr title="Spatial Information System">SIS</abbr>.
-Son contenu est traduit de la <a href="../faq.html">page de FAQ en anglais</a>.</p>
-<nav id="TableOfContents">
- <ul>
- <li><a href="#referencing">Géoréférencement </a>
- <ul>
- <li><a href="#referencing-intro">Pour bien commencer </a>
- <ul>
- <li><a href="#transform-point">Comment transformer une coordonnée ? </a></li>
- <li><a href="#operation-methods">Quelles projections sont supportées ? </a></li>
- <li><a href="#axisOrder">Qu’est ce que le problème d’ordre des axes et comment est il abordé ? </a></li>
- </ul>
- </li>
- <li><a href="#crs">Systèmes de Référence des Coordonnées </a>
- <ul>
- <li><a href="#UTM">Comment créer une projection de type Transverse Universelle de Mercator (UTM) ? </a></li>
- <li><a href="#google">Comment instancier une projection Google ? </a></li>
- <li><a href="#projectionKind">Comment puis-je identifier le type de projection d’un CRS ? </a></li>
- <li><a href="#lookupEPSG">Comment obtenir le code EPSG d’un CRS existant ? </a></li>
- <li><a href="#lookupURN">Comment obtenir l’URN « urn:ogc:def:crs:… » d’un CRS existant ? </a></li>
- <li><a href="#lookupReliability">Puis-je m’appuyer sur IdentifiedObjects.lookupEPSG(…) comme inverse de CRS.forCode(…) ? </a></li>
- <li><a href="#equalsIgnoreMetadata">Comment déterminer si deux CRS sont « fonctionnellement » égaux ? </a></li>
- <li><a href="#crsHashCode">Est-ce que les CRS sont utilisables comme clé dans un HashMap ? </a></li>
- </ul>
- </li>
- <li><a href="#transforms">Transformation de coordonnées </a>
- <ul>
- <li><a href="#axisOrderInTransforms">Mes coordonnées transformées sont totalement fausses ! </a></li>
- <li><a href="#projectionName">Les ordres des axes sont corrects mais les coordonnées transformées sont encore fausses. </a></li>
- <li><a href="#parameterUnits">J’ai juste utilisé le WKT d’une autorité connue et mes coordonnées transformées sont toujours fausses ! </a></li>
- <li><a href="#BursaWolf">J’ai vérifié tous ce qui est ci-dessus et j’ai toujours une erreur d’environ un kilomètre.</a></li>
- <li><a href="#slightDifferences">J’obtiens des résultats légèrement différents d’un environnement d’exécution à l’autre. </a></li>
- <li><a href="#toWGS84">Puis-je présumer qu’il est toujours possible de transformer un CRS arbitraire vers WGS84 ? </a></li>
- </ul>
- </li>
- </ul>
- </li>
- <li><a href="#metadata">Métadonnées </a>
- <ul>
- <li><a href="#metadata-implementation">Implementations sur mesures </a>
- <ul>
- <li><a href="#metadata-proxy">Mes metadonnées sont stockées dans une forme de base de données. Implémenter toute les interfaces de GeoAPI est infaisable. </a></li>
- <li><a href="#metadata-unknownClass">Je n’arrive pas à écrire mon implémentation de metadonnée </a></li>
- </ul>
- </li>
- </ul>
- </li>
- </ul>
-</nav>
-<h1 id="referencing">Géoréférencement </h1>
-<h2 id="referencing-intro">Pour bien commencer </h2>
-<h3 id="transform-point">Comment transformer une coordonnée ? </h3>
-<p>Le code java suivant projète une coordonnée de <em>World Geodetic System 1984</em> (WGS84) vers <em>WGS 84 / UTM zone 33N</em>.
-Afin de rendre cet exemple un peu plus simple, le code utilise des constantes prédéfinies dans la classe <code>CommonCRS</code>.
-Mais les applications plus avancées utilisent habituellement des codes EPSG à la place.
-Notez que les coordonnées ci-dessous sont en latitude puis longitude.</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.opengis.geometry.DirectPosition</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.opengis.referencing.crs.CoordinateReferenceSystem</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.opengis.referencing.operation.CoordinateOperation</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.opengis.referencing.operation.TransformException</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.opengis.util.FactoryException</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.apache.sis.referencing.CRS</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.apache.sis.referencing.CommonCRS</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl"><span class="kn">import</span> <span class="nn">org.apache.sis.geometry.DirectPosition2D</span><span class="o">;</span>
-</span></span><span class="line"><span class="cl">
-</span></span><span class="line"><span class="cl"><span class="kd">public</span> <span class="kd">class</span> <span class="nc">MyApp</span> <span class="o">{</span>
-</span></span><span class="line"><span class="cl"> <span class="kd">public</span> <span class="kd">static</span> <span class="kt">void</span> <span class="nf">main</span><span class="o">(</span><span class="n">String</span><span class="o">[]</span> <span class="n">args</span><span class="o">)</span> <span class="kd">throws</span> <span class="n">FactoryException</span><span class="o">,</span> <span class="n">TransformException</span> <span class="o">{</span>
-</span></span><span class="line"><span class="cl"> <span class="n">CoordinateReferenceSystem</span> <span class="n">sourceCRS</span> <span class="o">=</span> <span class="n">CommonCRS</span><span class="o">.</span><span class="na">WGS84</span><span class="o">.</span><span class="na">geographic</span><span class="o">();</span>
-</span></span><span class="line"><span class="cl"> <span class="n">CoordinateReferenceSystem</span> <span class="n">targetCRS</span> <span class="o">=</span> <span class="n">CommonCRS</span><span class="o">.</span><span class="na">WGS84</span><span class="o">.</span><span class="na">universal</span><span class="o">(</span><span class="n">40</span><span class="o">,</span> <span class="n">14</span><span class="o">);</span> <span class="c1">// Obtient la zone valide pour 14°E.
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span> <span class="n">CoordinateOperation</span> <span class="n">operation</span> <span class="o">=</span> <span class="n">CRS</span><span class="o">.</span><span class="na">findOperation</span><span class="o">(</span><span class="n">sourceCRS</span><span class="o">,</span> <span class="n">targetCRS</span><span class="o">,</span> <span class="kc">null</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl">
-</span></span><span class="line"><span class="cl"> <span class="c1">// Les lignes ci-dessus sont coûteuses et ne devraient être appelées qu’une fois pour un ensemble de points.
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span> <span class="c1">// Dans cet exemple, l’opération que l’on obtient est valide pour la zone géographique allant
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span> <span class="c1">// de 12°E à 18°E (UTM zone 33) et de 0°N à 84°N.
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span>
-</span></span><span class="line"><span class="cl"> <span class="n">DirectPosition</span> <span class="n">ptSrc</span> <span class="o">=</span> <span class="k">new</span> <span class="n">DirectPosition2D</span><span class="o">(</span><span class="n">40</span><span class="o">,</span> <span class="n">14</span><span class="o">);</span> <span class="c1">// 40°N 14°E
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span> <span class="n">DirectPosition</span> <span class="n">ptDst</span> <span class="o">=</span> <span class="n">operation</span><span class="o">.</span><span class="na">getMathTransform</span><span class="o">().</span><span class="na">transform</span><span class="o">(</span><span class="n">ptSrc</span><span class="o">,</span> <span class="kc">null</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl">
-</span></span><span class="line"><span class="cl"> <span class="n">System</span><span class="o">.</span><span class="na">out</span><span class="o">.</span><span class="na">println</span><span class="o">(</span><span class="s">"Source: "</span> <span class="o">+</span> <span class="n">ptSrc</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl"> <span class="n">System</span><span class="o">.</span><span class="na">out</span><span class="o">.</span><span class="na">println</span><span class="o">(</span><span class="s">"Target: "</span> <span class="o">+</span> <span class="n">ptDst</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl"> <span class="o">}</span>
-</span></span><span class="line"><span class="cl"><span class="o">}</span></span></span></code></pre></div>
-<h3 id="operation-methods">Quelles projections sont supportées ? </h3>
-<p>Les formules supportées par Apache <abbr title="Spatial Information System">SIS</abbr> (incluant les projections cartographiques, mais pas uniquement)
-sont listées sur la page <a href="tables/CoordinateOperationMethods.html">Coordinate Operation Methods</a>.
-La quantité de formules de projection est relativement faible,
-mais la quantité de <em>Systèmes de Coordonées projetés</em> que l’on peut construire avec est considérable.
-Par exemple, avec seulement trois familles de formules (<em>Mercator Cylindrique</em>, <em>Mercator Transverse</em> et <em>Lambert Conforme Conique</em>),
-utilisées avec différents paramètres, on peut couvrir des milliers de projections listées dans la base EPSG.</p>
-<p>Afin d’utiliser une formule de projection, il est nécessaire de connaître les paramètres de la projection.
-Par soucis de facilité d’utilisation, des milliers de projections avec des paramètres pré-définis ont un identifiant unique.
-Une source bien connue de ces définitions est la base de données EPSG, mais il existe d’autres autorités.
-Les systèmes de coordonnées prédéfinis dans Apache <abbr title="Spatial Information System">SIS</abbr> sont listés à la page
-<a href="tables/CoordinateReferenceSystems.html">Coordinate Reference Systems</a>.</p>
-<h3 id="axisOrder">Qu’est ce que le problème d’ordre des axes et comment est il abordé ? </h3>
-<p>L’ordre des axes est spécifié par l’autorité (typiquement un organisme public) qui défini les Systèmes de Référence des Coordonnées (CRS).
-L’ordre dépend du type de <abbr title="Coordinate Reference System">CRS</abbr> et du pays qui définit le <abbr title="Coordinate Reference System">CRS</abbr>.
-Dans le cas d’un <abbr title="Coordinate Reference System">CRS</abbr> géographique, l’ordre des axes (<em>latitude</em>, <em>longitude</em>) est largement répandu chez les géographes et les pilotes depuis des siècles.
-Toutefois certains développeurs de logiciels ont tendance à toujours utiliser l’ordre (<em>x</em>, <em>y</em>) pour tous les <abbr title="Coordinate Reference System">CRS</abbr>.
-Ces pratiques différentes ont conduit à des définitions contradictoires d’ordre des axes pour presque tous les <abbr title="Coordinate Reference System">CRS</abbr> de type <code>GeographicCRS</code>,
-pour certains <code>ProjectedCRS</code> de l’hémisphère sud (Afrique de sud, Australie, <em>etc.</em>) et pour certaines projections polaires entre autre.</p>
-<p>Pour chaque <abbr title="Coordinate Reference System">CRS</abbr> identifié par un code EPSG, l’ordre officiel des axes peut être vérifié avec
-le registre EPSG à l’adresse <a href="https://epsg.org/">https://epsg.org/</a>
-(à ne pas confondre avec d’autres sites ayant « epsg » dans leur nom
-mais qui sont sans aucune relation avec l’organisme en charge des définitions EPSG) :
-Cliquez sur le lien <em>« Retrieve by code »</em> et entrez le code numérique.
-Cliquez ensuite sur le lien <em>« View »</em> de la partie droite
-et cliquez sur le symbole <em>« + »</em> à gauche de <em>« Axes »</em>.</p>
-<p>Les standards <abbr title="Open Geospatial Consortium">OGC</abbr> récents stipulent que l’ordre des axes est celui défini par l’autorité.
-Les standards <abbr title="Open Geospatial Consortium">OGC</abbr> plus anciens utilisaient l’ordre des axes (<em>x</em>, <em>y</em>), ignorant la définition de l’autorité.
-Parmi les standards <abbr title="Open Geospatial Consortium">OGC</abbr> obsolètes qui utilisent un ordre des axes non-conforme,
-l’un des plus influent est la version 1 de la spécification <em>Well Known Text</em> (WKT).
-Selon ce format très utilisé, les définitions <abbr title="Well Known Text">WKT</abbr> sans éléments <code>AXIS[…]</code>
-doivent par défaut être dans l’ordre (<em>longitude</em>, <em>latitude</em>) ou (<em>x</em>, <em>y</em>).
-Dans la version 2 du format <abbr title="Well Known Text">WKT</abbr>, les éléments <code>AXIS[…]</code> ne sont plus optionnels
-et doivent contenir explicitement le sous-élément <code>ORDER[…]</code> pour appuyer l’ordre des axes à appliquer.</p>
-<p>Beaucoup de logiciels utilisent toujours l’ancien ordre des axes (<em>x</em>, <em>y</em>), parfois parce qu’il est plus simple à implémenter.
-Mais Apache <abbr title="Spatial Information System">SIS</abbr> suit l’ordre des axes <em>tel que défini par l’autorité</em> (à l’exception de la lecture de fichier <abbr title="Well Known Text">WKT</abbr> 1).
-Il permet toutefois de changer l’ordre des axes après la création d’un <abbr title="Coordinate Reference System">CRS</abbr>.
-Ce changement se fait avec le code suivant :</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="n">CoordinateReferenceSystem</span> <span class="n">crs</span> <span class="o">=</span> <span class="o">...;</span> <span class="c1">// CRS obtenu de n’importe quelle façon.
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span><span class="n">crs</span> <span class="o">=</span> <span class="n">AbstractCRS</span><span class="o">.</span><span class="na">castOrCopy</span><span class="o">(</span><span class="n">crs</span><span class="o">).</span><span class="na">forConvention</span><span class="o">(</span><span class="n">AxesConvention</span><span class="o">.</span><span class="na">RIGHT_HANDED</span><span class="o">)</span></span></span></code></pre></div>
-<h2 id="crs">Systèmes de Référence des Coordonnées </h2>
-<h3 id="UTM">Comment créer une projection de type Transverse Universelle de Mercator (UTM) ? </h3>
-<p>Si la zone UTM n’est pas connue, une façon simple est d’utiliser la méthode <code>universal(…)</code> sur l’une des constantes de <code>CommonCRS</code>.
-Cette méthode prend en argument une coordonnées géographique en (<em>latitude</em>, <em>longitude</em>) et en calcule la zone UTM correspondante.
-Voir <a href="#transform-point">le code java ci-dessus</a>.</p>
-<p>Si la zone UTM est connue, une solution est d’utiliser la fabrique des autorités « EPSG » ou « AUTO ».
-Le code EPSG de certaines projections UTM peut être déterminé comme suit,
-où <em>zone</em> est un nombre de 1 à 60 inclusif (sauf spécifié autrement) :</p>
-<ul>
-<li>WGS 84 (northern hemisphère nord): 32600 + <em>zone</em></li>
-<li>WGS 84 (hemisphère sud): 32700 + <em>zone</em></li>
-<li>WGS 72 (hemisphère nord): 32200 + <em>zone</em></li>
-<li>WGS 72 (hemisphère sud): 32300 + <em>zone</em></li>
-<li>NAD 83 (hemisphère nord): 26900 + <em>zone</em> (zone de 1 à 23)</li>
-<li>NAD 27 (hemisphère nord): 26700 + <em>zone</em> (zone de 1 à 22)</li>
-</ul>
-<p>Notez que la liste ci-dessus est incomplète. Voir la base EPSG pour d’avantages de définitions UTM
-(WGS 72BE, SIRGAS 2000, SIRGAS 1995, SAD 69, ETRS 89, <em>etc.</em>, la plupart définissent quelques zones).
-Une fois que le code EPSG de la projection UTM est déterminé, le <abbr title="Coordinate Reference System">CRS</abbr> peut être obtenu comme dans l’exemple ci-dessous:</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="kt">int</span> <span class="n">code</span> <span class="o">=</span> <span class="n">32600</span> <span class="o">+</span> <span class="n">zone</span><span class="o">;</span> <span class="c1">// Pour l’hémisphère nord WGS84
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span><span class="n">CoordinateReferenceSystem</span> <span class="n">crs</span> <span class="o">=</span> <span class="n">CRS</span><span class="o">.</span><span class="na">forCode</span><span class="o">(</span><span class="s">"EPSG:"</span> <span class="o">+</span> <span class="n">code</span><span class="o">);</span></span></span></code></pre></div>
-<h3 id="google">Comment instancier une projection Google ? </h3>
-<p>La projection Google est une projection de Mercator qui prétend utiliser un référentiel WGS84
-mais qui ignore la nature ellipsoïdale de ce référentiel et utilise un forme sphérique des formules à la place.
-Depuis la version 6.15 de la base EPSG, la façon privilégiée d’obtenir cette projection est d’utiliser la méthode <code>CRS.forCode("EPSG:3857")</code>.
-Il faut noter que l’usage de cette projection <strong>n’est pas</strong> recommandé, sauf pour des raisons de compatibilité.</p>
-<p>La définition de EPSG:3857 utilise une formule de projection nommée <em>« Popular Visualisation Pseudo Mercator »</em>.
-La base EPSG propose aussi d’autres projections qui utilisent des formules sphériques.
-Ces méthodes ont le mot « (Spherical) » dans leur nom, par exemple <em>« Mercator (Spherical) »</em>
-(qui diffère de <em>« Popular Visualisation Pseudo Mercator »</em> par l’utilisation d’une sphère de rayon plus approprié).
-Ces formules de projections peuvent être utilisées dans les définitions <em>Well Known Text</em> (WKT).</p>
-<p>Il est possible d’utiliser une formule sphérique avec une projection qui n’a pas de contrepartie sphérique
-en déclarant explicitement les paramètres <code>"semi_major"</code> et <code>"semi_minor"</code> dans la définition <abbr title="Well Known Text">WKT</abbr>.
-Ces paramètres sont généralement déduit du référentiel, mais Apache <abbr title="Spatial Information System">SIS</abbr> autorise les déclarations à surcharger ces valeurs.</p>
-<h3 id="projectionKind">Comment puis-je identifier le type de projection d’un CRS ? </h3>
-<p>Le terme « type de projection » (Mercator, Lambert Conformal, <em>etc.</em>) est appelé <em>Operation Method</em> dans la terminologie <abbr title="International Organization for Standardization">ISO</abbr> 19111.
-Une approche possible est de vérifier la valeur de <code>OperationMethod.getName()</code> et de comparer avec les noms <abbr title="Open Geospatial Consortium">OGC</abbr> et EPSG
-listés à la page <a href="tables/CoordinateOperationMethods.html">Coordinate Operation Methods</a>.</p>
-<h3 id="lookupEPSG">Comment obtenir le code EPSG d’un CRS existant ? </h3>
-<p>La propriété <em>identifiant</em> d’un <abbr title="Coordinate Reference System">CRS</abbr> peut être obtenue par la méthode <code>getIdentifiers()</code>
-qui retourne une collection de zéro ou un élément.
-Si le <abbr title="Coordinate Reference System">CRS</abbr> a été créé à partir d’un <em>Well Known Text</em> (WKT)
-et que le <abbr title="Well Known Text">WKT</abbr> se termine avec un élément <code>AUTHORITY["EPSG", "xxxx"]</code> (<abbr title="Well Known Text">WKT</abbr> version 1)
-ou <code>ID["EPSG", xxxx]</code> (<abbr title="Well Known Text">WKT</abbr> version 2,
-alors l’identifiant (un code numérique EPSG dans cet exemple) sera le <em>xxxx</em> de cet élément.
-Si le <abbr title="Coordinate Reference System">CRS</abbr> a été créé à partir de la base EPSG (par exemple avec l’appelle à <code>CRS.forCode("EPSG:xxxx")</code>),
-alors l’identifiant est le code <em>xxxx</em> donné à la méthode.
-Si le <abbr title="Coordinate Reference System">CRS</abbr> a été créé d’une autre façon, alors la collection retournée par la méthode <code>getIdentifiers()</code>
-pourra être vide dans le cas où le programme qui a créé le <abbr title="Coordinate Reference System">CRS</abbr> a aussi pris la responsabilité de fournir les identifiants.</p>
-<p>Si la collection d’identifiants est vide, la méthode la plus efficace de le corriger est de s’assurer que le <abbr title="Well Known Text">WKT</abbr>
-contient un élément <code>AUTHORITY</code> ou <code>ID</code> (en supposant que le <abbr title="Coordinate Reference System">CRS</abbr> vient d’un <abbr title="Well Known Text">WKT</abbr>).
-Si ce n’est pas possible, alors la classe <code>org.apache.sis.referencing.IdentifiedObjects</code> contient des méthodes utilitaires qui peuvent aider
-Dans l’exemple suivant, l’appel à <code>lookupEPSG(…)</code> va parcourir la base EPSG pour un <abbr title="Coordinate Reference System">CRS</abbr> équivalent (en ignorant les métadonnées).
-<em>Attention, cette recherche est sensible à l’ordre des axes.</em>
-La plupart des <abbr title="Coordinate Reference System">CRS</abbr> géographiques de la base EPSG sont déclarés avec l’ordre des axes (<em>latitude</em>, <em>longitude</em>).
-En conséquence, si le <abbr title="Coordinate Reference System">CRS</abbr> possède un ordre des axes (<em>longitude</em>, <em>latitude</em>), la recherche a toutes les chances de ne pas trouver de résultats.</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="n">CoordinateReferenceSystem</span> <span class="n">myCRS</span> <span class="o">=</span> <span class="o">...;</span>
-</span></span><span class="line"><span class="cl"><span class="n">Integer</span> <span class="n">identifier</span> <span class="o">=</span> <span class="n">IdentifiedObjects</span><span class="o">.</span><span class="na">lookupEPSG</span><span class="o">(</span><span class="n">myCRS</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl"><span class="k">if</span> <span class="o">(</span><span class="n">identifier</span> <span class="o">!=</span> <span class="kc">null</span><span class="o">)</span> <span class="o">{</span>
-</span></span><span class="line"><span class="cl"> <span class="n">System</span><span class="o">.</span><span class="na">out</span><span class="o">.</span><span class="na">println</span><span class="o">(</span><span class="s">"Le code EPSG a été trouvé : "</span> <span class="o">+</span> <span class="n">identifier</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl"><span class="o">}</span></span></span></code></pre></div>
-<h3 id="lookupURN">Comment obtenir l’URN « urn:ogc:def:crs:… » d’un CRS existant ? </h3>
-<p>L’<abbr title="Open Geospatial Consortium">OGC</abbr> définit les URN pour les identifiants de <abbr title="Coordinate Reference System">CRS</abbr>, par exemple <code>"urn:ogc:def:crs:epsg:7.1:4326"</code>
-avec <code>"7.1"</code> comme version de la base EPSG utilisée.
-Les URN peuvent ou non être présentes dans la collection d’identifiants retournée par <code>crs.getIdentifiers()</code>.
-Dans beaucoup de cas (principalement quand le <abbr title="Coordinate Reference System">CRS</abbr> provient d’un <em>Well Known Text</em>), seul des identifiants simples comme <code>"EPSG:4326"</code> sont présents.
-Une façon simple de construire une URN complète est d’utiliser le code ci-dessous.
-Cet exemple peut avoir à parcourir la base EPSG afin de trouver les informations qui n’apparaissent pas explicitement dans <code>myCRS</code>.</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="n">CoordinateReferenceSystem</span> <span class="n">myCRS</span> <span class="o">=</span> <span class="o">...;</span>
-</span></span><span class="line"><span class="cl"><span class="n">String</span> <span class="n">urn</span> <span class="o">=</span> <span class="n">IdentifiedObjects</span><span class="o">.</span><span class="na">lookupURN</span><span class="o">(</span><span class="n">myCRS</span><span class="o">);</span></span></span></code></pre></div>
-<h3 id="lookupReliability">Puis-je m’appuyer sur IdentifiedObjects.lookupEPSG(…) comme inverse de CRS.forCode(…) ? </h3>
-<p>Pour les <abbr title="Coordinate Reference System">CRS</abbr> créés avec la base EPSG, en général oui.
-À noter toutefois que <code>IdentifiedObjects.getIdentifier(…)</code> est moins riche et insensible aux détails de la définition du <abbr title="Coordinate Reference System">CRS</abbr>
-car il n’interroge pas la base de données EPSG. Il marche uniquement si le <abbr title="Coordinate Reference System">CRS</abbr> déclare explicitement son code
-ce qui est le cas des <abbr title="Coordinate Reference System">CRS</abbr> créés à partir de la base EPSG ou lus à partir d’un <em>Well Known Text</em> (WKT) avec un élément <code>AUTHORITY</code> ou <code>ID</code>.
-La méthode <code>lookupEPSG(…)</code> à l’inverse est plus robuste contre les erreurs de déclaration de code car elle compare toujours le <abbr title="Coordinate Reference System">CRS</abbr> avec celui de la base.
-Elle peut échouer s’il y a une légère différence (par exemple d’arrondie dans les paramètres)
-entre le <abbr title="Coordinate Reference System">CRS</abbr> fourni et le <abbr title="Coordinate Reference System">CRS</abbr> trouvé dans la base de données.</p>
-<h3 id="equalsIgnoreMetadata">Comment déterminer si deux CRS sont « fonctionnellement » égaux ? </h3>
-<p>Deux <abbr title="Coordinate Reference System">CRS</abbr> peuvent ne pas être considérés égaux s’ils sont associés à des métadonnées différentes
-(nom, identifiant, domaine d’usage, domaine de validité, remarque), même s’ils représentent mathématiquement le même <abbr title="Coordinate Reference System">CRS</abbr>.
-Afin de tester si deux <abbr title="Coordinate Reference System">CRS</abbr> sont fonctionnellement équivalents, utilisez la méthode <code>Utilities.equalsIgnoreMetadata(myFirstCRS, mySecondCRS)</code>.</p>
-<h3 id="crsHashCode">Est-ce que les CRS sont utilisables comme clé dans un HashMap ? </h3>
-<p>Oui, toutes les classes définies dans les paquets <code>org.apache.sis.referencing.crs</code>, <code>cs</code> et <code>datum</code>
-définissent leurs propres méthodes <code>equals(Object)</code> et <code>hashCode()</code>.
-La bibliothèque Apache <abbr title="Spatial Information System">SIS</abbr> utilise elle-même les objets <abbr title="Coordinate Reference System">CRS</abbr> dans des <code>Map</code> à des fins de cache.</p>
-<h2 id="transforms">Transformation de coordonnées </h2>
-<h3 id="axisOrderInTransforms">Mes coordonnées transformées sont totalement fausses ! </h3>
-<p>Ce cas se produit principalement à cause des ordonnées données dans le mauvais ordre.
-Les développeurs ont tendance à présumer que l’ordre des axes est (<em>x</em>, <em>y</em>) ou (<em>longitude</em>, <em>latitude</em>)
-mais les géographes et pilotes utilisent l’ordre (<em>latitude</em>, <em>longitude</em>) depuis des siècles
-et la base de données EPSG définit les systèmes de coordonnées de cette façon.
-Si une transformation de coordonnées semble produire des valeurs complètement fausses,
-la première chose à faire est d’afficher les <abbr title="Coordinate Reference System">CRS</abbr> source et cible :</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="n">System</span><span class="o">.</span><span class="na">out</span><span class="o">.</span><span class="na">println</span><span class="o">(</span><span class="n">sourceCRS</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl"><span class="n">System</span><span class="o">.</span><span class="na">out</span><span class="o">.</span><span class="na">println</span><span class="o">(</span><span class="n">targetCRS</span><span class="o">);</span></span></span></code></pre></div>
-<p>Une attention particulière doit être portée à l’ordre des éléments <code>AXIS</code>.
-Dans l’exemple ci-dessous, le <abbr title="Coordinate Reference System">CRS</abbr> stipule clairement l’ordre (<em>latitude</em>, <em>longitude</em>) :</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">GeodeticCRS["WGS 84",
-</span></span><span class="line"><span class="cl"> Datum["World Geodetic System 1984",
-</span></span><span class="line"><span class="cl"> Ellipsoid["WGS 84", 6378137.0, 298.257223563]],
-</span></span><span class="line"><span class="cl"> CS[ellipsoidal, 2],
-</span></span><span class="line"><span class="cl"> Axis["Geodetic latitude (Lat)", north],
-</span></span><span class="line"><span class="cl"> Axis["Geodetic longitude (Lon)", east],
-</span></span><span class="line"><span class="cl"> Unit["degree", 0.017453292519943295]]</span></span></code></pre></div>
-<p>Si l’ordre (<em>longitude</em>, <em>latitude</em>) est voulu, Apache <abbr title="Spatial Information System">SIS</abbr> est capable de le forcer comme décrit <a href="#axisOrder">ci-dessus</a>.</p>
-<h3 id="projectionName">Les ordres des axes sont corrects mais les coordonnées transformées sont encore fausses. </h3>
-<p>Vérifiez que se sont les bonnes projections qui sont utilisées. Certains noms sont déroutants.
-Par exemple <em>« Oblique Mercator »</em> et <em>« Hotine Oblique Mercator »</em> (dans l’autorité EPSG) sont deux projections différentes.
-Mais <em>« Oblique Mercator »</em> (sans le Hotine) de l’autorité EPSG est aussi appelée <em>« Hotine Oblique Mercator Azimuth Center »</em> par ESRI.
-tandis que <em>« Hotine Oblique Mercator »</em> (de l’autorité EPSG) est appelée <em>« Hotine Oblique Mercator Azimuth Natural Origin »</em> par ESRI.</p>
-<p>La projection <em>« Oblique Stereographic »</em> (de l’autorité EPSG) est appelée <em>« Double Stereographic »</em> par ESRI.
-ESRI définit aussi une projection <em>« Stereographic »</em> qui est en réalité une projection oblique comme la précédente mais avec des formules différentes.</p>
-<h3 id="parameterUnits">J’ai juste utilisé le WKT d’une autorité connue et mes coordonnées transformées sont toujours fausses ! </h3>
-<p>La version 1 de la spécification <em>Well Known Text</em> (WKT) a été interprétée de différentes façons en fonction des implémentations logicielles.
-Un problème subtil vient des unités d’angles pour le méridien d’origine et les paramètres de projection.
-La spécification <abbr title="Well Known Text">WKT</abbr> 1 stipule clairement : <em>« Si l’élément <code>PRIMEM</code> apparaît dans <code>GEOGCS</code>,
-alors l’unité des longitudes doit correspondre à celle du système de coordonnées géographiques »</em> (traduction libre de <abbr title="Open Geospatial Consortium">OGC</abbr> 01-009).
-Toutefois ESRI et GDAL entres autres utilisent inconditionnellement des degrés décimaux, ignorant cette partie de la spécification <abbr title="Well Known Text">WKT</abbr> 1
-(note: cette remarque ne s’applique pas à <abbr title="Well Known Text">WKT</abbr> 2).
-Ce problème peut être identifié en inspectant l’extrait de <abbr title="Well Known Text">WKT</abbr> suivant :</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">PROJCS["Lambert II étendu",
-</span></span><span class="line"><span class="cl"> GEOGCS["Nouvelle Triangulation Française", ...,
-</span></span><span class="line"><span class="cl"> PRIMEM["Paris", 2.337229167],
-</span></span><span class="line"><span class="cl"> UNIT["grad", 0.01570796326794897]]
-</span></span><span class="line"><span class="cl"> PROJECTION["Lambert_Conformal_Conic_1SP"],
-</span></span><span class="line"><span class="cl"> PARAMETER["latitude_of_origin", 46.8], ...]</span></span></code></pre></div>
-<p>Le méridien d’origine de Paris est situé à approximativement 2,597 gradians de Greenwich, ce qui correspond à 2,337 degrés.
-À partir de ce fait, on peut voir que le <abbr title="Well Known Text">WKT</abbr> ci-dessus utilise des degrés malgré la déclaration de l’unité <code>UNIT["grad"]</code>.
-Cette erreur s’applique aussi aux valeurs des paramètres, qui déclarent 46,8° dans l’exemple ci-dessus alors que la valeur officielle est de 52 gradians.
-Par défaut, Apache <abbr title="Spatial Information System">SIS</abbr> interprète ces valeurs angulaires en gradians quand il lit ce type de <abbr title="Well Known Text">WKT</abbr>, ce qui produit de grandes erreurs.
-Afin d’obtenir le résultat attendu, il est possible de :</p>
-<ul>
-<li>
-<p>Remplacer <code>UNIT["grad", 0.01570796326794897]</code> par <code>UNIT["degree", 0.017453292519943295]</code>,
-ce qui va assurer que Apache <abbr title="Spatial Information System">SIS</abbr>, GDAL et ESRI comprennent ce <abbr title="Well Known Text">WKT</abbr> 1 de la même manière.</p>
-</li>
-<li>
-<p>Ou demander explicitement à Apache <abbr title="Spatial Information System">SIS</abbr> de lire le <abbr title="Well Known Text">WKT</abbr> en utilisant les conventions ESRI ou GDAL,
-avec l’énumération <code>Convention.WKT1_COMMON_UNITS</code> pour la valeur de <code>WKTFormat</code> dans le paquet <code>org.apache.sis.io.wkt</code>.</p>
-</li>
-</ul>
-<p>Il est à noter que le standard GeoPackage requiert explicitement la conformité avec <abbr title="Open Geospatial Consortium">OGC</abbr> 01-009
-et que le nouveau standard <abbr title="Well Known Text">WKT</abbr> 2 suit aussi l’interprétation de <abbr title="Open Geospatial Consortium">OGC</abbr> 01-009.
-Le comportement par défaut de Apache <abbr title="Spatial Information System">SIS</abbr> est cohérent avec ces deux standards.</p>
-<h3 id="BursaWolf">J’ai vérifié tous ce qui est ci-dessus et j’ai toujours une erreur d’environ un kilomètre.</h3>
-<p>Les systèmes de coordonnées (CRS) font une approximation de la forme de la terre avec une ellipsoïde.
-Différentes ellipsoïdes (en réalité différents <em>référentiels</em>) sont utilisées dans différents pays du monde et à différents moments de l’histoire.
-Quand on transforme des coordonnées entre deux <abbr title="Coordinate Reference System">CRS</abbr> utilisant le même référentiel, aucun paramètre Bursa-Wolf n’est requis.
-Mais quand la transformation implique un changement de référentiel, le module de géoréférencement à besoin d’informations sur la manière d’effectuer ce changement.</p>
-<p>Il y a plusieurs façon de spécifier comment appliquer un changement de référentiel, et la plupart sont seulement approximatives.
-La méthode de Bursa-Wolf est l’une d’elle, mais pas la seule. Toutefois elle est une des plus fréquemment utilisées.
-Les paramètres Bursa-Wolf peuvent être spécifiés à l’intérieur de l’élément <code>TOWGS84</code> de la version 1 du format <em>Well Known Text</em> (WKT),
-ou dans l’élément <code>BOUNDCRS</code> avec la version 2 du format <abbr title="Well Known Text">WKT</abbr>.
-Si le <abbr title="Coordinate Reference System">CRS</abbr> est lu à partir d’une chaine <abbr title="Well Known Text">WKT</abbr>, assurez-vous qu’elle contient l’élément approprié.</p>
-<h3 id="slightDifferences">J’obtiens des résultats légèrement différents d’un environnement d’exécution à l’autre. </h3>
-<p>Les résultats de transformations de coordonnées quand on lance l’application dans un conteneur web (type JBoss, <em>etc.</em>)
-peuvent avoir quelques mètres de différence avec la transformation exécutée dans un IDE (NetBeans, Eclipse, <em>etc.</em>).
-Les résultats dépendent de la présence de la fabrique EPSG dans le chemin de classes (classpath),
-<strong>peu importe comment le <abbr title="Coordinate Reference System">CRS</abbr> a été créé</strong>, parce-que la fabrique EPSG spécifie explicitement l’opération à appliquer pour certaines paires de <abbr title="Coordinate Reference System">CRS</abbr>.
-Dans ces cas, l’opération spécifiée par EPSG a priorité par rapport aux paramètres de Bursa-Wolf
-(l’element <code>TOWGS84</code> de la version 1 du format <em>Well Known Text</em>).</p>
-<p>Une connexion à la base EPSG peut avoir été établie dans un environnement (typiquement celui JEE)
-et pas dans l’autre (typiquement un IDE) car uniquement le premier à un pilote <abbr title="Java DataBase Connectivity">JDBC</abbr>.
-La méthode recommandée pour uniformiser les résultats est d’ajouter dans le second environnement (l’IDE)
-le même pilote que celui présent dans le premier environnement (JEE).
-Cela devrait être un des suivant : JavaDB (aussi nommé Derby), HSQL ou PostgreSQL.
-Assurez vous également que les <a href="epsg.html">paramètres de connexion à la base EPSG</a> sont les mêmes.</p>
-<h3 id="toWGS84">Puis-je présumer qu’il est toujours possible de transformer un CRS arbitraire vers WGS84 ? </h3>
-<p>Pour les <abbr title="Coordinate Reference System">CRS</abbr> 2D horizontaux créés avec la base de données EPSG, l’appel à <code>CRS.findOperation(…)</code> devrait toujours marcher.
-Pour les <abbr title="Coordinate Reference System">CRS</abbr> 3D ayant n’importe quel axe de hauteur autre que la hauteur ellipsoïdale, ou pour les <abbr title="Coordinate Reference System">CRS</abbr> 2D de type <code>EngineeringCRS</code>, la méthode peu échouer.
-Il reste à noter que dans le cas ou la méthode <code>CRS.findOperation(…)</code> ne lève pas d’erreur, l’appel à <code>MathTransform.transform(…)</code> peut
-produire des valeurs <code>NaN</code> or <code>Infinity</code>si la coordonnée transformée est éloignée de la zone de validité.</p>
-<h1 id="metadata">Métadonnées </h1>
-<h2 id="metadata-implementation">Implementations sur mesures </h2>
-<h3 id="metadata-proxy">Mes metadonnées sont stockées dans une forme de base de données. Implémenter toute les interfaces de GeoAPI est infaisable. </h3>
-<p>Les développeurs n’ont pas besoin d’implémenter directement les interfaces de metadonnées.
-Si le système de stockage sous-jacent peut accéder aux metadonnées à partir de leur classes et nom de propriétés
-(soit le nom java ou le nom <abbr title="International Organization for Standardization">ISO</abbr>/<abbr title="Open Geospatial Consortium">OGC</abbr>), alors il est possible d’implémenter un seul moteur pour tous les types de metadonnées
-et de laisser la Machine Virtuelle Java implémenter les interfaces GeoAPI à la volée, en utilisant la classe <code>java.lang.reflect.Proxy</code>.
-Pour plus de détails voir la javadoc de la classe <code>Proxy</code>, en gardant à l’esprit que le nom <abbr title="International Organization for Standardization">ISO</abbr>/<abbr title="Open Geospatial Consortium">OGC</abbr> d’une <code>java.lang.Class</code> ou
-<code>java.lang.reflect.Method</code> peut être obtenu comme suit :</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="n">UML</span> <span class="n">uml</span> <span class="o">=</span> <span class="n">method</span><span class="o">.</span><span class="na">getAnnotation</span><span class="o">(</span><span class="n">UML</span><span class="o">.</span><span class="na">class</span><span class="o">);</span>
-</span></span><span class="line"><span class="cl"><span class="k">if</span> <span class="o">(</span><span class="n">uml</span> <span class="o">!=</span> <span class="kc">null</span><span class="o">)</span> <span class="o">{</span>
-</span></span><span class="line"><span class="cl"> <span class="n">String</span> <span class="n">name</span> <span class="o">=</span> <span class="n">uml</span><span class="o">.</span><span class="na">identifier</span><span class="o">();</span>
-</span></span><span class="line"><span class="cl"> <span class="c1">// Extraire les métadonnées ici.
-</span></span></span><span class="line"><span class="cl"><span class="c1"></span><span class="o">}</span></span></span></code></pre></div>
-<p>Cette approche est utilisée dans le paquet <code>org.apache.sis.metadata.sql</code> pour fournir une implémentation
-de toutes les interfaces de metadonnées de GeoAPI à partir d’une base de données SQL.</p>
-<h3 id="metadata-unknownClass">Je n’arrive pas à écrire mon implémentation de metadonnée </h3>
-<p>Les classes données à un marshaller JAXB doivent contenir des annotations JAXB,
-sinon l’exception suivante sera lancée :</p>
-<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">javax.xml.bind.JAXBException: class MyCustomClass nor any of its super class is known to this context.</span></span></code></pre></div>
-<p>La solution de contournement la plus simple est de décorer l’implémentation dans une des implémentations
-fournies dans le paquet <code>org.apache.metadata.iso</code>.
-Toutes les implémentations du SDK fournissent des constructeurs de copies peu profondes pour rendre cela plus simple.
-Il est uniquement nécéssaire de décorer la classes racine, pas les attributs.
-Les valeurs des attributs seront décorées automatiquement au besoin par les adaptateurs JAXB.</p>
-
-
- </article>
- </main>
- <footer class="footer">
- <div class="container">
- <p>
- Copyright © 2013-2023 The Apache Software Foundation, Licensed under the
- <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.<br/>
- Apache SIS, Apache, the Apache feather logo are trademarks of The Apache Software Foundation.
- </p>
- </div>
-</footer>
- </div>
-</div>
-
-<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.1/dist/js/bootstrap.bundle.min.js"
- integrity="sha384-/bQdsTh/da6pkI1MST/rWKFNjaCP5gBSY4sEBT38Q/9RBh9AH40zEOg7Hlq2THRZ" crossorigin="anonymous"></script>
-
-</body>
-</html>
diff --git a/fr/index.html b/fr/index.html
deleted file mode 100644
index c5f09a6..0000000
--- a/fr/index.html
+++ /dev/null
@@ -1,96 +0,0 @@
-<!DOCTYPE html>
-<html lang="fr">
-<head>
- <meta name="generator" content="Hugo 0.101.0" />
-
-
- <title>Apache SIS - La bibliothèque Apache SIS™</title>
- <meta charset="utf-8">
- <meta name="viewport" content="width=device-width, initial-scale=1">
- <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.1.1/dist/css/bootstrap.min.css"
- rel="stylesheet" integrity="sha384-F3w7mX95PdgyTmZZMECAngseQB83DfGTowi0iMjiWaeVhAn4FJkqJByhZMI3AhiU" crossorigin="anonymous">
- <link rel="stylesheet" type="text/css" media="screen" href="../syntax.css">
- <link rel="stylesheet" type="text/css" media="screen" href="../sis.css">
-</head>
-
-<body>
-
-<nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark">
- <div class="container-fluid">
- <a class="navbar-brand" href="../index.html"> Apache SIS™</a>
- <ul class="navbar-nav me-auto mb-2 mb-md-0">
- <li class="nav-item dropdown">
- <a class="nav-link dropdown-toggle" id="menuAbout" data-bs-toggle="dropdown" aria-expanded="false">À propos de</a>
- <ul class="dropdown-menu" aria-labelledby="menuAbout">
- <li><a class="dropdown-item" href="http://www.apache.org/licenses/">Licence</a></li>
- <li><a class="dropdown-item" href="../index.html">Page d'accueil</a></li>
- </ul>
- </li>
- <li class="nav-item dropdown">
- <a class="nav-link dropdown-toggle" id="menuDocumentation" data-bs-toggle="dropdown" aria-expanded="false">Documentation</a>
- <ul class="dropdown-menu" aria-labelledby="menuDocumentation">
- <li><a class="dropdown-item" href="index.html">Sommaire</a></li>
- <li><a class="dropdown-item" href="../book/fr/developer-guide.html">Guide du développeur</a></li>
- <li><a class="dropdown-item" href="../openoffice/fr/index.html">Add-in OpenOffice</a></li>
- <li><a class="dropdown-item" href="faq.html">FAQ</a></li>
- </ul>
- </li>
- </ul>
- <ul class="navbar-nav ml-auto mb-2 mb-md-0">
- <li class="nav-item">
- <a href="https://www.apache.org/events/current-event.html">
- <img class="apache-con" src="https://www.apache.org/events/current-event-234x60.png" alt="ApacheCon"/>
- </a>
- </li>
- </ul>
- </div>
-</nav>
-
-
-<div class="row flex-nowrap">
- <div class="d-flex flex-column flex-shrink-0 p-3 text-white bg-dark" style="width:13rem; min-height:40rem">
- <ul class="nav nav-pills flex-column mb-auto position-fixed">
- <li><a class="nav-link active " href="index.html">Sommaire</a></li>
- <li><a class="nav-link text-white" href="http://www.apache.org/licenses/">Licence</a></li>
- <li><a class="nav-link text-white" href="../book/fr/developer-guide.html">Guide du développeur</a></li>
- <li><a class="nav-link text-white" href="../openoffice/fr/index.html">Add-in OpenOffice</a></li>
- <li><a class="nav-link text-white " href="faq.html">FAQ</a></li>
- <li><hr class="dropdown-divider"></li>
- <li><a class="nav-link text-white" href="../index.html">Anglais</a></li>
- </ul>
- </div>
- <div class="col">
- <main class="container">
- <article>
- <img src="../images/logo.png" class="sis-logo" align="left"/>
- <p class="page-title">La bibliothèque Apache SIS™</p>
-
- <p>Quelques pages du site de Apache <abbr title="Spatial Information System">SIS</abbr> ont été traduites en français,
-mais cette traduction n’est pas maintenue et peut être obsolète.
-Les pages les plus complètes sont les versions anglaises.</p>
-<ul>
-<li><a href="faq.html">Questions fréquentes (FAQ)</a></li>
-<li><a href="../book/fr/developer-guide.html">Guide du développeur</a></li>
-<li><a href="../openoffice/fr/index.html">Add-in OpenOffice</a></li>
-</ul>
-
-
- </article>
- </main>
- <footer class="footer">
- <div class="container">
- <p>
- Copyright © 2013-2023 The Apache Software Foundation, Licensed under the
- <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.<br/>
- Apache SIS, Apache, the Apache feather logo are trademarks of The Apache Software Foundation.
- </p>
- </div>
-</footer>
- </div>
-</div>
-
-<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.1/dist/js/bootstrap.bundle.min.js"
- integrity="sha384-/bQdsTh/da6pkI1MST/rWKFNjaCP5gBSY4sEBT38Q/9RBh9AH40zEOg7Hlq2THRZ" crossorigin="anonymous"></script>
-
-</body>
-</html>
diff --git a/fr/index.xml b/fr/index.xml
deleted file mode 100644
index 4e4a7e4..0000000
--- a/fr/index.xml
+++ /dev/null
@@ -1,20 +0,0 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?>
-<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
- <channel>
- <title>La bibliothèque Apache SIS™ on Apache SIS</title>
- <link>https://sis.apache.org/fr/</link>
- <description>Recent content in La bibliothèque Apache SIS™ on Apache SIS</description>
- <generator>Hugo -- gohugo.io</generator>
- <language>en</language><atom:link href="https://sis.apache.org/fr/index.xml" rel="self" type="application/rss+xml" />
- <item>
- <title>Questions fréquentes (FAQ)</title>
- <link>https://sis.apache.org/fr/faq.html</link>
- <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
-
- <guid>https://sis.apache.org/fr/faq.html</guid>
- <description>Cette page liste quelques questions fréquemment posées à propos de Apache SIS. Son contenu est traduit de la page de FAQ en anglais.
-Géoréférencement Pour bien commencer Comment transformer une coordonnée ? Quelles projections sont supportées ? Qu’est ce que le problème d’ordre des axes et comment est il abordé ? Systèmes de Référence des Coordonnées Comment créer une projection de type Transverse Universelle de Mercator (UTM) ? Comment instancier une projection Google ?</description>
- </item>
-
- </channel>
-</rss>
diff --git a/fr/sitemap.xml b/fr/sitemap.xml
deleted file mode 100644
index b26b8ec..0000000
--- a/fr/sitemap.xml
+++ /dev/null
@@ -1,31 +0,0 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?>
-<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
- xmlns:xhtml="http://www.w3.org/1999/xhtml">
- <url>
- <loc>https://sis.apache.org/fr/</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- <xhtml:link
- rel="alternate"
- hreflang="en"
- href="https://sis.apache.org/"
- />
- <xhtml:link
- rel="alternate"
- hreflang="fr"
- href="https://sis.apache.org/fr/"
- />
- </url><url>
- <loc>https://sis.apache.org/fr/faq.html</loc>
- <lastmod>2022-12-08T22:07:22+01:00</lastmod>
- <xhtml:link
- rel="alternate"
- hreflang="en"
- href="https://sis.apache.org/faq.html"
- />
- <xhtml:link
- rel="alternate"
- hreflang="fr"
- href="https://sis.apache.org/fr/faq.html"
- />
- </url>
-</urlset>
diff --git a/index.xml b/index.xml
index 57cb05f..caffb6b 100644
--- a/index.xml
+++ b/index.xml
@@ -235,16 +235,6 @@
</item>
<item>
- <title>Questions fréquentes (FAQ)</title>
- <link>https://sis.apache.org/fr/faq.html</link>
- <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
-
- <guid>https://sis.apache.org/fr/faq.html</guid>
- <description>Cette page liste quelques questions fréquemment posées à propos de Apache SIS. Son contenu est traduit de la page de FAQ en anglais.
-Géoréférencement Pour bien commencer Comment transformer une coordonnée ? Quelles projections sont supportées ? Qu’est ce que le problème d’ordre des axes et comment est il abordé ? Systèmes de Référence des Coordonnées Comment créer une projection de type Transverse Universelle de Mercator (UTM) ? Comment instancier une projection Google ?</description>
- </item>
-
- <item>
<title>Read raster from a GeoTIFF file</title>
<link>https://sis.apache.org/howto/read_geotiff.html</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
diff --git a/openoffice/en/index.html b/openoffice/en/index.html
deleted file mode 100644
index b2b27c6..0000000
--- a/openoffice/en/index.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<!DOCTYPE html>
-
-<!--
- Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
--->
-
-<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en">
- <head>
- <title>Apache SIS™ add-in for OpenOffice / LibreOffice</title>
- <meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../openoffice.css"/>
- </head>
- <body>
- <h1>Apache <abbr>SIS</abbr>™ add-in for OpenOffice / LibreOffice</h1>
- <p>
- <a href="../../">Apache <abbr>SIS</abbr></a> is a toolbox offering some Geographic Information System (<abbr>GIS</abbr>) services.
- <abbr title="Spatial Information System">SIS</abbr> is developed as an open source project under Apache 2 license
- and can be used as a foundation for independent projects.
- The <cite>add-in</cite> for <a href="http://www.openoffice.org">OpenOffice</a> or
- <a href="http://www.libreoffice.org/">LibreOffice</a> described here is a bridge for accessing
- some Apache <abbr>SIS</abbr> functionalities from Calc spreadsheet.
- Currently only coordinate operation services are (partially) made accessible,
- but we hope to open the add-in to more functionalities in the future.
- </p>
-
- <ul>
- <li><a href="install.html">Apache <abbr>SIS</abbr> add-in installation on OpenOffice / LibreOffice</a></li>
- <li><a href="formula.html">Formulas added to Calc by the add-in</a></li>
- <li><a href="../example.ods">Spreadsheet example using add-in formulas</a></li>
- </ul>
- </body>
-</html>
diff --git a/openoffice/en/formula.html b/openoffice/formula.html
similarity index 96%
rename from openoffice/en/formula.html
rename to openoffice/formula.html
index 05021e4..a60ee32 100644
--- a/openoffice/en/formula.html
+++ b/openoffice/formula.html
@@ -24,7 +24,7 @@
<head>
<title>Formulas added to Calc by the add-in</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../openoffice.css"/>
+ <link rel="stylesheet" type="text/css" href="openoffice.css"/>
</head>
<body>
<h1>Formulas added to Calc by the add-in</h1>
@@ -46,9 +46,9 @@
This add-in for Open/LibreOffice contains a copy (in binary format) of <abbr>EPSG</abbr> database for convenience,
but note that its use <a href="https://epsg.org/terms-of-use.html">is subject to conditions</a>.
Apache <abbr>SIS</abbr> extends this list with a few codes defined outside <abbr>EPSG</abbr>, in particular codes defined by <abbr title="Open Geospatial Consortium">OGC</abbr>.
- A summary of codes embedded in Apache <abbr>SIS</abbr> is <a href="../../tables/CoordinateReferenceSystems.html">available here</a>.
+ A summary of codes embedded in Apache <abbr>SIS</abbr> is <a href="../tables/CoordinateReferenceSystems.html">available here</a>.
Recognized code syntax
- <a href="../../apidocs/org/apache/sis/referencing/CRS.html#forCode-java.lang.String-">is described in Apache <abbr>SIS</abbr> Javadoc</a>.
+ <a href="../apidocs/org.apache.sis.referencing/org/apache/sis/referencing/CRS.html#forCode(java.lang.String)">is described in Apache <abbr>SIS</abbr> Javadoc</a>.
For example, all following codes are considered equivalent to <code>"EPSG:4326"</code>:
</p>
<ul>
@@ -79,7 +79,7 @@
The numerical value must be an angle in decimal degrees (for example 12.5 for 12°30′).
The returned text may be a decimal or sexagesimal angle, depending on the pattern given in argument.
This pattern contains some special characters
- <a href="../../apidocs/org/apache/sis/measure/AngleFormat.html">described in Apache <abbr>SIS</abbr> Javadoc</a>.
+ <a href="../apidocs/org.apache.sis.util/org/apache/sis/measure/AngleFormat.html">described in Apache <abbr>SIS</abbr> Javadoc</a>.
The main ones are: <var>D</var>, <var>M</var>, <var>S</var>, <var>d</var>, <var>m</var> and <var>s</var>.
The <var>D</var> character represents the integer part of degrees and <var>d</var> the fractional part.
The <var>M</var> character represents the integer part of minutes and <var>m</var> the fractional part.
diff --git a/openoffice/fr/formula.html b/openoffice/fr/formula.html
deleted file mode 100644
index dce4c4b..0000000
--- a/openoffice/fr/formula.html
+++ /dev/null
@@ -1,289 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<!DOCTYPE html>
-
-<!--
- Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
--->
-
-<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="fr">
- <head>
- <title>Formules ajoutées dans Calc</title>
- <meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../openoffice.css"/>
- </head>
- <body>
- <h1>Formules ajoutées dans Calc</h1>
- <p>
- L’extension Apache <abbr title="Spatial Information System">SIS</abbr> pour Open/LibreOffice
- fournit de nouvelles fonctions réparties dans 2 catégories : <i>Texte</i> et <i>Add-in</i>.
- Le principe de base des fonctions de la catégorie <i>Add-in</i> est le suivant :
- chaque système de référence des coordonnées est identifié par un code numérique de la
- <a href="https://epsg.org/">base de données géodesiques <abbr>EPSG</abbr></a> ou d’une autre autorité.
- La base de donnnées <abbr>EPSG</abbr> recense plus de 6000 systèmes en usage sur la planète,
- ainsi que des paramètres permettant d’effectuer des transformations d’un système vers un autre.
- Certaines fonctions permettent d’obtenir des informations sur un système de référence en particulier,
- par exemple son domaine de validité. Ces fonctions n’attendent qu’un seul code <abbr>EPSG</abbr> en paramètre.
- D’autres fonctions agissent non pas à partir d’un système de référence seul,
- mais plutôt à partir d’une transformation passant d’un système vers un autre.
- Ces fonctions attendent deux codes <abbr>EPSG</abbr> en paramètres, chacun correspondant à un système de référence différent.
- Le premier code définit le système source, et le second code définit le système destination.
- L’opération est définie par l’algorithme permettant de passer des coordonnées du système source vers celles du système destination.
- </p><p>
- Les définitions officielles des codes <abbr>EPSG</abbr> peuvent être explorées en-ligne avec le <a href="https://epsg.org/">registre <abbr>EPSG</abbr></a>.
- Cette extension pour Open/LibreOffice est toutefois livrée avec sa propre copie (dans un format binaire) de la base de données <abbr>EPSG</abbr>,
- dont <a href="https://epsg.org/terms-of-use.html">l’utilisation est soumise à des conditions</a>.
- Apache <abbr>SIS</abbr> étend cette liste avec quelques codes définis en dehors d’<abbr>EPSG</abbr>, notamment par l’<abbr title="Open Geospatial Consortium">OGC</abbr>.
- Un sommaire des codes embarqués par Apache <abbr>SIS</abbr> est <a href="../../tables/CoordinateReferenceSystems.html">donné ici</a>.
- La syntaxe des codes acceptés
- <a href="../../apidocs/org/apache/sis/referencing/CRS.html#forCode-java.lang.String-">est décrite dans la Javadoc de Apache <abbr>SIS</abbr></a>.
- Par exemple, tous les codes suivants sont considérés équivalents à <code>"EPSG:4326"</code> :
- </p>
- <ul>
- <li><code>"EPSG::4326"</code></li>
- <li><code>"urn:ogc:def:crs:EPSG::4326"</code></li>
- <li><code>"http://www.opengis.net/def/crs/epsg/0/4326"</code></li>
- <li><code>"http://www.opengis.net/gml/srs/epsg.xml#4326"</code></li>
- </ul>
- <p>
- La plupart des fonctions opérant sur des coordonnées sont des fonctions matricielles.
- Leurs sorties nécessitent plusieurs colonnes, autant qu’il y a de dimensions dans le système de référence utilisé.
- Par exemple si une fonction doit retourner une coordonnée à trois dimensions,
- alors il faut sélectionner trois colonnes avant d’entrer la fonction
- et valider cette dernière en appuyant sur [Ctrl] + [Shift] + [Entrée].
- </p><p>
- Bien qu’il soit possible d’utiliser une fonction par ligne
- et de la recopier sur de nouvelles lignes autant de fois qu’il y a de points à transformer,
- il est beaucoup plus efficace de profiter là aussi du caractère matriciel des fonctions.
- En plus d’avoir sélectionné le nombre de colonnes nécessaires, sélectionnez autant de lignes qu’il y a de points à transformer.
- Cela permet à Apache <abbr>SIS</abbr> de récupérer les informations associées aux codes <abbr>EPSG</abbr> une seule fois
- pour toutes les lignes de la matrice résultante, plutôt que de recommencer cette opération pour chaque fonction recopiée.
- </p>
-
-
- <section>
- <span class="eng">(en anglais : <code>TEXT.ANGLE</code>)</span>
- <h2 id="TEXT.ANGLE">TEXTE.ANGLE</h2>
- <p>
- Convertit une valeur numérique en chaîne de caractères représentant un angle.
- La valeur numérique doit être un angle en degrés décimaux (par exemple 12,5 pour 12°30′).
- La chaîne retournée peut être un angle sexagésimal, en fonction du modèle donné en argument.
- Ce modèle comprend quelques caractères spéciaux
- <a href="../../apidocs/org/apache/sis/measure/AngleFormat.html">décrits dans la Javadoc de Apache <abbr>SIS</abbr></a>,
- dont les principaux sont : <var>D</var>, <var>M</var>, <var>S</var>, <var>d</var>, <var>m</var> et <var>s</var>.
- Le caractère <var>D</var> représente la partie entière des degrés, et <var>d</var> la partie fractionnaire.
- Le symbole <var>M</var> représente la partie entière des minutes, et <var>m</var> la partie fractionnaire.
- Enfin le symbole <var>S</var> représente la partie entière des secondes, et <var>s</var> la partie fractionnaire.
- </p>
- <table>
- <caption>Exemples</caption>
- <tr><th>Formule</th> <th>Résultat</th></tr>
- <tr><td><code>=TEXTE.ANGLE(167,1590; "DD°")</code></td> <td>167°</td></tr>
- <tr><td><code>=TEXTE.ANGLE(167,1590; "DD°MM′")</code></td> <td>167°10′</td></tr>
- <tr><td><code>=TEXTE.ANGLE(167,1590; "DD°MM′SS″")</code></td> <td>167°09′32″</td></tr>
- <tr><td><code>=TEXTE.ANGLE(167,1590; "DD°MM′SS.s″")</code></td> <td>167°09′32,4″</td></tr>
- </table>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>VALUE.ANGLE</code>)</span>
- <h2 id="VALUE.ANGLE">VALEUR.ANGLE</h2>
- <p>
- Convertit en valeur numérique une chaîne de caractères représentant un angle.
- Cette fonction est l’inverse de <code><a href="#TEXT.ANGLE">TEXTE.ANGLE</a></code>.
- La chaîne de caractères peut représenter un angle sexagésimal, à la condition que les symboles °, ′ et ″
- soient correctement utilisés pour identifier les degrés, minutes et secondes respectivement.
- L’hémisphère (<cite>N</cite>, <cite>S</cite>, <cite>E</cite> ou <cite>W</cite>) est optionnel.
- L’angle retourné est toujours exprimé en degrés décimaux.
- </p><p>
- Les symboles °, ′ et ″ n’ont pas besoin d’être tous présents.
- Ils peuvent être complètement omis si un modèle approprié est donné en argument.
- Par exemple si le modèle est <cite>DDMM</cite>, alors cette fonction convertira le texte "0430" en la valeur numérique 4,5.
- Excepté pour de tels cas où les symboles différentiateurs de champs sont complètement absents,
- le modèle donné à la fonction <code>VALEUR.ANGLE</code> est plutôt à titre indicatif.
- Cette fonction est assez tolérante et devrait interpréter correctement des chaînes de caractères
- qui ne correspondent pas exactement au modèle.
- </p>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>CRS.NAME</code>)</span>
- <h2 id="CRS.NAME">NOM.SRS</h2>
- <p>
- Retourne le nom du système de référence identifié par le code donné.
- Le code du système est l’unique argument attendu par cette fonction.
- Bien que cette fonction soit conçue pour retourner le nom de systèmes de références spatiaux (<abbr>SRS</abbr>),
- elle peut aussi retourner le nom de d’autres types d’objets à la condition que leur type soit explicité
- (par exemple : <code>"urn:ogc:def:<b>datum</b>:EPSG::6326"</code>).
- </p>
- <table>
- <caption>Exemples</caption>
- <tr><th>Formule</th> <th>Résultat</th></tr>
- <tr><td><code>=NOM.SRS("EPSG:3060")</code></td> <td>IGN72 Grande Terre / UTM zone 58S</td></tr>
- <tr><td><code>=NOM.SRS("EPSG:3061")</code></td> <td>Porto Santo 1995 / UTM zone 28N</td></tr>
- <tr><td><code>=NOM.SRS("EPSG:4326")</code></td> <td>WGS 84</td></tr>
- <tr><td><code>=NOM.SRS("EPSG:4329")</code></td> <td>WGS 84 (3D)</td></tr>
- </table>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>CRS.USAGE</code>)</span>
- <h2><a id="CRS.USAGE">USAGE.SRS</a></h2>
- <p>
- Retourne le domaine d’utilisation du système de référence identifié par le code donné.
- Le code du système est l’unique argument attendu par cette fonction.
- Bien que cette fonction soit conçue pour retourner le domaine d’utilisation de systèmes de références spatiaux (<abbr>SRS</abbr>),
- elle peut aussi retourner le domaine de d’autres types d’objets à la condition que leur type soit explicité
- (par exemple : <code>"urn:ogc:def:<b>datum</b>:EPSG::6326"</code>).
- </p>
- <table>
- <caption>Exemples</caption>
- <tr><th>Formule</th> <th>Résultat</th></tr>
- <tr><td><code>=USAGE.SRS("EPSG:3060")</code></td> <td>Large and medium scale topographic mapping and engineering survey.</td></tr>
- <tr><td><code>=USAGE.SRS("EPSG:4327")</code></td> <td>Used by GPS satellite navigation system.</td></tr>
- </table>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>REGION.NAME</code>)</span>
- <h2 id="REGION.NAME">NOM.REGION</h2>
- <p>
- Retourne une description textuelle de la région dans laquelle un objet est valide.
- Cette description comprend habituellement les noms des pays ou provinces pour lesquels le système a été conçu.
- L’objet donné en argument est souvent, mais pas obligatoirement, un code de Système de Références Spatiales (<abbr>SRS</abbr>).
- </p>
- <table>
- <caption>Exemples</caption>
- <tr><th>Formule</th> <th>Résultat</th></tr>
- <tr><td><code>=NOM.REGION("EPSG:3060")</code></td> <td>New Caledonia - Grande Terre.</td></tr>
- <tr><td><code>=NOM.REGION("EPSG:4326")</code></td> <td>World.</td></tr>
- </table>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>GEOGRAPHIC.AREA</code>)</span>
- <h2 id="GEOGRAPHIC.AREA">REGION.GEOGRAPHIQUE</h2>
- <p>
- Retourne sous forme de boîte englobante le domaine d’un objet identifié par le code donné.
- Si le code donné en argument identifie un système de référence spatial,
- alors cette fonction retourne les coordonnées géographiques de la région dans laquelle le système est valide.
- La boîte est exprimée par une matrice 2×2 avec les latitudes dans la première colonne
- et les longitudes dans la seconde colonne, toujours dans cet ordre et toujours en degrés décimaux.
- La première ligne donne les coordonnées du coin supérieur gauche
- et la seconde ligne donne celles du coin inférieur droit.
- En d’autres termes, les valeurs retournées par cette fonction se répartissent comme suit :
- </p>
- <table class="grid">
- <tr><td>Nord</td> <td>Ouest</td></tr>
- <tr><td>Sud</td> <td>Est</td></tr>
- </table>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>CRS.AXIS</code>)</span>
- <h2 id="CRS.AXIS">AXE.SRS</h2>
- <p>
- Retourne le nom d’un axe d’un système de référence de coordonnées avec ses unités.
- Cette fonction attend en arguments le code d’un système de référence, suivit de l’index d’un de ses axes.
- Les index sont numérotés de 1 jusqu’au nombre de dimensions du système de référence, inclusivement.
- Cette fonction est particulièrement utile pour obtenir le libellé des colonnes qui contiendront les coordonnées.
- </p>
- <table>
- <caption>Exemples</caption>
- <tr><th>Formule</th> <th>Résultat</th></tr>
- <tr><td><code>=AXE.SRS("EPSG:4326"; 1)</code></td> <td>Latitude (°)</td></tr>
- <tr><td><code>=AXE.SRS("EPSG:4326"; 2)</code></td> <td>Longitude (°)</td></tr>
- <tr><td><code>=AXE.SRS("EPSG:32758"; 1)</code></td> <td>Easting (m)</td></tr>
- <tr><td><code>=AXE.SRS("EPSG:32758"; 2)</code></td> <td>Northing (m)</td></tr>
- </table>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>TRANSFORM.POINTS</code>)</span>
- <h2 id="TRANSFORM.POINTS">TRANSFORM.POINTS</h2>
- <p>
- Applique un changement (transformation ou conversion) de coordonnées sur des points.
- Les coordonnées à transformer doivent être disposées sous forme de tableau avec une coordonnée par ligne
- et autant de colonnes qu’il y a de dimensions dans leur système de référence (habituellement deux ou trois).
- La sortie aura une disposition similaire. Cette fonction attend trois arguments :
- </p>
- <ul>
- <li>Le code du système de référence source.</li>
- <li>Le code du système de référence destination.</li>
- <li>La plage de coordonnées à transformer.</li>
- </ul>
- <p>
- L’ordre et le nombre de colonnes dans la plage de coordonnées à transformer dépendent du système de référence source.
- L’ordre et le nombre de colonnes des coordonnées transformées (la sortie de cette méthode) dépendent du système de référence destination.
- Pour s’y retrouver, il est pratique d’utiliser la fonction <code><a href="#CRS.AXIS">AXE.SRS</a></code> pour le libellé des colonnes.
- </p><p>
- Toutes les transformations de coordonnées n’ont pas la même précision.
- Pour obtenir une estimation de l’erreur, on peut utiliser la fonction <code><a href="#TRANSFORM.ACCURACY">PRECISION.TRANSFORM</a></code>
- avec les mêmes arguments que ceux qui auront été spécifiés à <code>TRANSFORM.POINTS</code>.
- </p>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>TRANSFORM.ENVELOPE</code>)</span>
- <h2 id="TRANSFORM.ENVELOPE">TRANSFORM.ENVELOPPE</h2>
- <p>
- Applique un changement (transformation ou conversion) une boîte englobante.
- Cette fonction prend les mêmes arguments que <code><a href="#TRANSFORM.POINTS">TRANSFORM.POINTS</a></code>,
- mais ne retournera que deux lignes. La première ligne contiendra les coordonnées transformées minimales alors
- que la second ligne contiendra les coordonnées transformées maximales.
- Ce résultat peut être différent de celui que l’on obtiendrait en transformant d’abord les points
- puis en prenant leurs minimums et maximums. La raison de cette différence est que cette fonction
- <code>TRANSFORM.ENVELOPPE</code> prend en compte la courbure de la boîte englobante sous l’effet
- d’une projection cartographique ou autre transformation.
- </p>
- </section>
-
-
- <section>
- <span class="eng">(en anglais : <code>TRANSFORM.ACCURACY</code>)</span>
- <h2><a id="TRANSFORM.ACCURACY">PRECISION.TRANSFORM</a></h2>
- <p>
- Retourne une <strong>estimation</strong> de la précision des transformations de coordonnées entre deux systèmes de référence.
- Cette fonction attend en argument les codes de deux systèmes de référence, habituellement ceux qui sont spécifiés à la fonction
- <code><a href="#TRANSFORM.POINTS">TRANSFORM.POINTS</a></code>.
- Elle retourne une estimation de l’erreur induite par la transformation de coordonnées, toujours en mètres.
- Il ne s’agit pas de l’erreur due aux limites de l’arithmétique en virgule flottante,
- mais plutôt de l’erreur due à la nature stochastique des paramètres dès qu’un changement de référentiel est impliqué
- (ces paramètres sont déterminés empiriquement à partir d’un ensemble de points exprimés selon les deux systèmes de références).
- </p><p>
- Des incertitudes sur les coordonnées calculées surviennent dès qu’il y a eu changement de référentiel,
- auquel cas on parle de <cite>transformation de coordonnées</cite> selon la terminologie de la norme
- <abbr title="Organisation internationale de normalisation">ISO</abbr> 19111.
- Lorsque le calcul consiste par exemple à appliquer une projection cartographique sans changer de référentiel,
- on parle alors de <cite>conversion de coordonnées</cite> (toujours selon la terminologie de la norme <abbr>ISO</abbr>).
- Dans ce dernier cas, la fonction <code>TRANSFORM.ACCURACY</code> peut retourner 0,
- ce qui signifie l’opération a une précision infinie en théorie.
- En pratique, Apache <abbr>SIS</abbr> est limitée par la précision des calculs à virgules flottantes
- ainsi que par les approximations utilisées pour certaines formules non-linéaires.
- L’erreur ne sera donc <em>pas réellement</em> nulle, mais devrait être faible.
- </p>
- </section>
- </body>
-</html>
diff --git a/openoffice/fr/index.html b/openoffice/fr/index.html
deleted file mode 100644
index 26ce32e..0000000
--- a/openoffice/fr/index.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<!DOCTYPE html>
-
-<!--
- Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
--->
-
-<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="fr">
- <head>
- <title>Extension Apache SIS™ pour OpenOffice / LibreOffice</title>
- <meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../openoffice.css"/>
- </head>
- <body>
- <h1>Extension Apache <abbr>SIS</abbr>™ pour OpenOffice / LibreOffice</h1>
- <p>
- <a href="../../">Apache <abbr>SIS</abbr></a> est une boîte à outils offrant quelques uns des services trouvés dans les systèmes d’informations géographiques.
- <abbr title="Spatial Information System">SIS</abbr> est développé comme projet libre sous licence Apache 2
- et peut servir de fondation à des projets indépendants.
- L’extension (<cite>add-in</cite>) pour <a href="http://www.openoffice.org">OpenOffice</a> ou
- <a href="http://www.libreoffice.org/">LibreOffice</a> décrit ici est un pont permettant
- d’accéder à une partie des fonctionnalités de Apache <abbr>SIS</abbr> à partir du tableur Calc.
- Dans un premier temps, seul le module de transformation de coordonnées est ainsi rendu (partiellement) accessible,
- mais nous espérons ajouter des ponts vers d’autres fonctionnalités progressivement.
- </p>
-
- <ul>
- <li><a href="install.html">Installation de l’extension Apache <abbr>SIS</abbr> pour OpenOffice / LibreOffice</a></li>
- <li><a href="formula.html">Formules ajoutées par l’extension dans Calc</a></li>
- <li><a href="../example.ods">Exemple de feuille de calculs utilisant les formules de l’extension</a></li>
- </ul>
- </body>
-</html>
diff --git a/openoffice/fr/install.html b/openoffice/fr/install.html
deleted file mode 100644
index b2bcdf3..0000000
--- a/openoffice/fr/install.html
+++ /dev/null
@@ -1,96 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<!DOCTYPE html>
-
-<!--
- Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
--->
-
-<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="fr">
- <head>
- <title>Installation de l’extension Apache SIS pour OpenOffice / LibreOffice</title>
- <meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../openoffice.css"/>
- </head>
- <body>
- <h1>Installation de l’extension Apache <abbr>SIS</abbr> pour OpenOffice / LibreOffice</h1>
- <section>
- <h2 id="requirements">Pré-requis</h2>
- <p>
- Cette extension requiert OpenOffice ou LibreOffice (au choix), ainsi que Java 7 ou 8.
- La version actuelle de l’extension a été testée avec LibreOffice 5.3 et Java 8.
- Cette version ne fonctionne pas encore avec Java 9.
- </p>
- </section>
-
-
- <section>
- <h2 id="configuration">Configuration</h2>
- <p>
- Avant d’installer l’extension, il peut être utile de configurer OpenOffice ou LibreOffice afin que celui-ci sache
- où se trouve l’environnement d’exécution du Java (<abbr title="Java Runtime Environment">JRE</abbr>).
- Cette configuration s’effectue en sélectionnant le menu <i>Outils</i> → <i>Options</i> sur Linux,
- ou <i>Open/LibreOffice</i> → <i>Préférences</i> sur MacOS.
- Dans la boîte de dialogue qui s’affiche, sélectionnez <i>Java</i> (sous OpenOffice) ou <i>Avancé</i> (sous LibreOffice).
- Si aucun environnement Java n’apparaît dans la liste, appuyez sur le bouton <i>Ajouter</i> et sélectionnez le répertoire
- où un environnement Java est installé.
- Une fois la liste des environnements Java apparue, sélectionnez une version 7 ou 8 du Java.
- </p>
- </section>
-
-
- <section>
- <h2 id="install">Installation</h2>
- <p>
- Téléchargez l’extension Apache <abbr title="Spatial Information System">SIS</abbr> pour Open/LibreOffice
- et sauvegardez le fichier n’importe où sur le disque.
- Dans Open/LibreOffice, sélectionnez le menu <i>Outils</i> → <i>Gestionnaire des extensions</i>.
- Appuyez sur le bouton <i>Ajouter…</i> et sélectionnez le fichier <code>apache-sis.oxt</code> qui a été téléchargé.
- L’installateur vous demandera d’accepter la licence Apache 2 ainsi que les conditions d’utilisation
- de la <a href="https://epsg.org/">base de données géodésiques <abbr>EPSG</abbr></a>.
- Après installation, il peut être nécessaire de redémarrer Open/LibreOffice pour qu’elle soit prise en compte.
- Si un icône de démarrage rapide apparaît dans la barre des tâches, il doit être fermé lui aussi avant de relancer Open/LibreOffice.
- </p><p>
- L’extension peut être désinstallé à tout moment par ce même menu.
- </p>
- </section>
-
-
- <section>
- <h2 id="problems">Résolution de problèmes</h2>
- <p>
- Si les formules fournit par l’extension Apache <abbr>SIS</abbr> ne produit que le résultat <code>#VALEUR!</code>,
- alors il est possible qu’une erreur survienne lors de l’exécution.
- Plus de détails peuvent être obtenus en ouvrant le fichier <code>jre/lib/logging.properties</code>
- avec un quelconque éditeur de texte, et en remplaçant la ligne suivante :
- </p>
- <blockquote><pre>handlers= java.util.logging.ConsoleHandler</pre></blockquote>
- <p>par</p>
- <blockquote><pre>handlers= java.util.logging.ConsoleHandler, java.util.logging.FileHandler</pre></blockquote>
- <p>
- Par défaut (il est possible de paramétrer plus finement),
- un fichier avec l’extension <code>.log</code> sera créé dans le répertoire de l’utilisateur.
- Ce fichier au format <abbr>XML</abbr> contient des informations sur le déroulement de l’exécution du programme Java.
- Les enregistrements dans le journal <code>org.apache.sis.openoffice</code> contiennent des informations
- se rapportant plus spécifiquement au pont Apache <abbr>SIS</abbr> ↔ Open/LibreOffice.
- L’élément <i>Message</i> contient quelques détails sur la cause de l’erreur.
- Si vous souhaitez demander de l’aide sur la <a href="../../mail-lists.html">liste des utilisateurs de Apache <abbr>SIS</abbr></a>,
- les messages enregistrés dans ce journal peuvent être utiles.
- </p>
- </section>
- </body>
-</html>
diff --git a/openoffice/index.html b/openoffice/index.html
index 779bba3..0ee9f4c 100644
--- a/openoffice/index.html
+++ b/openoffice/index.html
@@ -1,23 +1,48 @@
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html>
-<!-- Licensed to the Apache Software Foundation (ASF) -->
-<html>
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en">
<head>
<title>Apache SIS™ add-in for OpenOffice / LibreOffice</title>
- <meta charset="UTF-8">
- <script language="javascript" type="text/javascript">
- <!--
- switch (navigator.language) {
- case "fr": window.location = "fr/index.html"; break;
- default: window.location = "en/index.html"; break;
- }
- // -->
- </script>
+ <meta charset="UTF-8"/>
+ <link rel="stylesheet" type="text/css" href="openoffice.css"/>
</head>
<body>
- <h1>Apache SIS™ add-in for OpenOffice / LibreOffice</h1>
+ <h1>Apache <abbr>SIS</abbr>™ add-in for OpenOffice / LibreOffice</h1>
+ <p>
+ <a href="../">Apache <abbr>SIS</abbr></a> is a toolbox offering some Geographic Information System (<abbr>GIS</abbr>) services.
+ <abbr title="Spatial Information System">SIS</abbr> is developed as an open source project under Apache 2 license
+ and can be used as a foundation for independent projects.
+ The <cite>add-in</cite> for <a href="http://www.openoffice.org">OpenOffice</a> or
+ <a href="http://www.libreoffice.org/">LibreOffice</a> described here is a bridge for accessing
+ some Apache <abbr>SIS</abbr> functionalities from Calc spreadsheet.
+ Currently only coordinate operation services are (partially) made accessible,
+ but we hope to open the add-in to more functionalities in the future.
+ </p>
+
<ul>
- <li><a href="en/index.html">English</a></li>
- <li><a href="fr/index.html">Français</a></li>
+ <li><a href="install.html">Apache <abbr>SIS</abbr> add-in installation on OpenOffice / LibreOffice</a></li>
+ <li><a href="formula.html">Formulas added to Calc by the add-in</a></li>
+ <li><a href="example.ods">Spreadsheet example using add-in formulas</a></li>
</ul>
</body>
</html>
diff --git a/openoffice/en/install.html b/openoffice/install.html
similarity index 91%
rename from openoffice/en/install.html
rename to openoffice/install.html
index d805e7a..2e1ea37 100644
--- a/openoffice/en/install.html
+++ b/openoffice/install.html
@@ -24,16 +24,14 @@
<head>
<title>Apache SIS add-in installation on OpenOffice / LibreOffice</title>
<meta charset="UTF-8"/>
- <link rel="stylesheet" type="text/css" href="../openoffice.css"/>
+ <link rel="stylesheet" type="text/css" href="openoffice.css"/>
</head>
<body>
<h1>Apache <abbr>SIS</abbr> add-in installation on OpenOffice / LibreOffice</h1>
<section>
<h2 id="requirements">Requirements</h2>
<p>
- This add-in requires OpenOffice or LibreOffice, together with Java 7 or 8.
- Current add-in version has been tested on LibreOffice 5.3 with Java 8.
- This version does not work yet with Java 9.
+ This add-in requires OpenOffice or LibreOffice, together with Java 11 or later.
</p>
</section>
@@ -47,7 +45,7 @@
In the dialog box, select <i>Java</i> (on OpenOffice) or <i>Advanced</i> (on LibreOffice).
If no Java runtime environment is proposed, push the <i>Add</i> button and select a directory
where a Java Runtime Environment is installed.
- When a list of <abbr>JRE</abbr> is available, select a Java version 7 or 8.
+ When a list of <abbr>JRE</abbr> is available, select a Java version 11 or later.
</p>
</section>
@@ -85,7 +83,7 @@
Records in the <code>org.apache.sis.openoffice</code> logger contain information
more specifically about Apache <abbr>SIS</abbr> ↔ Open/LibreOffice bridge.
The <i>Message</i> element contains some details about the error cause.
- If you wish to ask for help on <a href="../../mail-lists.html">Apache <abbr>SIS</abbr> user mailing list</a>,
+ If you wish to ask for help on <a href="../mail-lists.html">Apache <abbr>SIS</abbr> user mailing list</a>,
providing the messages recorded in this logger may be useful.
</p>
</section>
diff --git a/release-management.html b/release-management.html
index 391423f..2e78104 100644
--- a/release-management.html
+++ b/release-management.html
@@ -532,7 +532,7 @@
A new <code>org.apache.sis</code> item should appear in the <em>Repository</em> column of <em>Build Promotion</em> → <em>Staging repositories</em>.
Navigate through the artifact tree and make sure that all Javadoc, source and jar files have <code>.asc</code> (GPG signature) and <code>.sha1</code> files.
Select any <code>*-javadoc.jar</code> file and click on the <cite>Archive Browser</cite> tab on the right side.
-Select any <code>*.html</code> file which is known to use some of the custom taglets defined in the <code>sis-build-helper</code> module.
+Select any <code>*.html</code> file which is known to use some of the custom taglets defined in <code>buildSrc</code>.
Click on that file and verify that the custom elements are rendered properly.
Then close this staging repository.
In the description field, specify <em>“Apache SIS main artifacts”</em>.</p>
@@ -661,7 +661,6 @@
</span></span><span class="line"><span class="cl">mv public/.htaccess public/* ../asf-staging/
</span></span><span class="line"><span class="cl">rmdir public
</span></span><span class="line"><span class="cl"><span class="nb">cd</span> ../asf-staging/
-</span></span><span class="line"><span class="cl">rm fr.html
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="c1"># Remove trailing whitespaces</span>
</span></span><span class="line"><span class="cl">find . -name <span class="s2">"*.html"</span> -type f -exec sed -i <span class="s1">'s/[[:space:]]*$//'</span> <span class="s1">'{}'</span> <span class="se">\;</span>
diff --git a/sitemap.xml b/sitemap.xml
index e5395c0..b18ed0a 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -1,16 +1,152 @@
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
-<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
-
- <sitemap>
- <loc>https://sis.apache.org/en/sitemap.xml</loc>
-
- <lastmod>2023-10-02T23:31:58+02:00</lastmod>
-
- </sitemap>
-
- <sitemap>
- <loc>https://sis.apache.org/fr/sitemap.xml</loc>
-
- </sitemap>
-
-</sitemapindex>
+<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
+ xmlns:xhtml="http://www.w3.org/1999/xhtml">
+ <url>
+ <loc>https://sis.apache.org/downloads.html</loc>
+ <lastmod>2023-11-17T11:22:19+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/team-list.html</loc>
+ <lastmod>2022-12-08T22:07:22+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/source.html</loc>
+ <lastmod>2023-10-03T18:22:46+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/coding-conventions.html</loc>
+ <lastmod>2023-11-17T11:22:19+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/command-line.html</loc>
+ <lastmod>2023-11-17T09:45:36+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/geodetic_paths.html</loc>
+ <lastmod>2023-04-18T16:41:51+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/formats.html</loc>
+ <lastmod>2023-10-25T18:34:35+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/crs_equality.html</loc>
+ <lastmod>2023-04-17T12:04:43+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/faq.html</loc>
+ <lastmod>2023-01-21T00:15:54+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/datalake_to_datacube.html</loc>
+ <lastmod>2023-09-28T11:41:25+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/export_metadata_to_xml.html</loc>
+ <lastmod>2023-01-21T14:16:36+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/geographic_bounding_box.html</loc>
+ <lastmod>2023-01-21T14:16:36+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/raster_values_at_geographic_coordinates.html</loc>
+ <lastmod>2023-04-17T12:04:43+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/raster_values_at_pixel_coordinates.html</loc>
+ <lastmod>2023-04-18T15:30:06+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/lookup_crs_urn.html</loc>
+ <lastmod>2023-04-17T12:04:43+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/rasters_bigger_than_memory.html</loc>
+ <lastmod>2023-04-18T12:19:12+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/epsg.html</loc>
+ <lastmod>2022-12-08T22:07:22+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto.html</loc>
+ <lastmod>2023-06-08T16:04:04+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/instantiate_utm_projection.html</loc>
+ <lastmod>2023-01-21T00:15:54+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/javafx.html</loc>
+ <lastmod>2022-12-08T22:07:22+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/mail-lists.html</loc>
+ <lastmod>2022-12-08T22:07:22+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/contributor.html</loc>
+ <lastmod>2022-12-08T22:07:22+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/parallel_computation.html</loc>
+ <lastmod>2023-04-18T15:30:06+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/parse_and_format_mgrs_codes.html</loc>
+ <lastmod>2023-04-18T16:41:51+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/read_geotiff.html</loc>
+ <lastmod>2023-09-28T11:41:25+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/read_netcdf.html</loc>
+ <lastmod>2023-09-28T11:41:25+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/code-patterns.html</loc>
+ <lastmod>2022-12-08T22:07:22+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-management.html</loc>
+ <lastmod>2023-11-17T11:22:19+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes.html</loc>
+ <lastmod>2023-10-02T17:36:51+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/resample_raster.html</loc>
+ <lastmod>2023-04-18T15:30:06+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.1.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.2.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.3.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.4.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.5.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.6.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.7.html</loc>
+ <lastmod>2023-08-19T16:17:41+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/0.8.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/1.0.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/1.1.html</loc>
+ <lastmod>2023-08-19T16:17:41+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/1.2.html</loc>
+ <lastmod>2022-12-12T22:21:04+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/1.3.html</loc>
+ <lastmod>2023-10-02T23:31:58+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/release-notes/1.4.html</loc>
+ <lastmod>2023-10-02T23:31:58+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/standards.html</loc>
+ <lastmod>2023-10-18T22:37:15+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/</loc>
+ <lastmod>2023-10-03T18:22:46+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/transform_coordinates.html</loc>
+ <lastmod>2023-01-21T00:15:54+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/transform_envelopes.html</loc>
+ <lastmod>2023-08-19T16:17:41+02:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/envelopes_in_different_crs.html</loc>
+ <lastmod>2023-01-21T14:16:36+01:00</lastmod>
+ </url><url>
+ <loc>https://sis.apache.org/howto/write_raster.html</loc>
+ <lastmod>2023-09-28T11:41:25+02:00</lastmod>
+ </url>
+</urlset>
