sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r993305 - in /websites/staging/sis/trunk/content: ./ faq.html
Date Thu, 21 Jul 2016 17:28:41 GMT
Author: buildbot
Date: Thu Jul 21 17:28:41 2016
New Revision: 993305

Log:
Staging update by buildbot for sis

Modified:
    websites/staging/sis/trunk/content/   (props changed)
    websites/staging/sis/trunk/content/faq.html

Propchange: websites/staging/sis/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Jul 21 17:28:41 2016
@@ -1 +1 @@
-1753710
+1753715

Modified: websites/staging/sis/trunk/content/faq.html
==============================================================================
--- websites/staging/sis/trunk/content/faq.html (original)
+++ websites/staging/sis/trunk/content/faq.html Thu Jul 21 17:28:41 2016
@@ -139,7 +139,7 @@ h2:hover > .headerlink, h3:hover > .head
 <h2 id="referencing-intro">Getting started<a class="headerlink" href="#referencing-intro"
title="Permanent link">&para;</a></h2>
 <h3 id="transform-point">How do I transform a coordinate?<a class="headerlink" href="#transform-point"
title="Permanent link">&para;</a></h3>
 <p>The following Java code projects a geographic coordinate from the <em>World
Geodetic System 1984</em> (WGS84) to <em>WGS 84 / UTM zone 33N</em>.
-In order to make the example a little bit simpler, this code uses predefined systems given
by the <code>CommonCRS</code> convenience class.
+In order to make the example a little bit simpler, this code uses predefined constants given
by the <code>CommonCRS</code> convenience class.
 But more advanced applications will typically use EPSG codes instead.
 Note that all geographic coordinates below express latitude <em>before</em> longitude.</p>
 <div class="codehilite"><pre><span class="kn">import</span> <span
class="nn">org.opengis.geometry.DirectPosition</span><span class="o">;</span>
@@ -174,48 +174,49 @@ Note that all geographic coordinates bel
 <h3 id="operation-methods">Which map projections are supported?<a class="headerlink"
href="#operation-methods" title="Permanent link">&para;</a></h3>
 <p>The operation <em>methods</em> (including, but not limited to, map projections)
supported by Apache SIS
 are listed in the <a href="tables/CoordinateOperationMethods.html">Coordinate Operation
Methods</a> page.
-The amount of map projection <em>methods</em> is relatively small,
+The amount of map projection methods is relatively small,
 but the amount of <em>projected <abbr title="Coordinate Reference System">CRS</abbr></em>
that we can build from them can be very large.
-For example with only three methods (namely <em>Cylindrical Mercator</em>, <em>Transverse
Mercator</em> and <em>Lambert Conic Conformal</em>)
+For example with only three family of methods (<em>Cylindrical Mercator</em>,
<em>Transverse Mercator</em> and <em>Lambert Conic Conformal</em>)
 used with different parameter values, we can cover thousands of projected <abbr title="Coordinate
Reference System">CRS</abbr> listed in the EPSG geodetic dataset.</p>
-<p>For convenience, some pre-defined combinations of operation methods with parameter
values are assigned a code.
-A well-known source of codes is the EPSG geodetic dataset, but other authorities also exist.
-The predefined <abbr title="Coordinate Reference System">CRS</abbr> known to
Apache SIS is listed in the
+<p>In order to use a map projection method, we need to know the value to assign to
the projection parameters.
+For convenience, thousands of projected <abbr title="Coordinate Reference System">CRS</abbr>
with pre-defined parameter values are are assigned a unique identifier.
+A well-known source of such definitions is the EPSG geodetic dataset, but other authorities
also exist.
+The predefined <abbr title="Coordinate Reference System">CRS</abbr> known to
Apache SIS are listed in the
 <a href="tables/CoordinateReferenceSystems.html">Coordinate Reference Systems</a>
page.</p>
 <h3 id="axisOrder">What is the axis order issue and how is it addressed?<a class="headerlink"
