sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1705105 [2/9] - in /sis/site/trunk/book: en/body.html en/coverage.html en/geometry.html fr/body.html fr/coverage.html fr/geometry.html
Date Thu, 24 Sep 2015 16:52:13 GMT
Copied: sis/site/trunk/book/en/coverage.html (from r1678141, sis/site/trunk/content/book/en/developer-guide.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/coverage.html?p2=sis/site/trunk/book/en/coverage.html&p1=sis/site/trunk/content/book/en/developer-guide.html&r1=1678141&r2=1705105&rev=1705105&view=diff
==============================================================================
--- sis/site/trunk/content/book/en/developer-guide.html [UTF-8] (original)
+++ sis/site/trunk/book/en/coverage.html [iso-8859-1] Thu Sep 24 16:52:13 2015
@@ -22,2181 +22,76 @@
 
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
   <head>
-    <title>Introduction to Apache SIS</title>
-    <link rel="stylesheet" type="text/css" href="../book.css"/>
+    <title>Data Coverages</title>
+    <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
   </head>
   <body>
-    <!-- From this point, shift indentation 4 spaces to the left for saving space. -->
-
-<p style="margin-top: 30pt"><span style="font-size: 30pt; font-weight: 900">Introduction to Apache SIS®</span></p>
-<p style="margin-bottom: 20pt">(English | <a href="../fr/developer-guide.html">Français</a>)</p>
-<p><i>Martin Desruisseaux</i><br/>
-<i>Christina Hough</i></p>
-<p>This work is licensed under the Apache 2 license.</p>
-<hr/>
-
-<p><b style="font-size: 20pt">Table of content</b></p>
-
-<ul class="toc">
-  <li><a href="#Foreword">Foreward</a><ul>
-    <li><a href="#About">Conventions Used in This Guide</a></li>
-  </ul></li>
-  <li><a href="#Standards">Standards and Norms</a><ul>
-    <li><a href="#OGC-process"><abbr>OGC</abbr> Standardization Process</a><ul>
-      <li><a href="#OGC-SWG">Standard Working Group (<abbr>SWG</abbr>) Procedures</a></li>
-      <li><a href="#OGC-OAB">The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</a></li>
-      <li><a href="#OGC-RFC">Procedure for the Submission of Proposals for Modification</a></li>
-    </ul></li>
-    <li><a href="#SpecificationTypes">Different Types of Specifications</a></li>
-    <li><a href="#DefinitionOfTerms">Definition of Terms</a></li>
-  </ul></li>
-  <li><a href="#GeoAPI">GeoAPI</a><ul>
-    <li><a href="#SpecificationToInterfaces">Interface Specifications</a><ul>
-      <li><a href="#UML-annotation">Mapping Given by <code>@UML</code> Annotations</a></li>
-      <li><a href="#MappingToJDK">Implicit Mapping to Standard <abbr>JDK</abbr></a></li>
-    </ul></li>
-    <li><a href="#ServiceLoader">Fetching an Implementation of the Interfaces</a><ul>
-      <li><a href="#GeoAPI-simple">Defining Custom Implementations</a></li>
-    </ul></li>
-    <li><a href="#GeoAPI-modules">GeoAPI Modules</a><ul>
-      <li><a href="#GeoAPI-core">The Interfaces' Definition Modules</a></li>
-      <li><a href="#GeoAPI-conformance">The Conformance Tests Module</a><ul>
-        <li><a href="#GeoAPI-validators">Instance Validations</a></li>
-        <li><a href="#GeoAPI-tests">Executing Pre-defined Tests</a></li>
-      </ul></li>
-      <li><a href="#GeoAPI-examples">Example Modules</a></li>
-    </ul></li>
-  </ul></li>
-  <li><a href="#XML-ISO">Representing Objects in <abbr>XML</abbr></a><ul>
-    <li><a href="#XML-ISO-19115">Representing Metadata According to <abbr>ISO</abbr> 19115-3</a><ul>
-      <li><a href="#gco-id">Identification of Already-Defined Instances</a></li>
-      <li><a href="#nilReason">Representing Missing Values</a></li>
-    </ul></li>
-  </ul></li>
-  <li><a href="#Utilities">Utility Classes and Methods</a><ul>
-    <li><a href="#ComparisonMode">Comparison Modes of Objects</a></li>
-    <li><a href="#Internationalization">Internationalization</a><ul>
-      <li><a href="#LocalizedString">Distinct Character Sequences for Each Locale</a></li>
-      <li><a href="#InternationalString">Single Instance in All Locale Conventions</a></li>
-      <li><a href="#Locale.ROOT"><code>Locale.ROOT</code> Convention</a></li>
-      <li><a href="#UnicodePoint">Treatment of Characters</a><ul>
-        <li><a href="#Whitespaces">The Interpretation of Blank Spaces</a></li>
-      </ul></li>
-    </ul></li>
-  </ul></li>
-  <li><a href="#Geometry">Geometries</a><ul>
-    <li><a href="#Geometry-root">Base Classes</a><ul>
-      <li><a href="#DirectPosition">Direct Points and Positions</a></li>
-      <li><a href="#Envelope">Envelopes</a><ul>
-        <li><a href="#AntiMeridian">Envelopes that Cross the Antimeridian</a></li>
-      </ul></li>
-    </ul></li>
-  </ul></li>
-  <li><a href="#Coverage">Data Coverages</a></li>
-</ul>
-
-
-<h1 id="Foreword">Foreward</h1>
-<p>
-  A geospatial information community is a collection of systems or individuals capable of exchanging their geospatial data
-  through the use of common standards, allowing them to communicate with one another.
-  As there are many ways to represent geospatial information, each community tends to structure this information in light of its areas of interest.
-  This diversity complicates the task of Spatial Information System (<abbr>SIS</abbr>) users
-  by confronting them with an apparently chaotic variety of data formats and structures.
-  The characteristics of these structures vary according to the observed phenomenon and measurement methods,
-  as well as the habits of the organizations producing the data.
-  Such a variety represents an obstacle in studies that require heterogeneous combinations of data,
-  especially when they originate in communities that are traditionally distinct.
-  For example, a researcher studying cholera might be interested in populations of shrimp as a propagation vector of the disease.
-  But as doctors and oceanographers may not be used to share their work,
-  the participants of such a study may be limited by the effort required to convert the data.
-</p><p>
-  We cannot impose a uniform format on all data collections, as the diversity of formats is tied to factors such as the constraints imposed by the measuring apparatus,
-  and the statistical distribution of values.
-  A more flexible solution is to ensure the interoperability of data across a common programming interface
-  (<abbr title="Application Programming Interface">API</abbr>).
-  This <abbr>API</abbr> is not necessarily defined in a programming language;
-  the actual tendency is rather to define conventions that use existing web protocols, which we can translate into various programming languages.
-  But in order for this approach to be viable, the <abbr>API</abbr> must be generally accepted by independent developers.
-  In other words, the <abbr>API</abbr> must come as near as possible to industrial standards.
-</p><p>
-  For example, one task that benefit from a successful standardization is the accessing of relational databases.
-  The industry has established a common language — the <abbr title="Structured Query Language">SQL</abbr> standard — that the creators of Java
-  have embedded in standard <abbr title="Java DataBase Connectivity">JDBC</abbr> programming interfaces.
-  Today, these interfaces are implemented by many software programs, both free and commercial.
-  Like databases, methods of accessing geographic information have been standardized.
-  In this case, however, the efforts have been more recent, and their integration in software — especially in older programs — is incomplete and not always coherent.
-  At the time of writing, no product to our knowledge has implemented all of the specifications in their entirety.
-  However, there are many implementations that cover a fairly large spectrum.
-  One of these is the Apache <abbr>SIS</abbr>® library that is described in this document.
-</p><p>
-  Apache <abbr title="Spatial Information System">SIS</abbr> is characterized by a sustained effort to comply with standards,
-  going so far as to participate in certain <abbr title="Open Geospatial Consortium">OGC</abbr> projects.
-  In general, complying with standards demands a greater effort than would be required for an isolated development,
-  but rewards us with a double advantage: not only does it improve the interoperability of our data with that of external projects,
-  it also points towards a robust way of elaborating the conceptual model reflected in the <abbr title="Application Programming Interface">API</abbr>.
-  In effect, the groups of experts who conceived the standards anticipated difficulties that sometimes escape the engineer at the beginning of a project,
-  but which risk to hit them before the end.
-</p>
-
-
-
-<h2 id="About">Conventions Used in This Guide</h2>
-<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 order to facilitate an understanding of the relationships between Apache <abbr>SIS</abbr> and the standards, these elements are also represented using the following colour codes:
-</p>
-<ul>
-  <li>
-    Elements defined in the <abbr title="Open Geospatial Consortium">OGC</abbr> standard
-    or the <abbr title="International Organization for Standardization">ISO</abbr> standard appear in blue.
-    Example: <code class="OGC">CD_Ellipsoid</code>.
-  </li>
-  <li>
-    Elements defined in GeoAPI appear in green.
-    Example: <code class="GeoAPI">Ellipsoid</code>.
-  </li>
-  <li>
-    Elements defined in Apache <abbr title="Spatial Information System">SIS</abbr> appear in brown.
-    Example: <code class="SIS">DefaultEllipsoid</code>.
-  </li>
-  <li>
-    Other elements, such as those in standard Java, are left in black.
-    Example: <code>String</code>.
-  </li>
-</ul>
-<p>
-  Text in gray boxes are for information purpose only and can be ignored.
-</p>
-
-
-
-<h1 id="Standards">Standards and Norms</h1>
-<p>
-  Most standards used by Apache <abbr title="Spatial Information System">SIS</abbr> have been devised by the <a href="http://www.opengeospatial.org">Open Geospatial Consortium</a> (<abbr>OGC</abbr>),
-  sometimes in collaboration with the <a href="http://www.iso.org">International Organization for Standardization</a> (<abbr>ISO</abbr>).
-  Some <abbr>ISO</abbr> standards themselves become European standards via the <a href="http://inspire.jrc.ec.europa.eu">INSPIRE Directive</a>.
-  These standards offer two key features:
-</p>
-<ul>
-  <li>
-    Allowing a community to make its information public in such a way that outside individuals or systems can discover it.
-  </li>
-  <li>
-    Transferring information from one community to another while preserving its semantics,
-    even if the two communities use very different internal representations.
-  </li>
-</ul>
-<p>
-  These standards are made available to the international community for free, as <a href="http://www.opengeospatial.org/standards/is">specifications (<abbr title="Portable Document Format">PDF</abbr> files)</a> or as <a href="http://schemas.opengis.net/gml/3.3/">schemas (<abbr title="XML Schema Definition">XSD</abbr> files)</a>.
-  Standardization organizations do not create software; to obtain an implementation of these specifications,
-  users must choose one of the compliant products available on the market, or develop their own solutions.
-  Such voluntary compliance with these specifications allow independent communities to more easily exchange geographic information.
-</p><p>
-  Besides these formal standardization organizations, there are organizations that are not officially dedicated
-  to the creation of standards, but whose work has largely been adopted as <i>de facto</i> standards.
-  In particular, the <a href="http://www.epsg.org">EPSG</a> database offers numeric codes which allow the easy identification of a
-  Coordinates Reference System (<abbr>CRS</abbr>) among <a href="../sis-referencing/supported-codes.html">several thousand</a>.
-  This database is offered by petroleum companies that have an interest in ensuring their explorations are conducted in the correct place,
-  even when using map produced by another party.
-  Other examples of <i>de facto</i> standards include <a href="http://geotiff.osgeo.org">GeoTIFF</a> for data distributed on a grid (such as images),
-  and <a href="http://en.wikipedia.org/wiki/Shapefile">Shapefile</a> for vector data (such as geometric shapes).
-</p>
-
-
-
-<h2 id="OGC-process"><abbr>OGC</abbr> Standardization Process</h2>
-<p>
-  The work of the <abbr title="Open Geospatial Consortium">OGC</abbr> is done by email, teleconferences, and at <a href="http://www.opengeospatial.org/event?category=ogctcpc">in-person meetings</a>.
-  The <abbr>OGC</abbr> organizes four meetings per year, each lasting five days, and hosted by member organizations that sponsor the event (companies, universities, research centres, <i>etc</i>).
-  The host continent alternates between Europe and North America, with a growing presence in Asia since 2011.
-  These meetings are usually attended by between 50 and 100 participants from among the hundreds of members of the <abbr>OGC</abbr>.
-  Some participants are present at almost all the meetings, forming the pillars of the organization.
-  The meetings of the <abbr title="Open Geospatial Consortium">OGC</abbr> offer opportunities for exchange among members from diverse backgrounds.
-</p><p>
-  The creation of a <abbr>OGC</abbr> standard begins with a gathering of organizations or individuals with a common interest in an issue.
-  A working group is proposed as a <i>Discussion Working Group</i> (<abbr>DWG</abbr>) if the work is still in the exploratory stages,
-  or as a <i>Standard Working Group</i> (<abbr>SWG</abbr>) if the work of standardization is ready to proceed.
-  <abbr>DWG</abbr>s are open to all members of the <abbr>OGC</abbr>,
-  while <abbr>SWG</abbr>s require that their participants enter into an agreement not to hinder the distribution of the standard through intellectual property claims.
-</p>
-
-
-
-<h3 id="OGC-SWG">Standard Working Group (<abbr>SWG</abbr>) Procedures</h3>
-<p>
-  In order to be accepted, a standardization project must be supported by a minimum number of members belonging to distinct organizations.
-  These founding members draft a charter defining the objectives of the <abbr title="Standard Working Group">SWG</abbr>,
-  which must be approved by the Technical Committee of the <abbr title="Open Geospatial Consortium">OGC</abbr>.
-  Each founding member is endowed with the right to vote, with a limit of one voting member per organization.
-  Each new member that wishes to join the <abbr>SWG</abbr> after its creation is granted the role of observer,
-  and receives on request the right to vote after several months of observation.
-</p><p>
-  A <abbr title="Standard Working Group">SWG</abbr> may contain several dozen members,
-  but the volunteers performing the bulk of the work are usually fewer.
-  Their proposals are submitted to the entire membership of the group, who may accept them by unanimous consent.
-  Any objections must be debated, and an alternative proposed.
-  <abbr>SWG</abbr>s usually try to debate an issue until a consensus emerges rather than move ahead despite negative votes,
-  even if those opposed are in a minority.
-  The decisions of the group are then integrated into the specifications by a member who assumes the role of editor.
-</p><p>
-  As far as possible, the working group must structure the specifications as a core around which various extensions might be built.
-  A series of tests must accompany the standard, allowing implementations to be classified by the level of test passed.
-  There must be at least one <i>reference implementation</i> that passes all the tests in order to demonstrate that the standard is usable.
-</p><p>
-  When the standard is considered ready, the <abbr title="Standard Working Group">SWG</abbr> votes on a motion
-  proposing its submission to a vote by the higher authorities of the <abbr title="Open Geospatial Consortium">OGC</abbr>.
-  This process takes several months.
-  There is a faster process for approving <i>de facto</i> standards, but it is applied sparingly.
-</p>
-
-
-<h3 id="OGC-OAB">The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</h3>
-<p>
-  All proposals for standards are first examined by the <abbr title="Open Geospatial Consortium">OGC</abbr> Architecture Board (<abbr>OAB</abbr>).
-  This board ensures that the standard conforms to the requirements of the <abbr title="Open Geospatial Consortium">OGC</abbr> in form,
-  modularization, and in terms of integration with other standards.
-  If the <abbr>OAB</abbr> approves it, the standard is next submitted to a vote by the members of the Technical Committee (<abbr title="Technical Committee">TC</abbr>).
-  This committee consists of the principal members of the <abbr>OGC</abbr>, and only they are capable of granting final approval.
-  If approved, the standard is made publicly available for comments during a period of several months.
-  At the end of this period, the <abbr title="Standard Working Group">SWG</abbr> must examine and respond to each comment.
-  The eventual modifications of the standard are submitted to the <abbr>OAB</abbr>, then the standard is published in its final form.
-  This distribution is announced in a press release by the <abbr>OGC</abbr>.
-</p><p>
-  Certain members of the <abbr title="Open Geospatial Consortium">OGC</abbr> and the <abbr title="Technical Committee">TC</abbr> also act as liaisons with the International Organization for Standardization (<abbr title="International Organization for Standardization">ISO</abbr>).
-  Cooperation between the two organizations goes two ways: the <abbr>OGC</abbr> adopts the <abbr>ISO</abbr> standards as a foundation on which to develop new standards,
-  and certain <abbr>OGC</abbr> standards become <abbr>ISO</abbr> standards.
-</p>
-
-
-
-
-<h3 id="OGC-RFC">Procedure for the Submission of Proposals for Modification</h3>
-<p>
-  All users, whether or not they are members of the Open Geospatial Consortium, may propose modifications to <abbr title="Open Geospatial Consortium">OGC</abbr> standards.
-  A list of current proposals for changes, along with a form for submitting new proposals, is <a href="http://www.opengeospatial.org/standards/cr">available online</a>.
-  Each proposal is reviewed by the <abbr title="Standard Working Group">SWG</abbr>.
-</p><p>
-  Some working groups use other parallel systems for submissions.
-  In particular, the GeoAPI project continues to use a <a href="http://jira.codehaus.org/browse/GEO">JIRA task system</a>
-  hosted outside of the structures of the <abbr title="Open Geospatial Consortium">OGC</abbr>.
-  This set-up exists in part for historical reasons, and in part because developments on the GeoAPI project are done more at the level of source code rather than at the level of documents or class diagrams.
-</p>
-
-
-
-<h2 id="SpecificationTypes">Different Types of Specifications</h2>
-<p>
-  <abbr title="Open Geospatial Consortium">OGC</abbr> standards are specified in several dozen documents.
-  Each document outlines a service — for example, the transformation of coordinates.
-  The function of each service is described by a collection of object classes and their interactions.
-  These elements are illustrated by <abbr>UML</abbr> (Unified Modeling Language) diagrams in specifications called “abstracts”.
-</p><p>
-  <a href="http://www.opengeospatial.org/standards/as">Abstract specifications</a> do not refer to any specific computer language.
-  Their concepts may be applied more or less directly to a programming language, a database or an <abbr>XML</abbr> schema.
-  There is always an element of arbitrariness in the method of applying an abstract specification,
-  given that adjustments are often necessary to take into account the constraints or conventions of the target language. For example:
-</p>
-<ul>
-  <li>
-    Attempts to support an object-oriented paradigm result in a verbose approach in certain languages
-    (notably the <abbr>XML</abbr> defined by <abbr>ISO</abbr> 19139) — for example, in order to support polymorphism.
-  </li>
-  <li>
-    Certain data structures only exist in a few languages — for example, unions that exist in C/C++ but not in Java.
-  </li>
-  <li>
-    Certain specifications (especially older ones) define operations which lend themselves easily to programming languages or services,
-    but not to databases.
-  </li>
-</ul>
-<p>
-  At the turn of the millennium, the abstract specifications were explicitly concretized in <i>implementation specifications</i>.
-  The term “implementation” is used here in the sense of all types of interfaces (Java or others) derived from <abbr title="Unified Modeling Language">UML</abbr> diagrams, and not implementations in the Java sense.
-  Such specifications existed for <abbr title="Structured Query Language">SQL</abbr>, <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr>, and Java languages.
-  As these languages are capable of executing procedures, the specifications of this period define not only data structures,
-  but also operations that apply to these structures.
-</p><p>
-  Thereafter, enthusiasm for “Web 2.0” increased interest for <abbr>XML</abbr> over other languages.
-  Older implementation specifications were deprecated,
-  and <abbr title="XML Schema Definition">XSD</abbr> schemas became the main concretization of abstract specifications.
-  Even the way abstract specifications are designed has evolved: they are less likely to define operations, and so what remains is closer to descriptions of database schemas.
-  Some operations that were defined in older standards now appear, in another form, in web service specifications.
-  Finally, the term “implementation specification” has been deprecated, to be subsumed under the term “<abbr title="Open Geospatial Consortium">OGC</abbr> standard.”
-  But despite their depreciation, <a href="http://www.opengeospatial.org/standards/retired">old implementation specifications</a> remain useful to programs in Java, because:
-</p>
-<ul>
-  <li>
-    Their simpler models, applied to the same concepts, are helpful in understanding new specifications.
-  </li>
-  <li>
-    They sometimes define easy ways to perform common tasks, where the newer specifications limit themselves to general cases.
-  </li>
-  <li>
-    As operations are more often omitted from the newer specifications,
-    the old ones remain a useful supplement when defining <abbr title="Application Programming Interface">API</abbr>s.
-  </li>
-</ul>
-<p>
-  The Apache <abbr title="Spatial Information System">SIS</abbr> project is based on the most recent specifications, drawing from the archives of the <abbr title="Open Geospatial Consortium">OGC</abbr> to complete certain abstract standards or make them more usable.
-  Some old definitions are preserved as “convenience methods”, not always bringing new functionality, but facilitating the practical use of a library.
-</p><p>
-  The following table lists the main norms used by the project.
-  Many norms are published both as <abbr title="International Organization for Standardization">ISO</abbr> standards and as
-  <abbr title="Open Geospatial Consortium">OGC</abbr> standards, and their corresponding names are listed next to one another in the first two columns.
-  Standards that are deprecated but still used appear <s>struck through</s>.
-  Finally, GeoAPI packages will be introduced in upcoming chapters.
-</p>
-<table>
-  <caption>Main Standards Used in the Apache <abbr>SIS</abbr> project</caption>
-  <tr>
-    <th><abbr>ISO</abbr> Norm</th>
-    <th><abbr>OGC</abbr> Norm</th>
-    <th>Titre</th>
-    <th>GeoAPI package</th>
-    <th>Apache SIS package</th>
-  </tr>
-  <tr>
-    <td class="separator" colspan="5">Abstract Specifications</td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19103</td>
-    <td></td>
-    <td><i>Conceptual schema language</i></td>
-    <td><code>org.opengis.util</code></td>
-    <td><code>org.apache.sis.util.iso</code></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19115</td>
-    <td>Topic 11</td>
-    <td><i>Metadata</i></td>
-    <td><code>org.opengis.metadata</code></td>
-    <td><code>org.apache.sis.metadata.iso</code></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19111</td>
-    <td>Topic 2</td>
-    <td><i>Spatial referencing by coordinates</i></td>
-    <td><code>org.opengis.referencing</code></td>
-    <td><code>org.apache.sis.referencing</code></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19108</td>
-    <td></td>
-    <td><i>Temporal Schema</i></td>
-    <td><code>org.opengis.temporal</code></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19107</td>
-    <td>Topic 1</td>
-    <td><i>Feature geometry</i></td>
-    <td><code>org.opengis.geometry</code></td>
-    <td><code>org.apache.sis.geometry</code></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19101</td>
-    <td>Topic 5</td>
-    <td><i>Features</i></td>
-    <td><code>org.opengis.feature</code></td>
-    <td><code>org.apache.sis.feature</code></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19123</td>
-    <td>Topic 6</td>
-    <td><i>Schema for coverage geometry and functions</i></td>
-    <td><code>org.opengis.coverage</code></td>
-    <td><code>org.apache.sis.coverage</code></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19156</td>
-    <td>Topic 20</td>
-    <td><i>Observations and measurements</i></td>
-    <td><code>org.opengis.observation</code></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td class="separator" colspan="5">Implementation Specifications</td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19139</td>
-    <td></td>
-    <td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
-    <td></td>
-    <td><code>org.apache.sis.xml</code></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 13249</td>
-    <td></td>
-    <td><i><abbr>SQL</abbr> spatial</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><s><abbr>OGC</abbr> 01-009</s></td>
-    <td><s><i>Coordinate Transformation Services</i></s></td>
-    <td><code>org.opengis.referencing</code></td>
-    <td><code>org.apache.sis.referencing</code></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><s><abbr>OGC</abbr> 01-004</s></td>
-    <td><s><i>Grid Coverage</i></s></td>
-    <td><code>org.opengis.coverage</code></td>
-    <td><code>org.apache.sis.coverage</code></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><abbr>SLD</abbr></td>
-    <td><i>Styled Layer Descriptor</i></td>
-    <td><code>org.opengis.style</code></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td class="separator" colspan="5">Web Services</td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19128</td>
-    <td><abbr>WMS</abbr></td>
-    <td><i>Web Map Service</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><abbr>WMTS</abbr></td>
-    <td><i>Web Map Tile Service</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td><abbr>ISO</abbr> 19142</td>
-    <td><abbr>WFS</abbr></td>
-    <td><i>Web Feature Service</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><abbr>WCS</abbr></td>
-    <td><i>Web Coverage Service</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><abbr>WPS</abbr></td>
-    <td><i>Web Processing Service</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td>Open<abbr>LS</abbr></td>
-    <td><i>Location Services</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><abbr>SWE</abbr></td>
-    <td><i>Sensor Web Enablement</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-  <tr>
-    <td></td>
-    <td><abbr>SOS</abbr></td>
-    <td><i>Sensor Observation Service</i></td>
-    <td></td>
-    <td></td>
-  </tr>
-</table>
-
-
-
-<h2 id="DefinitionOfTerms">Definition of Terms</h2>
-<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 functions in order to designate
-  a set of possible values of inputs and outputs respectively.
-  But the functions to which they are applied by certain <abbr title="International Organization for Standardization">ISO</abbr> standards are not the same as the functions to which they are applied by other libraries.
-  For example, <abbr>ISO</abbr> 19123 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.
-  But <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 of 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 title="International Organization for Standardization">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>
-
-
-
-<h1 id="GeoAPI">GeoAPI</h1>
-<p>
-  The <a href="http://www.geoapi.org">GeoAPI</a> project offers a set of Java interfaces for geospatial applications.
-  In a series of <code class = "GeoAPI"> org.opengis.*</code> packages, GeoAPI defines structures representing metadata,
-  coordinate reference systems and operations that perform cartographic projections.
-  In a part that is not yet standardized — called <i>pending</i> — GeoAPI defines structures that represent geo-referenced images,
-  geometries, filters that can be applied to queries, and other features.
-  These interfaces closely follow the specifications of the <abbr title = "Open Geospatial Consortium">OGC</abbr>,
-  while interpreting and adapting them to meet the needs of Java developers — for example, conforming with naming conventions.
-  These interfaces benefit both client applications and libraries:
-</p>
-<ul>
-  <li><p>
-    Developers of client applications benefit from the greater knowledge base available on the Internet
-    (due to the many publications related to <abbr title="Open Geospatial Consortium">OGC</abbr> standards), as well as increased interoperability.
-    Interoperability is facilitated by a better separation between applications that <em>call</em> GeoAPI functions,
-    and libraries that <em>implement</em> GeoAPI.
-    The separation is similar to that offered by the <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/"><abbr>JDBC</abbr></a> (<i>Java Database Connectivity</i>) interfaces of standard Java.
-    Using the interfaces' <abbr title="Application Programming Interface">API</abbr>,
-    developers can ignore the underlying implementation.
-    For example, they can perform cartographic projections with the help of the <a href="http://www.geoapi.org/geoapi-proj4/index.html">Proj.4</a> library, or the Apache <abbr title="Spatial Information System">SIS</abbr> library,
-    without having to change their programs when they change libraries.
-  </p></li>
-  <li><p>
-    The developers of libraries inherit the expertise of the specifications' authors,
-    via the models that represent interfaces.
-    GeoAPI also provides a framework within which developers can prioritize the implementation of the features they most need,
-    while leaving the remaining features as extension points for future developments.
-    For example, clients can call a GeoAPI function even if it is not yet supported by the library,
-    and simply get a null value until a new version of the library returns a relevant value.
-  </p></li>
-</ul>
-
-<aside>
-  <p><b>History</b></p>
-  <p>
-    In 2001, the Open GIS Consortium (the former name of the Open Geospatial Consortium) published
-    <a href="http://www.opengeospatial.org/standards/ct"><abbr>OGC</abbr> implementation specification 01-009:
-    <cite>Coordinate Transformation Services</cite></a>.
-    This specification, developed by the Computer Aided Development Corporation (Cadcorp),
-    was accompanied by <abbr title="Component Object Model">COM</abbr>,
-    <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, and Java interfaces.
-    At this time, the wave of web services had not yet eclipsed classical programming interfaces.
-    The interfaces of the <abbr title="Open Geospatial Consortium">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>”.
-    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 <a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">call
-    for the creation of a geospatial <abbr title="Application Programming Interface">API</abbr></a>.
-    The initial proposal attracted the interest of at least five free projects.
-    The project was created using <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
-    which has since hosted the source code in a <a href="http://www.geoapi.org/source-repository.html">Subversion repository</a>.
-    It was then that the project assumed the name “GeoAPI”, and used the interfaces of the <abbr>OGC</abbr> specification 01-009 as a starting point.
-  </p><p>
-    A few months later, the <abbr title="Open Geospatial Consortium">OGC</abbr> launched the <a href="http://www.opengeospatial.org/standards/go"><abbr>GO</abbr>-1: <i>Geographic Objects</i></a> project,
-    which pursued goals similar to those of GeoAPI.
-    In the meantime, the <abbr>OGC</abbr> abandonned some of their specifications in favor of <abbr title="International Organization for Standardization">ISO</abbr> standards.
-    GeoAPI and <abbr>GO-1</abbr> worked jointly to rework the GeoAPI interfaces and base them on the new <abbr>ISO</abbr> norms.
-    Their first interation, <a href="http://www.geoapi.org/1.0/index.html">GeoAPI 1.0</a>,
-    served as a starting point for the first draft of the <abbr>OGC</abbr> specification 03-064 by the <abbr>GO</abbr>-1 working group.
-    The final version of this specification became an <abbr>OGC</abbr> standard in 2005,
-    and <a href="http://www.geoapi.org/2.0/index.html">GeoAPI 2.0</a> was published at that time.
-  </p><p>
-    The <abbr>GO</abbr>-1 project was largely supported by a company called <i>Polexis</i>.
-    Its acquisition by <i>Sys Technology</i>, and the change in priorities under the new owners,
-    brought a halt to the <abbr>GO</abbr>-1 project, which in turn slowed development on GeoAPI.
-    In order to resume development, a new working group entitled “GeoAPI 3.0” was created at the <abbr title="Open Geospatial Consortium">OGC</abbr>.
-    This group took a narrower focus compared to GeoAPI 2.0, concentrating on the most stable interfaces, and putting the others
-    — such as geometries — in a module entitled “<a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a>”, for future consideration.
-    <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> became an <a href="http://www.opengeospatial.org/standards/geoapi"><abbr>OGC</abbr> standard</a> in 2011.
-    This version was the first to be deployed in the <a href="http://search.maven.org/#search|ga|1|geoapi">Maven central repository</a>.
-  </p>
-</aside>
-
-
-<h2 id="SpecificationToInterfaces">Interface Specifications</h2>
-<p>
-  Since <abbr title="Open Geospatial Consortium">OGC</abbr> standards are defined by well-tested software engineering methods,
-  it is possible to automatically generate Java interfaces using relatively common tools.
-  One of the most commonly-used approaches is to transform <a href="http://schemas.opengis.net/gml/3.3/"><abbr>XSD</abbr> schemas</a>
-  into Java interfaces using command line utility <code>xjc</code>.
-  As this utility is included in most Java distributions (it is one of the <a href="http://jaxb.java.net"><abbr>JAXB</abbr></a> tools),
-  this approach is favoured by many projects found on the Internet.
-  Other approaches use tools integrated into the Eclipse Development Environment,
-  which is based on <abbr title="Unified Modeling Language">UML</abbr> schemas rather than <abbr title="XML Schema Definition">XSD</abbr> ones.
-</p><p>
-  A similar approach was attempted in the early days of the GeoAPI project, but was quickly abandoned.
-  We favor a manual approach for the following reasons:
-</p>
-<ul>
-  <li>
-    <p>
-      Some <abbr title="XML Schema Definition">XSD</abbr> schemas are much more verbose than the original <abbr title="Unified Modeling Language">UML</abbr> schemas.
-      Converting from <abbr>XSD</abbr> schemas introduces — at least in the case of metadata —
-      almost double the number of interfaces actually defined by the standard, without adding any new features.
-      <abbr>XSD</abbr> schemas also define attributes specific to <abbr>XML</abbr> documents (<code class="OGC">id</code>,
-      <code class="OGC">uuid</code>, <code>xlink:href</code>, <i>etc.</i>), that do not exist in the original <abbr>UML</abbr> diagrams,
-      and which we do not necessarily wish to expose in a Java <abbr title="Application Programming Interface">API</abbr>.
-      Converting from <abbr>UML</abbr> schemas avoids this problem, but tools capable of performing this operation are less common.
-    </p>
-    <div class="example"><p><b>Example:</b>
-      <abbr title="XML Schema Definition">XSD</abbr> metadata schemas insert a <code class="OGC">&lt;gmd:CI_Citation&gt;</code> element
-      inside a <code class="OGC">&lt;gmd:citation&gt;</code>,
-      a <code class="OGC">&lt;gmd:CI_OnlineResource&gt;</code> element inside a <code class="OGC">&lt;gmd:onlineResource&gt;</code>,
-      and so on for the hundreds of classes defined by <abbr>ISO</abbr> 19115 standard.
-      This redundancy is certainly not necessary in a Java program.
-    </p></div>
-  </li>
-  <li>
-    <p>
-      <abbr title="Open Geospatial Consortium">OGC</abbr> standards use different naming conventions than Java.
-      In particular, the names of almost all <abbr>OGC</abbr> classes begin with a two-letter prefix,
-      such as <code class="OGC">MD_Identifier</code>.
-      This prefixes fulfill the same role as package names in Java.
-      GeoAPI adapts this practice by using interface names without prefixes and placing these interfaces in packages corresponding to the prefixes,
-      but with more descriptive names.
-      Occasionally we also change the names; for example, to avoid acronyms, or to conform to an established convention such as JavaBeans.
-    </p>
-    <div class="example"><p><b>Example:</b>
-      The <abbr title="Open Geospatial Consortium">OGC</abbr> class <code class="OGC">MD_Identifier</code> becomes the
-      <code class="GeoAPI">Identifier</code> interface in the <code class="GeoAPI">org.opengis.metadata</code> package.
-      The <abbr>OGC</abbr> class <code class="OGC">SC_CRS</code> becomes the <code class="GeoAPI">CoordinateReferenceSystem</code> interface,
-      and the <code class="OGC">usesDatum</code> association becomes a <code class="GeoAPI">getDatum()</code> method,
-      rather than the “<code>getUsesDatum()</code>” that would result from an automatic conversion tool.
-      We do not allow programs to blindly apply rules that ignore the conventions of the community whose schemas we translate.
-    </p></div>
-  </li>
-  <li>
-    <p>
-      The standards may contain structures that do not have a direct equivalent in Java,
-      such as unions similar to what we would find in C/C++.
-      The strategy used to obtain an equivalent feature in Java depends on the context:
-      multiple inheritance of interfaces, modification of the hierarchy, or simply omitting the union.
-      These decisions are made case-by-case based on a needs analysis.
-    </p>
-    <div class="example"><p><b>Example:</b>
-      <abbr>ISO</abbr> 19111 standard defines different types of coordinate systems, such as spherical, cylindrical, polar or Cartesian.
-      It then defines several <em>subsets</em> of these types of coordinate systems systems.
-      These subsets, represented by unions, serve to specify that a class may only be associated with a particular type of coordinate system.
-      For example, a union of types may be associated with an image, named <code class="OGC">CS_ImageCS</code>,
-      which can only contain <code class="OGC">CS_CartesianCS</code> and <code class="OGC">CS_AffineCS</code>.
-      In this case, we get the desired effect in Java through a modification of the hierarchy of classes:
-      we define the <code class="GeoAPI">CartesianCS</code> interface as a specialization of <code class="GeoAPI">AffineCS</code>,
-      which is semantically correct.
-      But it is not possible to apply a similar strategy to other unions without violating the semantics.
-    </p></div>
-  </li>
-  <li>
-    <p>
-      Several specifications overlap.
-      GeoAPI performs the work of integration by replacing some duplicate structures with references to equivalent structures from the standards that best represent them.
-    </p>
-    <div class="example"><p><b>Example:</b>
-      <abbr>ISO</abbr> 19115:2003 standard, which defines metadata structures,
-      also attempts to describe a few structures representing coordinate reference systems (<abbr title="Coordinate Reference System">CRS</abbr>).
-      Yet these are also the focus of another standard: <abbr>ISO</abbr> 19111.
-      At the same time, <abbr>ISO</abbr> 19111:2007 states in section 3 that it reuses all of the elements of
-      <abbr>ISO</abbr> 19115:2003 except <code class="OGC">MD_CRS</code> and its components.
-      GeoAPI interfaces reduce the redundancy by applying the exclusion recommended by <abbr>ISO</abbr> 19111 to the entire project.
-    </p></div>
-  </li>
-  <li>
-    <p>
-      The complexity of some standards have increased for historical reasons rather than technical ones, related to the standardization process.
-      GeoAPI reduces the technical debt by designing interfaces with each element in its proper place,
-      regardless of the chronological order in which the standards were published.
-    </p>
-    <div class="example"><p><b>Exemple:</b>
-      <abbr>ISO</abbr> 19115-2 standard is an extension of <abbr>ISO</abbr> 19115-1 standard, adding image metadata structures.
-      These metadata were defined in a separate standard because they were not yet ready when the first part of the standard was published.
-      As it was not possible for administrative reasons to add attributes to already-published classes,
-      the new attributes were added in a sub-class bearing almost the same name.
-      Thus, <abbr>ISO</abbr> 19115-2 defines the class <code class="OGC">MI_Band</code>,
-      which extends the class <code class="OGC">MD_Band</code> from <abbr>ISO</abbr> 19115-1 by adding attributes that would have appeared
-      directly in the parent class if there were ready on time.
-      In GeoAPI, we have chosen to “repair” these anomalies by fusing these two classes into a single interface.
-    </p></div>
-  </li>
-</ul>
-<p>
-  Deviations from the standards are documented in each affected class and method.
-  Each mention of a deviation is also collected on a <a href="http://www.geoapi.org/3.0/javadoc/departures.html">single page</a> in order to provide an overview.
-  Since these deviations blur the relationships between the standards and certain Java interfaces,
-  the correspondence between these languages is explained by <code class="GeoAPI">@UML</code> annotations and property files described in the following section.
-</p>
-
-
-
-<h3 id="UML-annotation">Mapping Given by <code>@UML</code> Annotations</h3>
-<p>
-  For each class, method and constant defined by an <abbr title="Open Geospatial Consortium">OGC</abbr> or <abbr title="International Organization for Standardization">ISO</abbr> standard,
-  GeoAPI indicates its provenance using annotations defined in the <code class="GeoAPI">org.opengis.annotation</code> package.
-  In particular, the <code class="GeoAPI">@UML</code> annotations indicates the standard,
-  the name of the element in that standard, and also its obligation.
-  For example, in the following code snippet, the first <code class="GeoAPI">@UML</code> code indicates that the Java interface that follows
-  (<code class="GeoAPI">ProjectedCRS</code>) is defined using the <code class="OGC">SC_ProjectedCRS</code> type of <abbr>ISO</abbr> 19111 standard.
-  The second <code class="GeoAPI">@UML</code> annotation, this time applied to the <code class="GeoAPI">getCoordinateSystem()</code> method,
-  indicates that this method is defined using the <code class="OGC">coordinateSystem</code> association of <abbr>ISO</abbr> 19111 standard,
-  and that this association is mandatory — meaning, in Java, that the method is not allowed to return a <code>null</code> value.
-</p>
-
-<pre><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>(<var>specification</var> = ISO_19111,
-     <var>identifier</var> = "<code class="OGC">SC_ProjectedCRS</code>")
-<b>public 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>(<var>obligation</var> = MANDATORY,
-         <var>specification</var> = ISO_19111,
-         <var>identifier</var> = "<code class="OGC">coordinateSystem</code>")
-    <code class="GeoAPI">CartesianCS getCoordinateSystem()</code>;
-}</pre>
-
-<p>
-  Java reflection methods allow access to this information during the execution of an application.
-  This is useful for displaying UML identifiers for users familiar with <abbr title="Open Geospatial Consortium">OGC</abbr> standards,
-  or for writing elements in an <abbr>XML</abbr> document.
-  The following example displays the standard name for the method <code class="GeoAPI">getTitle()</code> from the <code class="GeoAPI">Citation</code> interface:
-</p>
-
-<pre>Class&lt;?&gt; <var>type</var>   = <code class="GeoAPI">Citation</code>.class;
-Method   <var>method</var> = <var>type</var>.getMethod("<code class="GeoAPI">getTitle</code>", (Class&lt;?&gt;[]) null);
-<code class="GeoAPI">UML</code>      <var>annot</var>  = <var>method</var>.getAnnotation(<code class="GeoAPI">UML</code>.class);
-String   <var>id</var>     = <var>annot</var>.identifier();
-System.out.println("The standard name for the " + <var>method</var>.getName() + " method is " + <var>id</var>);</pre>
-
-<p>
-  The class <code class="SIS">org.apache.sis.util.iso.Types</code> provides the
-  <code class="SIS">getStandardName(Class)</code> convenience method to perform this operation.
-</p>
-
-<p>
-  The reverse operation — getting the Java class and method from a standard name — is a bit more complicated.
-  It requires reading the <code class="GeoAPI">class-index.properties</code> file provided in the <code class="GeoAPI">org.opengis.annotation</code> package.
-  The following example reads the files just before searching for the name of the interface corresponding to <code class="OGC">CI_Citation</code>.
-  Users are always encouraged to only read this file once and then save its contents in their application's cache.
-</p>
-
-<pre>Properties <var>isoToGeoAPI</var> = <b>new</b> Properties();
-<b>try</b> (InputStream in = <code class="GeoAPI">UML</code>.class.getResourceAsStream("<code class="GeoAPI">class-index.properties</code>")) {
-    <var>isoToGeoAPI</var>.load(in);
-}
-String <var>isoName</var> = "<code class="OGC">CI_Citation</code>";
-String <var>geoName</var> = getProperty(<var>isoName</var>);
-Class&lt;?&gt;  <var>type</var> = Class.forName(<var>geoName</var>);
-System.out.println("The GeoAPI interface for <abbr>ISO</abbr> type " + <var>isoName</var> + " is " + <var>type</var>);</pre>
-
-<p>
-  The class <code class="SIS">org.apache.sis.util.iso.Types</code> provides the
-  <code class="SIS">forStandardName(String)</code> convenience method to perform this operation.
-</p>
-
-
-
-<h3 id="MappingToJDK">Implicit Mapping to Standard <abbr>JDK</abbr></h3>
-<p>
-  Some classes and methods have neither an <code class="GeoAPI">@UML</code> annotation, nor an entry in the <code class="GeoAPI">class-index.properties</code> file.
-  They are either extensions of GeoAPI, or else types defined in other libraries, such as standard <abbr title="Java Development Kit">JDK</abbr>.
-  In this last case, the mapping to <abbr title="International Organization for Standardization">ISO</abbr> standards is implicit.
-  The following table describes this mapping for <abbr>ISO</abbr> 19103 types.
-  Java's primitive types are preferred when applicable,
-  but where necessary their wrappers are used in order to authorize null values.
-</p>
-<table>
-  <caption>Mapping between <abbr>ISO</abbr> 19103 and <abbr>JDK</abbr> types</caption>
-  <tr>
-    <th><abbr>ISO</abbr> type</th>
-    <th><abbr>JDK</abbr> type</th>
-    <th>Remarks</th>
-  </tr>
-  <tr>
-    <td class="separator" colspan="2">Numbers</td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Integer</code></td>
-    <td><code>int</code></td>
-    <td class="leftBorder">Sometimes <code>java.lang.Integer</code> for optional attributes.</td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Integer</code> (in some cases)</td>
-    <td><code>long</code></td>
-    <td class="leftBorder">Sometimes <code>java.lang.Long</code> for optional attributes.</td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Real</code></td>
-    <td><code>double</code></td>
-    <td class="leftBorder">Sometimes <code>java.lang.Double</code> for optional attributes.</td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Decimal</code></td>
-    <td><code>java.math.BigDecimal</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Number</code></td>
-    <td><code>java.lang.Number</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td class="separator" colspan="2">Texts</td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">FreeText</code></td>
-    <td>(no equivalent)</td>
-    <td class="leftBorder">See <code class="GeoAPI">org.opengis.util.InternationalString</code> below.</td>
-  </tr>
-  <tr>
-    <td><code class="OGC">CharacterString</code></td>
-    <td><code>java.lang.String</code></td>
-    <td class="leftBorder">Often <code class="GeoAPI">org.opengis.util.InternationalString</code> (see below).</td>
-  </tr>
-  <tr>
-    <td><code class="OGC">LocalisedCharacterString</code></td>
-    <td><code>java.lang.String</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Sequence&lt;Character&gt;</code></td>
-    <td><code>java.lang.CharSequence</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Character</code></td>
-    <td><code>char</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td class="separator" colspan="2">Dates and hours</td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Date</code></td>
-    <td><code>java.util.Date</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Time</code></td>
-    <td><code>java.util.Date</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">DateTime</code></td>
-    <td><code>java.util.Date</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td class="separator" colspan="2">Collections</td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Collection</code></td>
-    <td><code>java.util.Collection</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Bag</code></td>
-    <td><code>java.util.Collection</code></td>
-    <td class="leftBorder">A <code class="OGC">Bag</code> is similar to a
-        <code class="OGC">Set</code> without being restricted by uniqueness.</td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Set</code></td>
-    <td><code>java.util.Set</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Sequence</code></td>
-    <td><code>java.util.List</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Dictionary</code></td>
-    <td><code>java.util.Map</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">KeyValuePair</code></td>
-    <td><code>java.util.Map.Entry</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td class="separator" colspan="2">Enumerations</td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Enumeration</code></td>
-    <td><code>java.lang.Enum</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">CodeList</code></td>
-    <td>(no equivalent)</td>
-    <td class="leftBorder">See <code class="GeoAPI">org.opengis.util.CodeList</code> below.</td>
-  </tr>
-  <tr>
-    <td class="separator" colspan="2">Various</td>
-    <td class="leftBorder"></td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Boolean</code></td>
-    <td><code>boolean</code></td>
-    <td class="leftBorder">Sometimes <code>java.lang.Boolean</code> for optional attributes.</td>
-  </tr>
-  <tr>
-    <td><code class="OGC">Any</code></td>
-    <td><code>java.lang.Object</code></td>
-    <td class="leftBorder"></td>
-  </tr>
-</table>
-
-<p>
-  The nearest equivalent for <code class="OGC">CharacterString</code> is the <code>String</code> class,
-  but GeoAPI often uses the <code class="GeoAPI">InternationalString</code> interface, allowing the client to choose the language.
-  For example, it is useful on a server that simultaneously provides pages in multiple languages.
-  By returning translations when objects are used rather than at the time of their creation,
-  we allow the <abbr title="Spatial Information System">SIS</abbr> library to provide the same instances of <code class="GeoAPI">Metadata</code>
-  or <code class="GeoAPI">Coverage</code> (for example) for the same data, regardless of the client's language.
-  Translations may be made on the fly with the help of the application's <code>ResourceBundle</code>,
-  or may be provided directly with the data (as in the case of <code class="GeoAPI">Metadata</code>).
-</p>
-<p>
-  An <code class="OGC">Enumeration</code> corresponds to an <code>Enum</code> in Java.
-  Both define all authorized values, without allowing the user to add any.
-  A <code class="OGC">CodeList</code> is similar to an enumeration, except that users may add their own items.
-  Standard <abbr title="Java Development Kit">JDK</abbr> does not offer this possibility.
-  GeoAPI defines an abstract <code class="GeoAPI">CodeList</code> class that reproduces some of the functionality of <code>Enum</code> while being extensible.
-  Extensions are made available by the <code class="GeoAPI">valueOf(String)</code> static method, which, in contrast to <code>Enum</code>,
-  creates new instances if the name provided does not correspond to the name of an existing instance.
-</p>
-
-<pre><code class="GeoAPI">MediumName</code> <var>cdRom</var>  = <code class="GeoAPI">MediumName.CD_ROM;</code>
-<code class="GeoAPI">MediumName</code> <var>usbKey</var> = <code class="GeoAPI">MediumName.valueOf</code>("<code class="GeoAPI">USB_KEY</code>"); <code class="comment">// There is no constraint on this value.</code>
-<b>assert</b> <code class="GeoAPI">MediumName.valueOf</code>("<code class="GeoAPI">CD_ROM</code>")  == <var>cdRom</var>  : "valueOf must return existing constants.";
-<b>assert</b> <code class="GeoAPI">MediumName.valueOf</code>("<code class="GeoAPI">USB_KEY</code>") == <var>usbKey</var> : "valueOf must cache the previously requested values.";</pre>
-
-
-
-<h2 id="ServiceLoader">Fetching an Implementation of the Interfaces</h2>
-<p>
-  GeoAPI defines factories (<code class="GeoAPI">Factory</code>) that can create implementations of interfaces.
-  For example, <code class="GeoAPI">DatumFactory</code> provides methods that can create instances which implement interfaces of the
-  <code class="GeoAPI">org.opengis.referencing.datum</code> package.
-  A <code class="GeoAPI">Factory</code> must be implemented by a geospatial library,
-  and declared as a <i>service</i> as defined by the <code>java.util.ServiceLoader</code> class.
-  The <code>ServiceLoader</code> javadoc explains this procedure.
-  In brief, the library must create a file in the <code>META-INF/services/</code> directory,
-  with a name corresponding to the complete name of an interface in the factory
-  (in the preceding example, <code class="GeoAPI">org.opengis.referencing.datum.DatumFactory</code>).
-  On one line, this text file must include the complete name of the class that implements this interface.
-  This class may be hidden from users, as they do not need to know of its existence.
-</p>
-<p>
-  If the library has correctly declared its factories as services,
-  users may import them by using <code>ServiceLoader</code>, as in the example below.
-  This example only takes the first factory located; if there is more than one factory -
-  for example when multiple libraries coexist — then the choice is left to the user.
-</p>
-
-<pre><b>import</b> <code class="GeoAPI">org.opengis.referencing.GeodeticDatum</code>;
-<b>import</b> <code class="GeoAPI">org.opengis.referencing.DatumFactory</code>;
-<b>import</b> java.util.ServiceLoader;
-
-<b>public class</b> MyApplication {
-    <b>public void</b> createMyDatum() {
-        ServiceLoader  <var>loader</var> = ServiceLoader.load(<code class="GeoAPI">DatumFactory</code>.class);
-        <code class="GeoAPI">DatumFactory</code>  <var>factory</var> = <var>loader</var>.iterator().next();
-        <code class="GeoAPI">GeodeticDatum</code> <var>myDatum</var> = <var>factory</var>.<code class="GeoAPI">createGeodeticDatum</code>(…);
-    }
-}</pre>
-
-
-
-<h3 id="GeoAPI-simple">Defining Custom Implementations</h3>
-<p>
-  Implementing GeoAPI oneself in order to meet very specific needs is not difficult.
-  A developer might concentrate on a handful of interfaces among the hundreds available,
-  while keeping other interfaces as extension points to eventually implement as needed.
-</p>
-<p>
-  The conceptual model that the interfaces represent is complex. But this complexity may be reduced by combining certain interfaces.
-  For example, many libraries, even well-known ones, do not distinguish between a <cite>Coordinate System</cite> (<abbr>CS</abbr>)
-  and a <cite>Coordinate <u>Reference</u> System</cite> (<abbr>CRS</abbr>).
-  A developer that also wishes not to make this distinction may implement these two interfaces with the same class.
-  The resulting implementation may have a simpler class hierarchy than that of GeoAPI interfaces.
-  The <code class="GeoAPI">geoapi-examples</code> module, discussed later, provides such combinations.
-  The following table lists a few possible combinations:
-</p>
-<table>
-  <tr>
-    <th>Main Interface</th>
-    <th>Auxiliary Interface</th>
-    <th>Use</th>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">CoordinateReferenceSystem</code></td>
-    <td><code class="GeoAPI">CoordinateSystem</code></td>
-    <td>Description of a spatial reference system (<abbr title="Coordinate Reference System">CRS</abbr>).</td>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">GeodeticDatum</code></td>
-    <td><code class="GeoAPI">Ellipsoid</code></td>
-    <td>Description of the geodetic datum.</td>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">CoordinateOperation</code></td>
-    <td><code class="GeoAPI">MathTransform</code></td>
-    <td>Coordinate transformation operations.</td>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">IdentifiedObject</code></td>
-    <td><code class="GeoAPI">ReferenceIdentifier</code></td>
-    <td>An objet (usually a <abbr>CRS</abbr>) that we can identify by a code.</td>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">Citation</code></td>
-    <td><code class="GeoAPI">InternationalString</code></td>
-    <td>Bibliographic reference consisting of a simple title.</td>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">GeographicBoundingBox</code></td>
-    <td><code class="GeoAPI">Extent</code></td>
-    <td>Spatial area in degrees of longitude and latitude.</td>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">ParameterValue</code></td>
-    <td><code class="GeoAPI">ParameterDescriptor</code></td>
-    <td>Description of a parameter (name, type) associated with its value.</td>
-  </tr>
-  <tr>
-    <td><code class="GeoAPI">ParameterValueGroup</code></td>
-    <td><code class="GeoAPI">ParameterDescriptorGroup</code></td>
-    <td>Description of a set of parameters associated with their values.</td>
-  </tr>
-</table>
-
-
-
-<h2 id="GeoAPI-modules">GeoAPI Modules</h2>
-<p>
-  The GeoAPI project consists of a standardized part (<code class="GeoAPI">geoapi</code>)
-  and an experimental part (<code class="GeoAPI">geoapi-pending</code>).
-  As these two parts are mutually exclusive, users must take care not to mix them in the same project.
-  This separation is guaranteed for all projects that depend only on the Maven central repository
-  (including the final versions of Apache <abbr title="Spatial Information System">SIS</abbr>),
-  as the <code class="GeoAPI">geoapi-pending</code> module is never deployed on this central repository.
-  By contrast, certain <abbr>SIS</abbr> development branches may depend on <code class="GeoAPI">geoapi-pending</code>.
-</p>
-<p>
-  GeoAPI modules are:
-</p>
-<ul>
-  <li><p>
-    <b><code class="GeoAPI">geoapi</code></b> — includes interfaces covered by the
-    <a href="http://www.opengeospatial.org/standards/geoapi">GeoAPI standard of the <abbr title="Open Geospatial Consortium">OGC</abbr></a>.
-    The final versions of Apache <abbr title="Spatial Information System">SIS</abbr> depend on this module.
-  </p></li>
-  <li><p>
-    <b><code class="GeoAPI">geoapi-pending</code></b> — contains a
-    <em>copy</em> of all interfaces in the <code class="GeoAPI">geoapi</code> module
-    (not a dependence) with additions that have not yet been approved as an <abbr>OGC</abbr> standard.
-    Some additions appear in interfaces normally defined by the <code class="GeoAPI">geoapi</code> module, hence the need to copy them.
-    Apache <abbr>SIS</abbr>'s development branches <code>jdk6</code>, <code>jdk7</code> and <code>jdk8</code> depend on this module,
-    but this dependence becomes a dependence on the <code class="GeoAPI">geoapi</code> standard module when the branches are merged to the trunk.
-  </p></li>
-  <li><p>
-    <b><code class="GeoAPI">geoapi-conformance</code></b> — includes a JUnit test suite that developers may use to test their implementations.
-  </p></li>
-  <li><p>
-    <b><code class="GeoAPI">geoapi-examples</code></b> — includes examples of relatively simple implementations.
-    These examples are placed in the public domain in order to encourage users to copy and adapt them to their needs if
-    Apache <abbr>SIS</abbr> services are unsuitable.
-  </p></li>
-  <li><p>
-    <b><code class="GeoAPI">geoapi-proj4</code></b> — contains a partial implementation of <code class="GeoAPI">org.opengis.referencing</code>
-    packages as adaptors based on the C/C++ Proj.4 library.
-    This module may be used as an alternative to the <code class="SIS">sis-referencing</code> module for certain functions.
-  </p></li>
-  <li><p>
-    <b><code class="GeoAPI">geoapi-netcdf</code></b> — contains a partial implementation of <code class="GeoAPI">org.opengis.referencing</code>
-    and <code class="GeoAPI">org.opengis.coverage</code> packages as adaptors based on the
-    <abbr title="University Corporation for Atmospheric Research">UCAR</abbr>
-    <abbr title="Network Common Data Form">NetCDF</abbr> library.
-    The series of tests in this module was developed in such a way as to be reusable for other projects.
-    Apache <abbr>SIS</abbr> uses them to test its own <code class="SIS">sis-netcdf</code> module.
-  </p></li>
-  <li><p>
-    <b><code class="GeoAPI">geoapi-openoffice</code></b> — contains an add-in for the OpenOffice.org office suite.
-    <!--
-    Apache <abbr>SIS</abbr> offers its own add-in in the <code class="SIS">sis-openoffice</code> module,
-    but uses the same function names as the GeoAPI module in order to maintain some compatibility.
-    -->
-  </p></li>
-</ul>
-
-<h3 id="GeoAPI-core">The Interfaces' Definition Modules</h3>
-<p>
-  <code class="GeoAPI">geoapi</code> and <code class="GeoAPI">geoapi-pending</code> modules provide interfaces derived from
-  <abbr title="Unified Modeling Language">UML</abbr> schemas of international standards.
-  The conceptual model 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>.
-</p>
-
-
-
-<h3 id="GeoAPI-conformance">The Conformance Tests Module</h3>
-<p>
-  The <code class="GeoAPI">geoapi-conformance</code> module provides <i>validators</i>, a JUnit <i>test suite</i>, and <i>report generators</i>
-  in the form of <abbr title="Hypertext Markup Language">HTML</abbr> pages.
-  This module may be used with any GeoAPI implementation.
-  For developers of a geospatial library, it offers the following advantages:
-</p>
-<ul>
-  <li>Reduces the tedious task of writing tests by using existing tests.</li>
-  <li>Increases confidence in the validity of tests,
-    since <code class="GeoAPI">geoapi-conformance</code> has its own test suite and is applied to other implementations.</li>
-  <li>Facilitates comparison with other implementations.</li>
-</ul>
-
-
-
-<h4 id="GeoAPI-validators">Instance Validations</h4>
-<p>
-  GeoAPI can validate an instance of its interfaces by checking that certain constraints are observed.
-  Many constraints can not be expressed in the method signature. Those constraints
-  are usually described textually in the abstract specifications or in the javadoc.
-</p>
-<div class="example"><p><b>Example:</b>
-  A coordinate conversion or transformation (<code class="OGC">CC_CoordinateOperation</code>) may require a sequence of several steps.
-  In such a sequence of operations (<code class="OGC">CC_ConcatenatedOperation</code>), for each step (<code class="OGC">CC_SingleOperation</code>)
-  the number of output dimensions must equal the number of input dimensions in the next operation.
-  Expressed in Java, this constraint stipulates that for the entire index 0 &lt; <var>i</var> &lt; <var>n</var> where <var>n</var>
-  is the number of operations, we have <code>coordOperation[i].targetDimensions == coordOperation[i-1].sourceDimensions</code>.
-</p></div>
-
-<p>
-  The easiest way to perform these verifications is to call the static methods <code class="GeoAPI">validate(…)</code> of the
-  <code class="GeoAPI">org.opengis.test.Validators</code> class.
-  As all of <code class="GeoAPI">Validators</code> methods bear the same name, it is enough to write “<code>validate(<var>value</var>)</code>”
-  and then let the compiler choose the most appropriate method for the type of object given in argument.
-  If the object type is not known at the time of compilation,
-  the <code class="GeoAPI">dispatch(Object)</code> method can be invoked for redirecting the work to the most appropriate <code class="GeoAPI">validate(…)</code> method.
-</p>
-<p>
-  All <code class="GeoAPI">validate(…)</code> functions follow a chain of dependencies,
-  meaning that they will also validate each component of the object to be validated.
-  For example, the validation of a <code class="GeoAPI">GeographicCRS</code> implies the validation of its component
-  <code class="GeoAPI">GeodeticDatum</code>, which itself implies the validation of its component <code class="GeoAPI">Ellipsoid</code>, and so on.
-  Thus it is unnecessary to validate the components explicitely, unless the developer wishes to isolate the test for a particular item known to cause problems.
-</p>
-<p>
-  By default, validations are as strict as possible. It is always possible to relax certain rules.
-  The most common is to tolerate the absence of attributes that would normally be mandatory.
-  This rule and a few others may be modified globally for all tests executed by the currently running <abbr title="Java Virtual Machine">JVM</abbr>,
-  as in the following example:
-</p>
-
-<pre><b>import</b> <code class="GeoAPI">org.opengis.metadata.Metadata</code>;
-<b>import</b> <code class="GeoAPI">org.opengis.test.Validators</code>;
-<b>import</b> org.junit.Test;
-
-<b>public class</b> MyTest {<code class="comment">
-    /*
-     * Tolerate the absence of mandatory attributes in metadata and citation packages.
-     * This modification applies to all tests executed by the currently running <abbr>JVM</abbr>.
-     * If there are multiple test classes, this initialization may be performed
-     * in a parent class to all test classes.
-     */</code>
-    <b>static</b> {
-        <code class="GeoAPI">Validators.DEFAULT.metadata.requireMandatoryAttributes</code> = <b>false</b>;
-        <code class="GeoAPI">Validators.DEFAULT.citation.requireMandatoryAttributes</code> = <b>false</b>;
-    }
-
-    @Test
-    <b>public void</b> testMyMetadata() {
-        <code class="GeoAPI">Metadata</code> <var>myObject</var> = …; <code class="comment">// Create an object here.</code>
-        <code class="GeoAPI">Validators.validate</code>(<var>myObject</var>);
-    }
-}</pre>
-
-<p>
-  Rules may also be modified for a particular test suite without affecting the default configuration of the standard
-  <abbr title="Java Virtual Machine">JVM</abbr>.
-  This approach requires the creation of a new instance of the validator that we wish to modify the configuration.
-</p>
-
-<pre><b>import</b> <code class="GeoAPI">org.opengis.metadata.Metadata</code>;
-<b>import</b> <code class="GeoAPI">org.opengis.test.ValidatorContainer</code>;
-<b>import</b> org.junit.Test;
-
-<b>public class</b> MyTest {
-    <b>private final</b> <code class="GeoAPI">ValidatorContainer</code> <var>validators</var>;
-
-    <b>public</b> MyTest() {
-        <var>validators</var> = <b>new</b> <code class="GeoAPI">ValidatorContainer()</code>;
-        <var>validators</var>.<code class="GeoAPI">metadata.requireMandatoryAttributes</code> = <b>false</b>;
-        <var>validators</var>.<code class="GeoAPI">citation.requireMandatoryAttributes</code> = <b>false</b>;
-    }
-
-    @Test
-    <b>public void</b> testMyMetadata() {
-        <code class="GeoAPI">Metadata</code> <var>myObject</var> = …; <code class="comment">// Create an object here.</code>
-        <var>validators</var>.<code class="GeoAPI">validate</code>(<var>myObject</var>);
-    }
-}</pre>
-
-
-
-<h4 id="GeoAPI-tests">Executing Pre-defined Tests</h4>
-<p>
-  JUnit tests are defined in the <code class="GeoAPI">org.opengis.test</code> sub-packages.
-  All test classes bear a name ending in "<code>Test</code>".
-  GeoAPI also provides an <code class="GeoAPI">org.opengis.test.TestSuite</code> class including all test classes defined in the
-  <code class="GeoAPI">geoapi-conformance</code> module, but Apache <abbr title="Spatial Information System">SIS</abbr> does not use it.
-  Instead, Apache <abbr>SIS</abbr> inherits GeoAPI's <code class="GeoAPI">*Test</code> classes on a case-by-case basis,
-  in the appropriate modules.
-  The example below gives an example of a customized GeoAPI test:
-  The <a href="http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/referencing/ParameterizedTransformTest.html">parent test javadoc</a>
-  documents the tests performed in detail.
-  In this example, only one test is modified and all the others are inherited as they are (it is not necessary to repeat them in the sub-class).
-  However, this example adds a supplemental verification, annotated with <code>@After</code>, which will be executed after each test.
-</p>
-
-<pre><b>import</b> org.junit.*;
-<b>import</b> org.junit.runner.RunWith;
-<b>import</b> org.junit.runners.JUnit4;
-<b>import</b> <code class="GeoAPI">org.opengis.test.referencing.ParameterizedTransformTest</code>;
-<b>import static</b> org.junit.Assert.*;
-
-@RunWith(JUnit4.class)
-<b>public class</b> MyTest <b>extends</b> <code class="GeoAPI">ParameterizedTransformTest</code> {<code class="comment">
-    /**
-     * Specify our own coordinate transformation factory for the GeoAPI tests.
-     * GeoAPI will test the objects created by this factory.
-     */</code>
-    <b>public</b> MyTest() {
-        <b>super</b>(<b>new</b> MyMathTransformFactory());
-    }
-<code class="comment">
-    /**
-     * Changes the behaviour of a test. This example relaxes the requirements of this test a little,
-     * by accepting errors of up to 10 centimetres, rather than the default value of 1 cm.
-     * This change only applies to this method, and does not affect the other inherited tests.
-     */</code>
-    @Test
-    @Override
-    <b>public void</b> testLambertAzimuthalEqualArea() <b>throws</b> <code class="GeoAPI">FactoryException</code>, <code class="GeoAPI">TransformException</code> {
-        <code class="GeoAPI"><var>tolerance</var></code> = 0.1; // 10 cm tolerance.
-        <b>super</b>.<code class="GeoAPI">testLambertAzimuthalEqualArea()</code>;
-    }
-<code class="comment">
-    /**
-     * Supplemental verification performed after each test, inherited or not.
-     * In this example, we are verifying that the transformation tested
-     * works correctly in two-dimensional spaces.
-     */</code>
-    @After
-    <b>public void</b> ensureAllTransformAreMath2D() {
-        assertTrue(<code class="GeoAPI"><var>transform</var></code> <b>instanceof</b> <code class="GeoAPI">MathTransform2D</code>);
-    }
-}</pre>
-
-
-
-<h3 id="GeoAPI-examples">Example Modules</h3>
-<p>
-  The <code class="GeoAPI">geoapi-examples</code> module provides examples of simple implementations.
-  Many of these classes implement more than one interface at a time in order to provide a simpler conceptual model.
-  The <a href="http://www.geoapi.org/geoapi-examples/apidocs/overview-summary.html">javadoc for this module</a>
-  lists key packages and classes along with the combinations performed.
-  This module illustrates not only how GeoAPI might be implemented,
-  but also how the implementation might be tested using <code class="GeoAPI">geoapi-conformance</code>.
-</p>
-<p>
-  Although its primary goal is to serve as a source of inspiration for implementors,
-  <code class="GeoAPI">geoapi-examples</code> was also designed so as to be usable by applications with very simple needs.
-  As all the examples are in the public domain, developers are invited to freely adapt copies of these classes as necessary.
-  However, if changes are made outside the framework of the GeoAPI project,
-  fair use demands that modified copies be placed in a package with a different name than <code class="GeoAPI">org.opengis</code>.
-</p>
-<p>
-  For somewhat more involved needs, developers are invited to examine the
-  <code class="GeoAPI">geoapi-proj4</code> and <code class="GeoAPI">geoapi-netcdf</code> modules.
-  These two modules provide examples of adaptors that are allowed, via GeoAPI interfaces,
-  to use some of the features of external libraries (Proj.4 and <abbr title="Network Common Data Form">NetCDF</abbr>).
-  The advantage of using these interfaces is to provide a unified model to operate two very different
-  <abbr title="Application Programming Interface">API</abbr>s,
-  while retaining the ability to switch easily to another library if desired.
-</p>
-
-
-
-<h1 id="XML-ISO">Representing Objects in <abbr>XML</abbr></h1>
-<p>
-  Objects defined by
-  <abbr title="Open Geospatial Consortium">OGC</abbr>/<abbr title="International Organization for Standardization">ISO</abbr>
-  standards must be able to communicate with remote machines via the Internet,
-  using different software written in different languages.
-  Some of the better known formats include <abbr>WKT</abbr> (<i>Well Known Text</i>) and
-  <abbr>WKB</abbr> (<i>Well Known Binary</i>).
-  But the most exhaustive and often referred format is <abbr>XML</abbr>,
-  to the point where the representation of <abbr>ISO</abbr> objects in this format is itself sometimes
-  the entire focus of an international standard.
-  Thus are metadata classes described in <abbr>ISO</abbr> 19115-1 standard (an abstract specification),
-  while the representation of these classes in <abbr>XML</abbr> is described in <abbr>ISO</abbr> 19115-3 and 19139 standards.
-</p>
-<p>
-  Different <abbr title="Open Geospatial Consortium">OGC</abbr>/<abbr title="International Organization for Standardization">ISO</abbr>
-  standards do not always use the same strategy to express objects in <abbr>XML</abbr>.
-  <abbr>ISO</abbr> 19115-3 standard in particular uses a more verbose approach than other standards,
-  and will be the subject of its <a href="#XML-ISO-19115">own section</a>.
-  But most <abbr>XML</abbr> formats define supplementary types and attributes that are not part of
-  the original abstract specifications.
-  These supplementary attributes are usually specific to <abbr>XML</abbr> and may not appear in the
-  <abbr title="Application Programming Interface">API</abbr> of Apache <abbr title="Spatial Information System">SIS</abbr>.
-  However, some of these attributes, such as <code class="OGC">id</code>, <code class="OGC">uuid</code> and
-  <code>xlink:href</code>, remain accessible in the form of key-value pairs.
-</p>
-<p>
-  <abbr>XML</abbr> documents may use any prefixes,
-  but the following prefixes are commonly used.
-  They therefore appear by default in documents produced by Apache <abbr>SIS</abbr>.
-  These prefixes are defined in the <code class="SIS">org.apache.sis.xml.Namespaces</code> class.
-</p>
-<table>
-  <caption>Common <abbr>XML</abbr> namespace prefixes</caption>
-  <tr>
-    <th>Prefix</th>
-    <th>Namespace</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>
-  <p><b>Tools for Reading and Writing <abbr>XML</abbr> Documents</b></p>
-  <p>
-    Apache <abbr title="Spatial Information System">SIS</abbr> uses different libraries to read and write
-    different types of objects.
-    The library used depends on the complexity of the object and on performance constraints.
-    For example, <abbr title="Java Architecture for XML Binding">JAXB</abbr> annotations have the advantage of being close to code,
-    which makes it easier to maintain mapping between Java and <abbr>XML</abbr>.
-    On the other hand, <abbr title="Simple API for XML">SAX</abbr> is more efficient.
-    In general, Apache <abbr>SIS</abbr> uses:
-  </p>
-  <ul>
-    <li>
-      <abbr title="Java Architecture for XML Binding">JAXB</abbr> for objects that do not occur very often in <abbr>XML</abbr> documents,
-      but with complex structures and deep hierarchies.
-      The metadata set in <abbr>ISO</abbr> 19115-3 standard is a typical example
-    </li>
-    <li>
-      <abbr title="Simple API for XML">SAX</abbr> for objects that are relatively simple,
-      but which may exist in very large numbers.
-      The set of points in a geometry is a typical example.
-    </li>
-    <li>
-      <abbr title="Document Object Model">DOM</abbr> as an alternative to
-      <abbr title="Java Architecture for XML Binding">JAXB</abbr> when the <abbr>XML</abbr> elements do not correspond
-      exactly to Java attributes.
-      <i>Features</i> are an example, as their structure is dynamic.
-    </li>
-  </ul>
-</aside>
-
-
-
-<h2 id="XML-ISO-19115">Representing Metadata According to <abbr>ISO</abbr> 19115-3</h2>
-<p>
-  For each metadata class, there is an <abbr>XML</abbr> type with the same name than in the abstract specification
-  (for example, <code class="OGC">gmd:MD_Metadata</code> and <code class="OGC">gmd:CI_Citation</code>).
-  All of these types may be used as the root of an <abbr>XML</abbr> document.
-  It is therefore possible to write a document representing a complete <code class="OGC">MD_Metadata</code> object,
-  or to write a document representing only a <code class="OGC">CI_Citation</code> object.
-</p>
-<p>
-  <abbr>ISO</abbr> 19115-3 standard arranges the content of these objects in an unusual way:
-  for each property whose value type is itself another class of <abbr>ISO</abbr> 19115,
-  the value is wrapped in an element that represents its type, rather than being written directly.
-  For example, in an object of the <code class="OGC">CI_Citation</code> type,
-  the value of the <code class="OGC">citedResponsibleParty</code> property is incorporated into a
-  <code class="OGC">CI_Responsibility</code> element.
-  This practice doubles the depth of the hierarchy, and introduces duplication at all levels for each value,
-  as in the following example:
-</p>
-<pre><b>&lt;MD_Metadata&gt;</b>
-  &lt;identificationInfo&gt;
-    <b>&lt;MD_DataIdentification&gt;</b>
-      &lt;citation&gt;
-        <b>&lt;CI_Citation&gt;</b>
-          &lt;citedResponsibleParty&gt;
-            <b>&lt;CI_Responsibility&gt;</b>
-              &lt;party&gt;
-                <b>&lt;CI_Party&gt;</b>
-                  &lt;contactInfo&gt;
-                    <b>&lt;CI_Contact&gt;</b>
-                      &lt;onlineResource&gt;
-                        <b>&lt;CI_OnlineResource&gt;</b>
-                          &lt;linkage&gt;
-                            &lt;URL&gt;http://www.opengeospatial.org&lt;/URL&gt;
-                          &lt;/linkage&gt;
-                        <b>&lt;/CI_OnlineResource&gt;</b>
-                      &lt;/onlineResource&gt;
-                    <b>&lt;/CI_Contact&gt;</b>
-                  &lt;/contactInfo&gt;
-                <b>&lt;/CI_Party&gt;</b>
-              &lt;/party&gt;
-            <b>&lt;/CI_Responsibility&gt;</b>
-          &lt;/citedResponsibleParty&gt;
-        <b>&lt;/CI_Citation&gt;</b>
-      &lt;/citation&gt;
-    <b>&lt;/MD_DataIdentification&gt;</b>
-  &lt;/identificationInfo&gt;
-<b>&lt;/MD_Metadata&gt;</b></pre>
-
-<p>
-  The preceding example, like all documents that conform to <abbr>ISO</abbr> 19115-3,
-  consists of a systematic alternation of two types of <abbr>XML</abbr> elements:
-</p>
-<ol>
-  <li><p>
-    It begins with the name of the property, which always begins with a lower-case letter (ignoring prefixes).
-    In Java <abbr title="Application Programming Interface">API</abbr>s, each property corresponds to a method in its enclosing class.
-    In the example above, <code class="OGC">gmd:identificationInfo</code>  (a property of <code class="OGC">MD_Metadata</code> class)
-    corresponds to the <code class="GeoAPI">Metadata.getIdentificationInfo()</code> method.
-  </p></li>
-  <li><p>
-    The value type is included under each property, unless it has been replaced with a reference
-    (the following <a href="#gco-id">sub-section</a> will elaborate on this subject).
-    The value type is an <abbr>XML</abbr> element whose name always begins with an upper-case letter,
-    ignoring prefixes.
-    In the example above we had <code class="OGC">MD_DataIdentification</code>,
-    which corresponds to the <code class="GeoAPI">DataIdentification</code> Java interface.
-    It is this <abbr>XML</abbr> element that contains the child properties.
-  </p></li>
-</ol>
-
-<p>
-  In order to reduce the complexity of the libraries, GeoAPI and Apache <abbr title="Spatial Information System">SIS</abbr>
-  only expose publicly a single unified view of these two types of elements.
-  The public <abbr title="Application Programming Interface">API</abbr> basically corresponds to the second group.
-  However, when writing an <abbr>XML</abbr> document, elements of the first group must be temporarily recreated.
-  The corresponding classes are defined in internal <abbr title="Spatial Information System">SIS</abbr> packages.
-  These classes may be ignored, unless the developer wishes to implement his or her own classes whose instances
-  must be written in <abbr title="Java Architecture for XML Binding">JAXB</abbr>.
-</p>
-
-<aside>
-  <p><b>Implementation Strategy in Apache <abbr>SIS</abbr></b></p>
-  <p>
-    <code class="SIS">org.apache.sis.internal.jaxb.*</code> packages (non-public) define
-    <abbr title="Java Architecture for XML Binding">JAXB</abbr> adaptors for all types of <abbr>ISO</abbr> objects.
-    These adaptors are required anyway to allow <abbr>JAXB</abbr> to get
-    <abbr title="Spatial Information System">SIS</abbr> classes while implementing GeoAPI interfaces.
-    Conveniently, <abbr>SIS</abbr> made both <abbr>JAXB</abbr> adaptors and objects wrapping the “real” object
-    to be read or written.
-    This double usage avoids having to double the number of classes (already quite high) present in the internal packages.
-  </p>
-  <p><b>Naming Conventions in <abbr>XSD</abbr> Schemas</b></p>
-  <p>
-    For each element of the first group listed above, the <abbr title="XML Schema Definition">XSD</abbr> schemas of the
-    <abbr title="Open Geospatial Consortium">OGC</abbr> define a type whose name ends with “<code class="OGC">_PropertyType</code>”.
-    For the second group, each element has a type whose name ends with “<code class="OGC">_Type</code>”.
-    The “<code class="OGC">_PropertyType</code>” elements may have a group of attributes
-    (such as <code class="OGC">gmd:idref</code>, <code class="OGC">gco:uuidref</code> and <code>xlink:href</code>)
-    which the <abbr>XSD</abbr> schemas collectively name <code class="OGC">gco:ObjectIdentification</code>.
-    These attributes do not have dedicated Java methods, but are accessible indirectly via the
-    <code class="SIS">IdentifiedObject</code> interface described in the following subsection.
-  </p>
-</aside>
-
-
-<h3 id="gco-id">Identification of Already-Defined Instances</h3>
-<p>
-  The parent element may contain an <code class="OGC">id</code>, <code class="OGC">uuid</code> or
-  <code>xlink:href</code> attribute.
-  If one of these attributes is present, the parent attribute may be completely omitted;
-  it will be replaced at the time of reading by the element referenced by the attribute.
-  In the following example, the part on the left defines an element associated with the identifier “<code>my_id</code>,”
-  while the part on the right references this element:
-</p>
-
-<table class="hidden">
-  <tr>
-    <th>Defining an Identifier</th>
-    <th>Using a Defined Identifier</th>
-  </tr>
-  <tr>
-    <td>
-      <pre style="margin-top: 6pt">&lt;MD_MetaData&gt;
-  &lt;identificationInfo&gt;
-    &lt;MD_DataIdentification id="<b>my_id</b>"&gt;
-      <code class="comment">&lt;!-- insert child properties here --&gt;</code>
-    &lt;/MD_DataIdentification&gt;
-  &lt;/identificationInfo&gt;
-&lt;/MD_MetaData&gt;</pre>
-    </td>
-    <td>
-      <pre style="margin-top: 6pt">&lt;MD_MetaData&gt;
-  &lt;identificationInfo idref="<b>my_id</b>"/&gt;
-&lt;/MD_MetaData&gt;</pre>
-    </td>
-  </tr>
-</table>
-
-<p>
-  The decision of which attribute to use depends on the scope of the referenced item:
-</p>
-<ul>
-  <li>
-    <code class="OGC">id</code> is only valid in the same <abbr>XML</abbr> document that defines the object it references.
-  </li>
-  <li>
-    <code class="OGC">uuid</code> may be valid outside the <abbr>XML</abbr> document,
-    but someone must maintain a database providing the objects for each given UUID.
-  </li>
-  <li>

[... 679 lines stripped ...]



Mime
View raw message