href="#axisOrder" title="Permanent link">&para;</a></h3>
-<p>The axis order is specified by the authority (typically a national agency) defining
the <em>Coordinate Reference System</em> (<abbr title="Coordinate Reference
System">CRS</abbr>).
+<p>The axis order is specified by the authority (typically a national agency) defining
the Coordinate Reference System (<abbr title="Coordinate Reference System">CRS</abbr>).
 The order depends on the <abbr title="Coordinate Reference System">CRS</abbr>
type and the country defining the <abbr title="Coordinate Reference System">CRS</abbr>.
 In the case of geographic <abbr title="Coordinate Reference System">CRS</abbr>,
the (<em>latitude</em>, <em>longitude</em>) axis order is widely used
by geographers and pilots for centuries.
-However software developers tend to consistently use the (<em>x</em>,<em>y</em>)
order for every kind of <abbr title="Coordinate Reference System">CRS</abbr>.
+However software developers tend to consistently use the (<em>x</em>, <em>y</em>)
order for every kind of <abbr title="Coordinate Reference System">CRS</abbr>.
 Those different practices resulted in contradictory definitions of axis order for almost
every <abbr title="Coordinate Reference System">CRS</abbr> of kind <code>GeographicCRS</code>,
 for some <code>ProjectedCRS</code> in the South hemisphere (South Africa, Australia,
<em>etc.</em>) and for some polar projections among others.</p>
+<p>For any <abbr title="Coordinate Reference System">CRS</abbr> identified
by an EPSG code, the official axis order can be checked on the
+official EPSG registry at <a href="http://www.epsg-registry.org">http://www.epsg-registry.org</a>
+(not to be confused with other sites having "epsg" in their name,
+but actually unrelated to the organization in charge of EPSG definitions):
+click on the <em>"Retrieve by code"</em> link and enter the numerical code.
+Then click on the <em>"View"</em> link on the right side,
+and click on the <em>"+"</em> symbol of the left side of <em>"Axes"</em>.</p>
 <p>Recent <abbr title="Open Geospatial Consortium">OGC</abbr> standards
mandate the use of axis order as defined by the authority.
-Oldest <abbr title="Open Geospatial Consortium">OGC</abbr> standards used the
(<em>x</em>,<em>y</em>) axis order instead, ignoring any authority
specification.
+Oldest <abbr title="Open Geospatial Consortium">OGC</abbr> standards used the
(<em>x</em>, <em>y</em>) axis order instead, ignoring any authority
specification.
 Among the legacy <abbr title="Open Geospatial Consortium">OGC</abbr> standards
that used the non-conform axis order,
 an influent one is version 1 of the <em>Well Known Text</em> (WKT) format specification.
 According that widely-used format, WKT definitions without explicit <code>AXIS[…]</code>
elements
-shall default to (<em>longitude</em>, <em>latitude</em>) or (<em>x</em>,<em>y</em>)
axis order.
-In version 2 of WKT format, <code>AXIS[…]</code> elements are no longer
optional
+shall default to (<em>longitude</em>, <em>latitude</em>) or (<em>x</em>,
<em>y</em>) axis order.
+In version 2 of the WKT format, <code>AXIS[…]</code> elements are no longer
optional
 and should contain an explicit <code>ORDER[…]</code> sub-element for making
the intended order yet more obvious.</p>
-<p>Many softwares still use the old (<em>x</em>,<em>y</em>)
axis order, because it is easier to implement.
-Apache SIS defaults to axis order <em>as defined by the authority</em> (except
when parsing a WKT 1 definition),
-but allows to change axis order to (<em>x</em>,<em>y</em>) order
after <abbr title="Coordinate Reference System">CRS</abbr> creation.
+<p>Many softwares still use the old (<em>x</em>, <em>y</em>)
axis order, sometime because it is easier to implement.
+But Apache SIS rather defaults to axis order <em>as defined by the authority</em>
(except when parsing a WKT 1 definition),
+but allows changing axis order to the (<em>x</em>, <em>y</em>) order
after <abbr title="Coordinate Reference System">CRS</abbr> creation.
 This change can be done with the following code:</p>
 <div class="codehilite"><pre><span class="n">CoordinateReferenceSystem</span>
<span class="n">crs</span> <span class="o">=</span> <span class="err">…</span><span
class="o">;</span>             <span class="c1">// CRS obtained by any means.</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>
 </pre></div>
 
 
-<p>For any <abbr title="Coordinate Reference System">CRS</abbr> identified
by an EPSG code, the official axis order can be checked on the
-official EPSG registry at <a href="http://www.epsg-registry.org">http://www.epsg-registry.org</a>
-(not to be confused with other sites having "epsg" in their name,
-but actually unrelated to the organization in charge of EPSG definition and maintenance):
-click on the <em>"Retrieve by code"</em> link and enter the numerical code.
-Then click on the <em>"View"</em> link on the right side,
-and click on the <em>"+"</em> symbol of the left side of <em>"Axes"</em>.</p>
 <h2 id="crs">Coordinate Reference Systems<a class="headerlink" href="#crs" title="Permanent
link">&para;</a></h2>
 <h3 id="UTM">How do I instantiate a Universal Transverse Mercator (UTM) projection?<a
class="headerlink" href="#UTM" title="Permanent link">&para;</a></h3>
-<p>If the UTM zone is unknown, an easy way is to use the <code>UTM</code>
method in one of the <code>CommonCRS</code> pre-defined constants.
+<p>If the UTM zone is unknown, an easy way is to invoke the <code>UTM(…)</code>
method on one of the <code>CommonCRS</code> pre-defined constants.
 That method receives in argument a geographic coordinate in (<em>latitude</em>,
<em>longitude</em>) order and computes the UTM zone from it.
 See the <a href="#transform-point">above Java code example</a>.</p>
 <p>If the UTM zone is know, one way is to use the "EPSG" or "AUTO" authority factory.
@@ -231,28 +232,24 @@ The EPSG code of some UTM projections ca
 <p>Note that the above list is incomplete. See the EPSG database for additional UTM
definitions
 (WGS 72BE, SIRGAS 2000, SIRGAS 1995, SAD 69, ETRS 89, <em>etc.</em>, most of
them defined only for a few zones).
 Once the EPSG code of the UTM projection has been determined, the <abbr title="Coordinate
Reference System">CRS</abbr> can be obtained as in the example below:</p>
-<div class="codehilite"><pre><span class="kt">int</span> <span
class="n">code</span> <span class="o">=</span> <span class="mi">32600</span>
<span class="o">+</span> <span class="n">zone</span><span class="o">;</span>
+<div class="codehilite"><pre><span class="kt">int</span> <span
class="n">code</span> <span class="o">=</span> <span class="mi">32600</span>
<span class="o">+</span> <span class="n">zone</span><span class="o">;</span>
   <span class="c1">// For WGS84 northern hemisphere</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">&quot;EPSG:&quot;</span>
<span class="o">+</span> <span class="n">code</span><span class="o">);</span>
 </pre></div>
 
 
-<p>If no EPSG code is available for the desired projection, a more powerful (but also
more difficult)
-way is to instantiate directly a <code>MathTransform</code> using the parameters
documented in the
-<a href="tables/CoordinateOperationMethods.html#9807">Coordinate Operation Methods</a>
page,
-then build a <code>DefaultProjectedCRS</code> instance using it.</p>
 <h3 id="google">How do I instantiate a Google projection?<a class="headerlink" href="#google"
title="Permanent link">&para;</a></h3>
 <p>The Google projection is a Mercator projection that pretends to be defined on the
WGS84 datum,
 but actually ignores the ellipsoidal nature of that datum and uses the simpler spherical
formulas instead.
-Since version 6.15 of the EPSG geodetic dataset, the preferred way to get that projection
is to invoke <code>CRS.forCode("EPSG:3857")</code>.
+Since version 6.15 of EPSG geodetic dataset, the preferred way to get that projection is
to invoke <code>CRS.forCode("EPSG:3857")</code>.
 Note that the use of that projection is <strong>not</strong> recommended, unless
needed for compatibility with other data.</p>
-<p>The EPSG:3857 definition uses a map projection method named "Popular Visualisation
Pseudo Mercator".
+<p>The EPSG:3857 definition uses a map projection method named <em>"Popular Visualisation
Pseudo Mercator"</em>.
 The EPSG geodetic dataset provides also some other map projections that use spherical formulas
despite the ellipsoidal nature of the ellipsoid.
-Those methods have "(Spherical)" in their name, for example "Mercator (Spherical)"
-(which differs from "Popular Visualisation Pseudo Mercator" by the use of a more appropriate
sphere radius).
+Those methods have "(Spherical)" in their name, for example <em>"Mercator (Spherical)"</em>
+(which differs from <em>"Popular Visualisation Pseudo Mercator"</em> by the use
of a more appropriate sphere radius).
 Those projection methods can be used in Well Known Text (WKT) definitions.</p>
 <p>If there is a need to use spherical formulas with a projection that does not have
a "(Spherical)" counterpart,
-this can be done with explicit declarations of "semi_major" and "semi_minor" parameter values
in the WKT definition.
-Those parameters are usually inferred from the datum, but Apache SIS allows explicit declarations
to override the inferred values.</p>
+this can be done with explicit declarations of <code>"semi_major"</code> and
<code>"semi_minor"</code> parameter values in the WKT definition.
+Those parameter values are usually inferred from the datum, but Apache SIS allows explicit
declarations to override the inferred values.</p>
 <h3 id="projectionKind">How can I identify the projection kind of a <abbr title="Coordinate
Reference System">CRS</abbr>?<a class="headerlink" href="#projectionKind" title="Permanent
link">&para;</a></h3>
 <p>The "kind of projection" (Mercator, Lambert Conformal, <em>etc.</em>)
is called <em>Operation Method</em> in <abbr title="International Organization
for Standardization">ISO</abbr> 19111 terminology.
 One approach is to check the value of <code>OperationMethod.getName()</code>
and compare them against the <abbr title="Open Geospatial Consortium">OGC</abbr>
or EPSG names
@@ -261,16 +258,19 @@ listed in the <a href="tables/Coordinate
 <p>The <em>identifier</em> of a Coordinate Reference System (<abbr title="Coordinate
Reference System">CRS</abbr>) object can be obtained by the <code>getIdentifiers()</code>
method,
 which usually return a collection of zero or one element.
 If the <abbr title="Coordinate Reference System">CRS</abbr> has been created
from a Well Known Text (WKT) parsing
-and the WKT ends with an <code>AUTHORITY["EPSG", "xxxx"]</code> (WKT 1) or <code>ID["EPSG",
xxxx]</code> (WKT 2) element,
+and the WKT ends with an <code>AUTHORITY["EPSG", "xxxx"]</code> (WKT version
1) or <code>ID["EPSG", xxxx]</code> (WKT version 2) element,
 then the identifier (an EPSG numerical code in this example) is the <em>xxxx</em>
value in that element.
 If the <abbr title="Coordinate Reference System">CRS</abbr> has been created
from the EPSG geodetic dataset (for example by a call to <code>CRS.forCode("EPSG:xxxx")</code>),
-then the identifier is that <em>xxxx</em> code.
+then the identifier is the <em>xxxx</em> code given to that method.
 If the <abbr title="Coordinate Reference System">CRS</abbr> has been created
in another way, then the collection returned by the <code>getIdentifiers()</code>
method
 may or may not be empty depending if the program that created the <abbr title="Coordinate
Reference System">CRS</abbr> took the responsibility of providing identifiers.</p>
 <p>If the collection of identifiers is empty, the most effective fix is to make sure
that the WKT
 contains an <code>AUTHORITY</code> or <code>ID</code> element (assuming
that the <abbr title="Coordinate Reference System">CRS</abbr> was parsed from
a WKT).
-If this is not possible, then the <code>org.apache.sis.referencing.IdentifiedObjects</code>
class contains
-some convenience methods which may help. Example:</p>
+If this is not possible, then the <code>org.​apache.​sis.​referencing.​IdentifiedObjects</code>
class contains some convenience methods which may help.
+In the following example, the call to <code>lookupEPSG(…)</code> will scan
the EPSG database for a <abbr title="Coordinate Reference System">CRS</abbr> equals
+(ignoring metadata) to the given one. <em>Note that this scan is sensitive to axis
order.</em>
+Most geographic <abbr title="Coordinate Reference System">CRS</abbr> in the EPSG
database are declared with (<em>latitude</em>, <em>longitude</em>)
axis order.
+Consequently if the given <abbr title="Coordinate Reference System">CRS</abbr>
has (<em>longitude</em>, <em>latitude</em>) axis order, then the scan
is likely to find no match.</p>
 <div class="codehilite"><pre><span class="n">CoordinateReferenceSystem</span>
<span class="n">myCRS</span> <span class="o">=</span> <span class="err">…</span><span
class="o">;</span>
 <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 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>
@@ -279,21 +279,18 @@ some convenience methods which may help.
 </pre></div>
 
 
-<p>The above call will scan the EPSG database for a <abbr title="Coordinate Reference
System">CRS</abbr> equals (ignoring metadata) to the given one.
-<em>Note that this scan is sensitive to axis order.</em>
-Most geographic <abbr title="Coordinate Reference System">CRS</abbr> in the EPSG
database are declared with (<em>latitude</em>, <em>longitude</em>)
axis order.
-Consequently if the given <abbr title="Coordinate Reference System">CRS</abbr>
has (<em>longitude</em>, <em>latitude</em>) axis order, then the scan
is likely to find no match.</p>
 <h3 id="lookupURN">How do I get the "urn:ogc:def:crs:…" URN of an existing <abbr
title="Coordinate Reference System">CRS</abbr>?<a class="headerlink" href="#lookupURN"
title="Permanent link">&para;</a></h3>
-<p><abbr title="Open Geospatial Consortium">OGC</abbr> defines URN for
<abbr title="Coordinate Reference System">CRS</abbr> identifiers, for example
"urn:ogc:def:crs:epsg:7.1:4326" where "7.1" is the version of the EPSG database used.
+<p><abbr title="Open Geospatial Consortium">OGC</abbr> defines URN for
<abbr title="Coordinate Reference System">CRS</abbr> identifiers, for example
<code>"urn:​ogc:​def:​crs:​epsg:​7.1:​4326"</code>
+where <code>"7.1"</code> is the version of the EPSG database used.
 URN may or may not be present in the set of identifiers returned by <code>crs.getIdentifiers()</code>.
-In many cases (especially if the <abbr title="Coordinate Reference System">CRS</abbr>
was parsed from a Well Known Text), only simple identifiers like "EPSG:4326" are provided.
-An easy way to build the full URN is to use the code below:</p>
+In many cases (especially if the <abbr title="Coordinate Reference System">CRS</abbr>
was parsed from a Well Known Text), only simple identifiers like <code>"EPSG:​4326"</code>
are provided.
+An easy way to build the full URN is to use the code below.
+That example may scan the EPSG database for finding the information if it was not explicitely
provided in the given <abbr title="Coordinate Reference System">CRS</abbr>.</p>
 <div class="codehilite"><pre><span class="n">CoordinateReferenceSystem</span>
<span class="n">myCRS</span> <span class="o">=</span> <span class="err">…</span><span
class="o">;</span>
 <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>
 </pre></div>
 
 
-<p>The above call may scan the EPSG database for finding the information if it was
not explicitely provided in the given <abbr title="Coordinate Reference System">CRS</abbr>.</p>
 <h3 id="lookupReliability">Can I rely on IdentifiedObjects.lookupEPSG(…) to work
correctly as the inverse of <abbr title="Coordinate Reference System">CRS</abbr>.forCode(…)?<a
class="headerlink" href="#lookupReliability" title="Permanent link">&para;</a></h3>
 <p>For <abbr title="Coordinate Reference System">CRS</abbr> created from
the EPSG geodetic dataset, usually yes.
 Note however that <code>IdentifiedObjects.getIdentifier(…)</code> is cheaper
and insensitive to the details of <abbr title="Coordinate Reference System">CRS</abbr>
definition,
@@ -301,12 +298,12 @@ since it never query the database. But i
 which is the case for <abbr title="Coordinate Reference System">CRS</abbr> created
from the EPSG database or parsed from a Well Known Text (WKT) having an <code>AUTHORITY</code>
or <code>ID</code> element.
 The <code>lookupEPSG(…)</code> method on the other hand is robust to erroneous
code declaration,
 since it always compares the <abbr title="Coordinate Reference System">CRS</abbr>
with the database content.
-But it fails if there is slight mismatch (for example rounding errors in projection parameters)
+But it may fail if there is slight mismatch (for example rounding errors in projection parameters)
 between the supplied <abbr title="Coordinate Reference System">CRS</abbr> and
the <abbr title="Coordinate Reference System">CRS</abbr> found in the database.</p>
 <h3 id="equalsIgnoreMetadata">How can I determine if two <abbr title="Coordinate
Reference System">CRS</abbr> are "functionally" equal?<a class="headerlink" href="#equalsIgnoreMetadata"
title="Permanent link">&para;</a></h3>
 <p>Two Coordinate Reference Systems may not be considered equal if they are associated
to different metadata
 (name, identifiers, scope, domain of validity, remarks), even though they represent the same
logical <abbr title="Coordinate Reference System">CRS</abbr>.
-In order to test if two <abbr title="Coordinate Reference System">CRS</abbr>
are functionally equivalent, use <code>Utilities.equalsIgnoreMetadata(Object, Object)</code>.</p>
+In order to test if two <abbr title="Coordinate Reference System">CRS</abbr>
are functionally equivalent, use <code>Utilities.equalsIgnoreMetadata(myFirstCRS, mySecondCRS)</code>.</p>
 <h3 id="crsHashCode">Are <abbr title="Coordinate Reference System">CRS</abbr>
objects safe for use as keys in HashMap?<a class="headerlink" href="#crsHashCode" title="Permanent
link">&para;</a></h3>
 <p>Yes, every classes defined in the <code>org.apache.sis.referencing.crs</code>,
<code>cs</code> and <code>datum</code> packages
 define properly their <code>equals(Object)</code> and <code>hashCode()</code>
methods.
@@ -316,16 +313,16 @@ The Apache SIS library itself uses <abbr
 <p>This is most frequently caused by ordinate values given in the wrong order.
 Developers tend to assume a (<em>x</em>, <em>y</em>) or (<em>longitude</em>,
<em>latitude</em>) axis order.
 But geographers and pilots are using (<em>latitude</em>, <em>longitude</em>)
axis order for centuries,
-and the EPSG geodetic dataset defines geographic coordinate reference systems that way.
+and the EPSG geodetic dataset defines geographic Coordinate Reference Systems that way.
 If a coordinate transformation seems to produce totally wrong values,
-the first thing to do should be to print the source and target coordinate reference systems:</p>
+the first thing to do should be to print the source and target Coordinate Reference Systems:</p>
 <div class="codehilite"><pre><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 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>
 </pre></div>
 
 
 <p>Attention should be paid to the order of <code>AXIS</code> elements.
-In the example below, the coordinate reference system clearly uses (<em>latitude</em>,
<em>longitude</em>) axis order:</p>
+In the example below, the Coordinate Reference System clearly uses (<em>latitude</em>,
<em>longitude</em>) axis order:</p>
 <div class="codehilite"><pre>GeodeticCRS[&quot;WGS 84&quot;,
   Datum[&quot;World Geodetic System 1984&quot;,
     Ellipsoid[&quot;WGS 84&quot;, 6378137.0, 298.257223563]],
@@ -350,15 +347,13 @@ One subtle issue is the angular units of
 The WKT 1 specification clary states: <em>"If the <code>PRIMEM</code> clause
occurs inside a <code>GEOGCS</code>,
 then the longitude units will match those of the geographic coordinate system"</em>
(source: <abbr title="Open Geospatial Consortium">OGC</abbr> 01-009).
 However ESRI and GDAL among others unconditionally use decimal degrees, ignoring this part
of the WKT specification.
-This problem can be identified by WKT inspection as in the following example:</p>
+This problem can be identified by WKT inspection as in the following extract:</p>
 <div class="codehilite"><pre>PROJCS[&quot;Lambert II étendu&quot;,
-  GEOGCS[&quot;Nouvelle Triangulation Française&quot;,
-    …,
+  GEOGCS[&quot;Nouvelle Triangulation Française&quot;, …,
     PRIMEM[&quot;Paris&quot;, 2.337229167],
     UNIT[&quot;grad&quot;, 0.01570796326794897]]
   PROJECTION[&quot;Lambert_Conformal_Conic_1SP&quot;],
-  PARAMETER[&quot;latitude_of_origin&quot;, 46.8],
-  …]
+  PARAMETER[&quot;latitude_of_origin&quot;, 46.8], …]
 </pre></div>
 
 
@@ -374,7 +369,7 @@ In order to get the intended result, the
 </li>
 <li>
 <p>Or ask explicitely Apache SIS to parse the WKT using the ESRI or GDAL conventions,
by specifying the
-    <code>Convention.WKT1_COMMON_UNITS</code> enumeration value to <code>WKTFormat</code>
in the <code>org.apache.sis.io.wkt</code> package.</p>
+    <code>Convention.​WKT1_COMMON_UNITS</code> enumeration value to <code>WKTFormat</code>
in the <code>org.​apache.​sis.​io.​wkt</code> package.</p>
 </li>
 </ul>
 <p>Note that the GeoPackage standard explicitely requires <abbr title="Open Geospatial
Consortium">OGC</abbr> 01-009 compliant WKT
@@ -386,28 +381,28 @@ Different ellipsoids (actually different
 When transforming coordinates between two <abbr title="Coordinate Reference System">CRS</abbr>
using the same datum, no Bursa-Wolf parameters are needed.
 But when the transformation involves a change of datum, the referencing module needs some
information about how to perform that datum shift.</p>
 <p>There is many way to specify how to perform a datum shift, and most of them are
only approximation.
-The Bursa-Wolf method is one of them, not the only one. However it is one of the most frequently
used method.
-The Bursa-Wolf parameters can specified inside a <code>TOWGS84</code> element
in version 1 of Well Known Text (WKT) format,
-or in a <code>BOUNDCRS</code> element in version 2 of WKT format.
+The Bursa-Wolf method is one of them, not the only one. However it is one of the most frequently
used methods.
+The Bursa-Wolf parameters can be specified inside a <code>TOWGS84</code> element
with version 1 of Well Known Text (WKT) format,
+or in a <code>BOUNDCRS</code> element with version 2 of WKT format.
 If the <abbr title="Coordinate Reference System">CRS</abbr> are parsed from a
WKT string, make sure that the string contains the appropriate element.</p>
 <h3 id="slightDifferences">I get slightly different results depending on the environment
I’m running in.<a class="headerlink" href="#slightDifferences" title="Permanent link">&para;</a></h3>
-<p>The results of coordinates converted when running in a web application container
(JBoss, <em>etc.</em>)
-may be a few meters off compared to coordinates converted in an IDE (NetBeans, Eclipse, <em>etc.</em>).
-The results depend on whatever an EPSG factory is available on the classpath, <strong>regardless
how the <abbr title="Coordinate Reference System">CRS</abbr> were created</strong>,
+<p>The results of coordinate transformations when running in a web application container
(JBoss, <em>etc.</em>)
+may be a few meters off compared to coordinates transformations in an IDE (NetBeans, Eclipse,
<em>etc.</em>).
+The results depend on whether an EPSG factory is available on the classpath, <strong>regardless
how the <abbr title="Coordinate Reference System">CRS</abbr> were created</strong>,
 because the EPSG factory specifies explicitly the coordinate operation to apply for some
pairs of <abbr title="Coordinate Reference System">CRS</abbr>.
 In such case, the coordinate operation specified by EPSG has precedence over the Burwa-Wolf
parameters
 (the <code>TOWGS84</code> element in version 1 of Well Known Text format).</p>
 <p>A connection to the EPSG database may have been established for one environment
 (typically the JEE one) and not the other (typically the IDE one) because only the former
has <abbr title="Java DataBase Connectivity">JDBC</abbr> driver.
 The recommended way to uniformize the results is to add in the second environment (IDE)
-the same <abbr title="Java DataBase Connectivity">JDBC</abbr> driver than the
first environment (JEE).
+the same <abbr title="Java DataBase Connectivity">JDBC</abbr> driver than the
one available in the first environment (JEE).
 It should be one of the following: JavaDB (a.k.a. Derby), HSQL or PostgreSQL.
 Make sure that the <a href="epsg.html">connection parameters to the EPSG database</a>
are also the same.</p>
 <h3 id="toWGS84">Can I always expect a transform from an arbitrary <abbr title="Coordinate
Reference System">CRS</abbr> to WGS84 to succeed?<a class="headerlink" href="#toWGS84"
title="Permanent link">&para;</a></h3>
 <p>For 2D horizontal <abbr title="Coordinate Reference System">CRS</abbr>
created from the EPSG database, calls to <code>CRS.findOperation(…)</code>
should generally succeed.
-For 3D <abbr title="Coordinate Reference System">CRS</abbr> having any kind of
height different than ellipsoid height, or for a 2D <abbr title="Coordinate Reference System">CRS</abbr>
of type <code>EngineeringCRS</code>, it may fail.
+For 3D <abbr title="Coordinate Reference System">CRS</abbr> having any kind of
height different than ellipsoidal height, or for a 2D <abbr title="Coordinate Reference
System">CRS</abbr> of type <code>EngineeringCRS</code>, it may fail.
 Note however that even if the call to <code>CRS.findOperation(…)</code>
succeed, the call to <code>MathTransform.transform(…)</code> may fail
-or produce <code>NaN</code> or infinity values if the coordinate to transform
is far from the projection area of validity.</p>
+or produce <code>NaN</code> or infinity values if the coordinate to transform
is far from the domain of validity.</p>
 <h1 id="metadata">Metadata<a class="headerlink" href="#metadata" title="Permanent
link">&para;</a></h1>
 <h2 id="metadata-implementation">Custom implementations<a class="headerlink" href="#metadata-implementation"
title="Permanent link">&para;</a></h2>
 <h3 id="metadata-proxy">My metadata are stored in a database-like framework. Implementing
every GeoAPI interfaces for them is impractical.<a class="headerlink" href="#metadata-proxy"
title="Permanent link">&para;</a></h3>



Mime
View raw message