This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/sis-site.git
commit dd8701a937fd386e95c6628dfea49d7b9030f2a4
Author: Martin Desruisseaux <martin.desruisse...@geomatys.com>
AuthorDate: Sat Nov 19 14:04:58 2022 +0100
Fix common spelling errors.
---
source/build.md | 4 ++--
source/code-patterns.md | 10 +++++-----
source/command-line.md | 6 +++---
.../developer-guide/annexes/design/AffineTransform.html | 4 ++--
source/developer-guide/annexes/design/JacobianUsage.html | 4 ++--
source/developer-guide/annexes/design/MatrixLibrary.html | 8 ++++----
.../annexes/geoapi/DefinitionProcess.html | 2 +-
.../developer-guide/annexes/tests/GeoApiConformance.html | 6 +++---
source/developer-guide/coverage/AffineTransform.html | 2 +-
source/developer-guide/geometry/Envelope.html | 2 +-
source/developer-guide/introduction/Conventions.html | 2 +-
source/developer-guide/introduction/DataAccess.html | 6 +++---
source/developer-guide/metadata/GetMetadataElement.html | 4 ++--
source/developer-guide/referencing/ComponentsOfCRS.html | 8 ++++----
.../referencing/CoordinateOperationSteps.html | 2 +-
source/developer-guide/utility/ObjectConverters.html | 4 ++--
source/epsg.md | 6 +++---
source/faq.md | 16 ++++++++--------
source/formats.md | 6 +++---
source/mail-lists.md | 2 +-
source/release-management-setup.md | 2 +-
source/release-management.md | 4 ++--
source/source.md | 2 +-
source/standards.md | 2 +-
static/openoffice/en/formula.html | 6 +++---
static/release-notes/0.7.html | 2 +-
static/release-notes/0.8.html | 4 ++--
static/release-notes/1.0.html | 4 ++--
static/release-notes/1.1.html | 2 +-
29 files changed, 66 insertions(+), 66 deletions(-)
diff --git a/source/build.md b/source/build.md
index ef607e62..60fdf2a7 100644
--- a/source/build.md
+++ b/source/build.md
@@ -36,7 +36,7 @@ The remaining of this page provides more advanced tips for
SIS developers.
# Distribution file {#dist}
The distribution archive is a file with the `.zip` extension containing most
SIS modules except `sis-webapp`
-(because Web applications use an other packaging) together with their
dependencies.
+(because Web applications use another packaging) together with their
dependencies.
However for users convenience, we provide shell scripts launching the SIS
command line tool or the JavaFX application.
Those shell scripts, together with other files (`README`, `LICENSE`,
<i>etc.</i>) are bundled in a ZIP file created as below:
@@ -101,7 +101,7 @@ implementation looks only for resources in any package
ending with the `resource
The resources compilation is part of the build process and does not need to be
run explicitly.
However, if necessary the resources compiler can be invoked alone by the
following command line
-in the module containing the resources to recompile. This is sometime useful
for regenerating
+in the module containing the resources to recompile. This is sometimes useful
for regenerating
the constants in the `Keys` inner class in a feaster way than building the
project.
{{< highlight bash >}}
diff --git a/source/code-patterns.md b/source/code-patterns.md
index 266ac9b8..9b9ff67c 100644
--- a/source/code-patterns.md
+++ b/source/code-patterns.md
@@ -10,10 +10,10 @@ This page lists some recommended code pattern for
developing or using Apache {{%
This section lists recommended code pattern when using the `sis-referencing`
module.
-## Never explicitely swap coordinates for axis order {#axisOrder}
+## Never explicitly swap coordinates for axis order {#axisOrder}
The [axis order issue](faq.html#axisOrder) causes lot of confusion,
-and developers are sometime tempted to swap their coordinate values in order
to comply with some expected axis ordering.
+and developers are sometimes tempted to swap their coordinate values in order
to comply with some expected axis ordering.
It should never be necessary, since the Apache {{% SIS %}} referencing engine
manages axis order transparently —
provided that the Coordinate Reference System (CRS) definition is accurate.
If a code needs to swap coordinates, this is probably an indication that the
{{% CRS %}} has not been properly defined.
@@ -50,8 +50,8 @@ This section lists recommended code pattern for
internationalization.
## Specify timezone {#timezone}
Geospatial data often cover a wide geographic area, spanning many time zones.
-Timezone are sometime specified as metadata in the header of data files to be
read,
-or is sometime fixed to {{% UTC %}} by applications managing world-wide data.
+Timezone are sometimes specified as metadata in the header of data files to be
read,
+or is sometimes fixed to {{% UTC %}} by applications managing world-wide data.
Some Apache {{% SIS %}} objects have `Locale` and `TimeZone` information.
Such locale and timezone are given to `java.text.DateFormat` or
`java.util.Calendar` constructors among others.
@@ -64,7 +64,7 @@ The `Calendar` object should has been created with the
appropriate timezone.
Before to sort programmatic names for human reading, consider replacing all
occurrences of the underscore character
(`'_'`) by the space character (`' '`). The ASCII value of the underscore
character is greater than `'Z'` but lower
-than `'a'`, which sometime produce unexpected sort results.
+than `'a'`, which sometimes produce unexpected sort results.
For example `"Foo_bar"` is sorted _between_ `"FooBar"` and `"Foobar"`.
The space character produces more consistent sort results because its ASCII
value is less than any printable character,
so `"Foo bar"` is sorted before both `"FooBar"` and `"Foobar"`.
diff --git a/source/command-line.md b/source/command-line.md
index 0112790d..e50ed670 100644
--- a/source/command-line.md
+++ b/source/command-line.md
@@ -45,7 +45,7 @@ However users can add other JAR files in that directory for
the following option
* **UCAR netCDF library —**
by default, SIS uses its own embedded netCDF reader which supports only the
classical netCDF format, as standardized by OGC.
If there is a need to read files encoded in GRID or HDF formats, then copy
the UCAR netCDF library in the `lib` sub-directory.
- If presents, the UCAR library should be detected and used automatically when
SIS can not read a netCDF file by itself.
+ If presents, the UCAR library should be detected and used automatically when
SIS cannot read a netCDF file by itself.
# Usage {#usage}
@@ -187,7 +187,7 @@ Such codes can be written in different ways. For example
all the following strin
In a _Well Known Text_ (WKT) string, the code can appear at the bottom of the
definition
in an optional element like `ID["EPSG", 4326]` or `AUTHORITY["EPSG", "4326"]`.
However in many cases the code is missing.
-Sometime Apache {{% SIS %}} can find a missing code by comparing a given {{%
CRS %}} against the definitions in the EPSG database.
+Sometimes Apache {{% SIS %}} can find a missing code by comparing a given {{%
CRS %}} against the definitions in the EPSG database.
The following example reads a {{% WKT %}} for the _“NTF (Paris) / Lambert zone
II”_ Coordinate Reference System,
but in which the `ID["EPSG", 27572]` element has been intentionally omitted.
Furthermore, the _“NTF (Paris) / Lambert zone II”_ name has been replaced by
_“NTF (Paris) / zone to be discovered by the demo”_ name.
@@ -205,7 +205,7 @@ urn:ogc:def:crs:EPSG:9.7:27572 | NTF (Paris) / Lambert
zone II
As we can see, Apache {{% SIS %}} has been able to find back the identifier
code and the actual {{% CRS %}} name.
-Sometime a {{% WKT %}} declares wrongly an EPSG code.
+Sometimes a {{% WKT %}} declares wrongly an EPSG code.
The most frequent case is a {{% WKT %}} that defines a Coordinate Reference
System with (_longitude_, _latitude_) axes,
but declare an EPSG code for a {{% CRS %}} with (_latitude_, _longitude_) axes.
Apache {{% SIS %}} can detect such mismatches.
diff --git a/source/developer-guide/annexes/design/AffineTransform.html
b/source/developer-guide/annexes/design/AffineTransform.html
index 386e3c01..86296b84 100644
--- a/source/developer-guide/annexes/design/AffineTransform.html
+++ b/source/developer-guide/annexes/design/AffineTransform.html
@@ -53,10 +53,10 @@
<p>
However in many cases, affine or perspective transforms are the only
kind of coordinate operations supported by the graphical library.
Apache <abbr>SIS</abbr> needs to handle a wider range of operations,
in which affine transforms are only special cases.
- In particular most map projections and datum shifts can not be
represented by affine transforms.
+ In particular most map projections and datum shifts cannot be
represented by affine transforms.
<abbr>SIS</abbr> also needs to support arbitrary number of dimensions,
while above-cited <abbr>API</abbr> restrict the use to a fixed number
of dimensions.
- For those reasons <abbr>SIS</abbr> can not use directly the
above-cited <abbr>API</abbr>.
+ For those reasons <abbr>SIS</abbr> cannot use directly the above-cited
<abbr>API</abbr>.
Instead, <abbr>SIS</abbr> uses the more abstract
<code>org.opengis.referencing.transform.MathTransform</code> interface.
But in the special case where the transform is actually affine,
<abbr>SIS</abbr> may try to use an existing implementation,
in particular Java2D. The following Java code can be used in
situations where the Java2D object is desired:
diff --git a/source/developer-guide/annexes/design/JacobianUsage.html
b/source/developer-guide/annexes/design/JacobianUsage.html
index 9859e931..336cc167 100644
--- a/source/developer-guide/annexes/design/JacobianUsage.html
+++ b/source/developer-guide/annexes/design/JacobianUsage.html
@@ -214,10 +214,10 @@ Matrix derivative = projection.<code
class="SIS">transform</code>(sourcePoint
</p><p>
Many operations on coordinate transforms can also be applied on
transform derivatives:
concatenation of a chain of transforms, inversion, taking a subset of
the dimensions, <i>etc.</i>
- Inverse projection formulas are usually more complicated than forward
projections formulas,
+ reverse projection formulas are usually more complicated than forward
projections formulas,
but thankfully their derivatives do not need to be computed:
the Jacobian matrix of an inverse transform is the inverse of the
Jacobian matrix of the forward transform.
- Calculation of inverse projections can be implemented as below:
+ Calculation of reverse projections can be implemented as below:
</p>
<pre><code>@Override
diff --git a/source/developer-guide/annexes/design/MatrixLibrary.html
b/source/developer-guide/annexes/design/MatrixLibrary.html
index 14c2365a..8ade688e 100644
--- a/source/developer-guide/annexes/design/MatrixLibrary.html
+++ b/source/developer-guide/annexes/design/MatrixLibrary.html
@@ -70,12 +70,12 @@
This investment can save execution time at the place where it matters
most:
in the code looping over millions of coordinates to transform.
</p><p>
- However matrix libraries are often designed for high performances with
large matrices, sometime containing thousands of rows and columns.
+ However matrix libraries are often designed for high performances with
large matrices, sometimes containing thousands of rows and columns.
Those libraries can efficiently resolve systems of linear equations
with hundreds of unknown variables.
Those libraries resolve difficult problems, but not of the same kind
than the problems that Apache <abbr>SIS</abbr> needs to solve.
For that reason, and also for another reason described in next
paragraphs, Apache <abbr>SIS</abbr> uses its own matrix implementation.
This implementation addresses the accuracy issue by using
“double-double” arithmetic
- (a technic for simulating the accuracy of approximatively 120 bits
wide floating point numbers)
+ (a technic for simulating the accuracy of approximately 120 bits wide
floating point numbers)
at the cost of performance in a phase (transform <em>preparation</em>)
where performance is not considered critical.
</p>
@@ -99,9 +99,9 @@
<xi:include
href="../../../../layouts/partials/math/Geographic3Dto2D.html"/>
</p><p>
For linear algebra libraries, the above non-square matrix represents
an under-determined system of equations and may be considered unresolvable.
- Indeed the above coordinate operation can not be inverted as a
(<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>)
+ Indeed the above coordinate operation cannot be inverted as a
(<var>φ₂</var>, <var>λ₂</var>) → (<var>φ₁</var>, <var>λ₁</var>, <var>h</var>)
operation because we do not know which value to assign to <var>h</var>.
- Ignoring <var>h</var> implies that we can not assign values to
(<var>φ₁</var>, <var>λ₁</var>) neither since those values may depend on
<var>h</var>.
+ Ignoring <var>h</var> implies that we cannot assign values to
(<var>φ₁</var>, <var>λ₁</var>) neither since those values may depend on
<var>h</var>.
However in <abbr>GIS</abbr> case, the ellipsoidal <var>h</var> axis is
perpendicular to the ellipsoid surface
on which the <em>geodetic</em> latitudes and longitudes (<var>φ</var>,
<var>λ</var>) are represented
(note that this statement is not true for <em>geocentric</em>
latitudes and longitudes).
diff --git a/source/developer-guide/annexes/geoapi/DefinitionProcess.html
b/source/developer-guide/annexes/geoapi/DefinitionProcess.html
index 5465068a..c5fbe6c0 100644
--- a/source/developer-guide/annexes/geoapi/DefinitionProcess.html
+++ b/source/developer-guide/annexes/geoapi/DefinitionProcess.html
@@ -37,7 +37,7 @@
<h3 id="SpecificationToInterfaces">From <abbr>OGC</abbr>
specifications to Java interfaces</h3>
</header>
<p>
- GeoAPI interfaces are sometime generated from other files provided by
<abbr>OGC</abbr>, like <abbr>XSD</abbr> files.
+ GeoAPI interfaces are sometimes generated from other files provided by
<abbr>OGC</abbr>, like <abbr>XSD</abbr> files.
But there is always a manual revision, and often modifications
compared to automatically generated Java files.
It would have been possible to automatically generate Java interfaces
from <abbr>OGC</abbr> standards using existing tools.
For example one of the most commonly-used approaches is to transform
<a href="http://schemas.opengis.net/gml/3.3/";><abbr>XSD</abbr> schemas</a>
diff --git a/source/developer-guide/annexes/tests/GeoApiConformance.html
b/source/developer-guide/annexes/tests/GeoApiConformance.html
index 3530f628..45ab83aa 100644
--- a/source/developer-guide/annexes/tests/GeoApiConformance.html
+++ b/source/developer-guide/annexes/tests/GeoApiConformance.html
@@ -53,7 +53,7 @@
<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
+ Many constraints cannot 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>
@@ -77,7 +77,7 @@
meaning that they will also validate each component of the object to
be validated.
For example, the validation of a <code>GeographicCRS</code> implies
the validation of its component
<code>GeodeticDatum</code>, which itself implies the validation of its
component <code>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.
+ Thus it is unnecessary to validate the components explicitly, 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.
@@ -136,7 +136,7 @@ public class MyTest {
- <h4 id="GeoAPI-tests">Executing pre-defined tests</h4>
+ <h4 id="GeoAPI-tests">Executing predefined tests</h4>
<p>
JUnit tests are defined in the <code>org.opengis.test</code>
sub-packages.
All test classes bear a name ending in "<code>Test</code>".
diff --git a/source/developer-guide/coverage/AffineTransform.html
b/source/developer-guide/coverage/AffineTransform.html
index a7377802..ef25cc32 100644
--- a/source/developer-guide/coverage/AffineTransform.html
+++ b/source/developer-guide/coverage/AffineTransform.html
@@ -40,7 +40,7 @@
<dfn>affine transforms</dfn> are both relatively simple and very
common.
Affine transforms can represent any combination of scales, shears,
flips, rotations and translations,
which are <em>linear</em> operations.
- Affine transforms can not handle <em>non-linear</em> operations like
map projections,
+ Affine transforms cannot handle <em>non-linear</em> operations like
map projections,
but the affine transform capabilities nevertheless cover many other
cases:
</p>
<ul>
diff --git a/source/developer-guide/geometry/Envelope.html
b/source/developer-guide/geometry/Envelope.html
index 27535920..95535c79 100644
--- a/source/developer-guide/geometry/Envelope.html
+++ b/source/developer-guide/geometry/Envelope.html
@@ -197,7 +197,7 @@ Envelope transformed = Envelopes.transform(envelope,
targetCRS);</code></pre>
The union operation needs to find a <abbr>CRS</abbr> valid in a domain
large enough for containing all envelopes.
It may be a <abbr>CRS</abbr> different than all <abbr>CRS</abbr> used
by the source envelopes.
Apache <abbr>SIS</abbr> has an utility method for handling this
additional complexity.
- This method accepts an arbitrary amount of envelopes that may be in
different <abbr>CRS</abbr>:
+ This method accepts an arbitrary number of envelopes that may be in
different <abbr>CRS</abbr>:
</p>
<pre><code>Envelope union = Envelopes.union(envelope1, envelope2,
envelope3);</code></pre>
</section>
diff --git a/source/developer-guide/introduction/Conventions.html
b/source/developer-guide/introduction/Conventions.html
index daacaf70..9b83e350 100644
--- a/source/developer-guide/introduction/Conventions.html
+++ b/source/developer-guide/introduction/Conventions.html
@@ -65,7 +65,7 @@
</p><p>
Apache SIS implements most GeoAPI interfaces by a classes of the same
name than the interface
but prefixed by <code>Abstract</code>, <code>Default</code> or
<code>General</code> word.
- The <code>General</code> prefix is sometime used instead of
<code>Default</code>
+ The <code>General</code> prefix is sometimes used instead of
<code>Default</code>
to indicate that alternative implementations are available for some
specific cases.
For example the <code class="GeoAPI">Envelope</code> interface is
implemented by at least two Apache SIS classes:
<code class="SIS">GeneralEnvelope</code> and <code
class="SIS">Envelope2D</code>.
diff --git a/source/developer-guide/introduction/DataAccess.html
b/source/developer-guide/introduction/DataAccess.html
index 19baeb49..dc0f4a69 100644
--- a/source/developer-guide/introduction/DataAccess.html
+++ b/source/developer-guide/introduction/DataAccess.html
@@ -101,7 +101,7 @@ Geographic Bounding Box
The <abbr>ISO</abbr> 19115 standard defines hundreds of elements.
Some of them will be introduced progressively in next chapters.
But in order to give some idea about what is available, the following
table lists a few metadata elements.
- Most of the nodes accept an arbitrary amount of values.
+ Most of the nodes accept an arbitrary number of values.
For example the <code class="OGC">extent</code> node may contain many
geographic areas.
</p>
@@ -150,9 +150,9 @@ Geographic Bounding Box
Its content is essential for accurate data positioning;
without this element, even positions given by latitudes and longitudes
are ambiguous.
Reference systems have many characteristics that make them apart from
other metadata:
- they are immutable, can not be handled by <code
class="SIS">MetadataStandard.ISO_19115.asValueMap(…)</code>,
+ they are immutable, cannot be handled by <code
class="SIS">MetadataStandard.ISO_19115.asValueMap(…)</code>,
have a particular text representation and are associated to an engine
- performing coordinate transformation from one reference system to an
other.
+ performing coordinate transformation from one reference system to
another.
</p>
</section>
</body>
diff --git a/source/developer-guide/metadata/GetMetadataElement.html
b/source/developer-guide/metadata/GetMetadataElement.html
index 591e7b25..603b676c 100644
--- a/source/developer-guide/metadata/GetMetadataElement.html
+++ b/source/developer-guide/metadata/GetMetadataElement.html
@@ -38,7 +38,7 @@
<p>
Methods like <code class="GeoAPI">getExtents()</code> are efficient
when looking for a particular element known at compile-time.
But those elements may be deep in the tree structure and may require
traversal of many optional elements and collection members,
- which is sometime tedious. For a few frequently-used elements, some
convenience methods are provided.
+ which is sometimes tedious. For a few frequently-used elements, some
convenience methods are provided.
Those conveniences are generally defined as static methods in classes
having a name in plural form.
For example the <code>Extents</code> class defines static methods for
fetching more easily some information from <code>Extent</code> metadata
elements.
For example the following method navigates through different branches
where North, South, East and West data bounds may be found:
@@ -54,7 +54,7 @@
<p>
Above static methods explore fragments of metadata tree in search for
requested information,
but the searches are still targeted to elements whose types and at
least part of their paths are known at compile-time.
- Sometime the element to search is known only at runtime, or sometime
there is a need to iterate over all elements.
+ Sometimes the element to search is known only at runtime, or sometimes
there is a need to iterate over all elements.
In such cases, one can view the metadata as a
<code>java.util.Map</code> like below:
</p>
diff --git a/source/developer-guide/referencing/ComponentsOfCRS.html
b/source/developer-guide/referencing/ComponentsOfCRS.html
index d5a49326..f670230a 100644
--- a/source/developer-guide/referencing/ComponentsOfCRS.html
+++ b/source/developer-guide/referencing/ComponentsOfCRS.html
@@ -44,7 +44,7 @@
<ul>
<li>A <i>datum</i>, which specifies among other things which ellipsoid
to use as an Earth shape approximation.</li>
<li>A description for each axis: name, direction, units of
measurement, range of values.</li>
- <li>Sometime a list of parameters, especially when using map
projections.</li>
+ <li>Sometimes a list of parameters, especially when using map
projections.</li>
</ul>
<p>
Those systems are described by the <abbr>ISO</abbr> 19111 standard
(<i>Referencing by Coordinates</i>),
@@ -58,7 +58,7 @@
<h3 id="ProjectedCRS">Map projections</h3>
<p>
Map projections represent a curved surface (the Earth surface) on a
plane surface (a map or a computer screen).
- Every rendering of geospatial data on a flat screen uses some kind of
map projection, sometime implicitly.
+ Every rendering of geospatial data on a flat screen uses some kind of
map projection, sometimes implicitly.
Well-designed map projections provide some control over deformations:
one can preserve the angles, another projection can preserve the areas,
but none can preserve both in same time.
@@ -80,7 +80,7 @@
<h3 id="GeographicCRS">Geographic reference systems</h3>
<p>
All map projections are based on a geodetic (usually geographic)
<abbr>CRS</abbr>.
- A geodetic <abbr>CRS</abbr> is a coordinate reference system with
latitude, longitude and sometime height axes.
+ A geodetic <abbr>CRS</abbr> is a coordinate reference system with
latitude, longitude and sometimes height axes.
There is many kinds of latitudes and longitudes,
but two common kinds supported by Apache <abbr>SIS</abbr> are
<dfn>geodetic</dfn> and <dfn>geocentric</dfn> latitudes.
Those two angles differ slightly in the way they intersect the
ellipsoid surface.
@@ -184,7 +184,7 @@ RangeMeaning atEnds = secondAxis.getRangeMeaning();
// For a longitude a
<p>
The main properties that we can get from an ellipsoid are given below.
- The semi-major axis length is sometime called <cite>equatorial
radius</cite> and
+ The semi-major axis length is sometimes called <cite>equatorial
radius</cite> and
the semi-minor axis length the <cite>polar radius</cite>.
The inverse flattening factor is apparently superfluous since it can
be derived from other quantities,
but many ellipsoid definitions provide this factor instead of
semi-minor axis length.
diff --git a/source/developer-guide/referencing/CoordinateOperationSteps.html
b/source/developer-guide/referencing/CoordinateOperationSteps.html
index 6c50d515..12bd648b 100644
--- a/source/developer-guide/referencing/CoordinateOperationSteps.html
+++ b/source/developer-guide/referencing/CoordinateOperationSteps.html
@@ -223,7 +223,7 @@
<li><p>The “Geocentric translation” operation is not anymore
applied in the geographic domain, but in the geocentric domain.
Consequently conversions between geographic and geocentric
coordinate reference systems must be made explicit.
Those explicit steps are also necessary for specifying the
ellipsoid semi-axis lengths,
- since they can not anymore by inferred for source and target
<abbr>CRS</abbr>.</p></li>
+ since they cannot anymore by inferred for source and target
<abbr>CRS</abbr>.</p></li>
<li><p>Conversions between geographic and geocentric coordinates
are three-dimensional.
Consequently operations for increasing and reducing the number
of dimensions are inserted.
By default the ellipsoidal height before conversion is set to
zero.</p></li>
diff --git a/source/developer-guide/utility/ObjectConverters.html
b/source/developer-guide/utility/ObjectConverters.html
index de3a1a39..3e27caad 100644
--- a/source/developer-guide/utility/ObjectConverters.html
+++ b/source/developer-guide/utility/ObjectConverters.html
@@ -36,7 +36,7 @@
<h2 id="ObjectConverters">Object converters</h2>
</header>
<p>
- There is sometime a need to convert instances from a <var>source</var>
Java type to a <var>target</var> Java type
+ There is sometimes a need to convert instances from a
<var>source</var> Java type to a <var>target</var> Java type
while those types are unknown at compile time.
Various projects (Apache Common Convert, Spring, <i>etc.</i>)
have created their own interface for performing object conversions
between types known only at runtime.
@@ -73,7 +73,7 @@
the <code>String</code> → <code>Integer</code> conversion
performed by <code>Integer.valueOf(String)</code>
is a <dfn>surjective</dfn> function because every
<code>Integer</code> value can be created from at least one <code>String</code>
value.
However the <code>Integer</code> → <code>String</code>
conversion performed by <code>Integer.toString()</code>
- is <strong>not</strong> a surjective function because it can not
produce all possible <code>String</code> values.
+ is <strong>not</strong> a surjective function because it cannot
produce all possible <code>String</code> values.
For example there is no way to produce the "ABC" value with the
<code>Integer.toString()</code> method.
</p></div>
</dd>
diff --git a/source/epsg.md b/source/epsg.md
index 3d277db3..316c643a 100644
--- a/source/epsg.md
+++ b/source/epsg.md
@@ -11,7 +11,7 @@ without that geodetic dataset, only a small subset of CRS
definitions will be av
(basically the constants enumerated in the
[`CommonCRS`](apidocs/org/apache/sis/referencing/CommonCRS.html) Java class)
unless full definitions are provided in _Well Known Text_ (WKT) or _Geographic
Markup Language_ (GML) formats.
Furthermore, coordinate operations between any given pair of CRS may be less
accurate
-and their domains of validity may be unspecified if Apache {{% SIS %}} can not
query EPSG.
+and their domains of validity may be unspecified if Apache {{% SIS %}} cannot
query EPSG.
The EPSG geodetic dataset is not distributed with Apache {{% SIS %}} because
the [EPSG terms of use][EPSG-ToU]
are incompatible with Apache license. The following items are quoted from
those terms of use:
@@ -64,7 +64,7 @@ export SIS_DATA=apache-sis-{{% version %}}/data
java --class-path apache-sis-{{% version %}}/lib/sis-referencing.jar:myApp.jar
MyMainClass
{{< / highlight >}}
-If the `SIS_DATA` environment variable can not be set, Java property can be
used as a fallback:
+If the `SIS_DATA` environment variable cannot be set, Java property can be
used as a fallback:
{{< highlight bash >}}
java -Dderby.system.home=apache-sis-{{% version %}}/data/Databases \
@@ -79,7 +79,7 @@ Alternatively `SIS_DATA` or `derby.system.home` can be set to
the path of any ot
Maven projects can get the EPSG geodetic dataset automatically, _without any
prompt for terms of use agreement_,
if they add a `sis-epsg` or `sis-embedded-data` dependency (from
`org.apache.sis.non-free` group) in their project.
Those two approaches have advantages and inconvenient described in following
sub-sections.
-In both cases, we assume that developers who add those dependencies
explicitely in their project agree with
+In both cases, we assume that developers who add those dependencies explicitly
in their project agree with
[EPSG terms of use][EPSG-ToU].
## As database installer {#maven-epsg}
diff --git a/source/faq.md b/source/faq.md
index f8009d33..2e3b2fc1 100644
--- a/source/faq.md
+++ b/source/faq.md
@@ -56,7 +56,7 @@ For example with only three family of methods (_Cylindrical
Mercator_, _Transver
used with different parameter values, we can cover thousands of projected {{%
CRS %}} listed in the EPSG geodetic dataset.
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 {{% CRS %}} with pre-defined parameter
values are are assigned a unique identifier.
+For convenience, thousands of projected {{% CRS %}} with predefined 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 {{% CRS %}} known to Apache {{% SIS %}} are listed in the
[Coordinate Reference Systems](tables/CoordinateReferenceSystems.html) page.
@@ -87,7 +87,7 @@ shall default to (_longitude_, _latitude_) or (_x_, _y_) axis
order.
In version 2 of the {{% WKT %}} format, `AXIS[…]` elements are no longer
optional
and should contain an explicit `ORDER[…]` sub-element for making the intended
order yet more obvious.
-Many software products still use the old (_x_, _y_) axis order, sometime
because it is easier to implement.
+Many software products still use the old (_x_, _y_) axis order, sometimes
because it is easier to implement.
But Apache {{% SIS %}} rather defaults to axis order _as defined by the
authority_ (except when parsing a {{% WKT %}} 1 definition),
but allows changing axis order to the (_x_, _y_) order after {{% CRS %}}
creation.
This change can be done with the following code:
@@ -101,7 +101,7 @@ crs =
AbstractCRS.castOrCopy(crs).forConvention(AxesConvention.RIGHT_HANDED)
### How do I instantiate a Universal Transverse Mercator (UTM) projection?
{#UTM}
-If the UTM zone is unknown, an easy way is to invoke the `universal(…)` method
on one of the `CommonCRS` pre-defined constants.
+If the UTM zone is unknown, an easy way is to invoke the `universal(…)` method
on one of the `CommonCRS` predefined constants.
That method receives in argument a geographic coordinate in (_latitude_,
_longitude_) order and computes the UTM zone from it.
See the [above Java code example](#transform-point).
@@ -183,7 +183,7 @@ where `"7.1"` is the version of the EPSG database used.
URN may or may not be present in the set of identifiers returned by
`crs.getIdentifiers()`.
In many cases (especially if the {{% CRS %}} 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.
-That example may scan the EPSG database for finding the information if it was
not explicitely provided in the given {{% CRS %}}.
+That example may scan the EPSG database for finding the information if it was
not explicitly provided in the given {{% CRS %}}.
{{< highlight java >}}
CoordinateReferenceSystem myCRS = ...;
@@ -273,7 +273,7 @@ PROJCS["Lambert II étendu",
PARAMETER["latitude_of_origin", 46.8], ...]
{{< / highlight >}}
-The Paris prime meridian is located at approximatively 2.597 gradians from
Greenwich, which is 2.337 degrees.
+The Paris prime meridian is located at approximately 2.597 gradians from
Greenwich, which is 2.337 degrees.
From this fact, we can see that the above {{% WKT %}} uses decimal degrees
despite its `UNIT["grad"]` declaration.
This mismatch applies also to the parameter value, which declare 46.8° in the
above example while the official value is 52 gradians.
By default, Apache {{% SIS %}} interprets those angular values as gradians
when parsing such {{% WKT %}}, resulting in a large error.
@@ -282,10 +282,10 @@ In order to get the intended result, there is a choice:
* Replace `UNIT["grad", 0.01570796326794897]` by `UNIT["degree",
0.017453292519943295]`,
which ensure that Apache {{% SIS %}}, GDAL and ESRI understand that {{% WKT
%}} 1 in the same way.
-* Or ask explicitely Apache {{% SIS %}} to parse the {{% WKT %}} using the
ESRI or GDAL conventions, by specifying the
+* Or ask explicitly Apache {{% SIS %}} to parse the {{% WKT %}} using the ESRI
or GDAL conventions, by specifying the
`Convention.WKT1_COMMON_UNITS` enumeration value to `WKTFormat` in the
`org.apache.sis.io.wkt` package.
-Note that the GeoPackage standard explicitely requires {{% OGC %}} 01-009
compliant {{% WKT %}}
+Note that the GeoPackage standard explicitly requires {{% OGC %}} 01-009
compliant {{% WKT %}}
and the new {{% WKT %}} 2 standard also follows the {{% OGC %}} 01-009
interpretation.
The default Apache {{% SIS %}} behavior is consistent with those two standards.
@@ -349,7 +349,7 @@ if (uml != null) {
This is indeed the approach taken by the `org.apache.sis.metadata.sql` package
for providing an implementation
of all GeoAPI metadata interfaces reading their values directly from a SQL
database.
-### I can not marshall my custom implementation. {#metadata-unknownClass}
+### I cannot marshall my custom implementation. {#metadata-unknownClass}
The classes given to the JAXB marshaller shall contain JAXB annotations,
otherwise the following exception is thrown:
diff --git a/source/formats.md b/source/formats.md
index e745cd1f..916d49ff 100644
--- a/source/formats.md
+++ b/source/formats.md
@@ -6,7 +6,7 @@ Apache {{% SIS %}} can read data from the formats listed below.
Some formats are supported in read-only mode, others in read/write modes.
Data may be structured as vectors or rasters,
which in Apache {{% SIS %}} are mapped to the `FeatureSet` and
`GridCoverageResource` interfaces respectively.
-Some formats can contain an arbitrary amount of feature types or rasters,
+Some formats can contain an arbitrary number of feature types or rasters,
in which case the root resource will be `Aggregate`.
<table>
@@ -65,12 +65,12 @@ in which case the root resource will be `Aggregate`.
</tr><tr>
<td>World File</td>
<td>Read/write</td>
- <td><code>GridCoverageResource</code>, sometime <code>Aggregate<code></td>
+ <td><code>GridCoverageResource</code>, sometimes <code>Aggregate<code></td>
</tr>
</table>
**Notes:**
-1. {{% GML %}}, {{% WKT %}} and {{% ISO %}} 19115 can not yet be written
+1. {{% GML %}}, {{% WKT %}} and {{% ISO %}} 19115 cannot yet be written
throught the `DataStore` API. They require the use of specific API.
2. {{% SQL %}} is not a file format but rather a connection to a database
throught {{% JDBC %}} driver.
diff --git a/source/mail-lists.md b/source/mail-lists.md
index 947a27ba..fdf0db1c 100644
--- a/source/mail-lists.md
+++ b/source/mail-lists.md
@@ -14,7 +14,7 @@ See [Public Forum Archive Policy][policy] for more
information.
## Geospatial mailing list {#geospatial}
This is where peoples can ask questions or discuss about geospatial topics
that are not specific to Apache {{% SIS %}}.
-Those topics can include questions about international standards,
participation to upcomming geospatial events
+Those topics can include questions about international standards,
participation to upcoming geospatial events
or collaboration with communities outside Apache.
- Subscribe: [geospatial-subscr...@apache.org][geo-sub]
diff --git a/source/release-management-setup.md
b/source/release-management-setup.md
index 555c7a8a..468ce091 100644
--- a/source/release-management-setup.md
+++ b/source/release-management-setup.md
@@ -12,7 +12,7 @@ If those steps have already been done, jump directly to the
[Release Management]
The steps described in the _release management_ page assume the following
directory layout.
Some directories are Git checkout, other are ordinary directories. Any other
layout can be used.
-However in the later case, all relative paths in the _release management_ page
will need to be adjusted accordingly.
+However in the latter case, all relative paths in the _release management_
page will need to be adjusted accordingly.
{{< highlight text >}}
<any root directory for SIS>
diff --git a/source/release-management.md b/source/release-management.md
index fbd8f833..2434fcba 100644
--- a/source/release-management.md
+++ b/source/release-management.md
@@ -118,7 +118,7 @@ Those steps are also useful as additional tests, since
failure to generate those
## Prepare release notes {#release-notes}
-We update JIRA soon because doing so is sometime a reminder of uncompleted
tasks in source code.
+We update JIRA soon because doing so is sometimes a reminder of uncompleted
tasks in source code.
Update [JIRA][JIRA] tasks and prepare release notes as below:
* Ensure that the _Fix Version_ in issues resolved since the last release
includes this release version correctly.
@@ -276,7 +276,7 @@ In the `sis-epsg-$NEW_VERSION.jar` file, verify that
`META-INF/LICENSE` contains
Additional cleaning:
* Delete all
`org/apache/sis/parent/$NEW_VERSION/parent-$NEW_VERSION-source-release.zip.*`
files on the Nexus repository.
- They should not be there - source release will be deployed on an other
repository later.
+ They should not be there - source release will be deployed on another
repository later.
* Delete all
`org/apache/sis/non-free/$NEW_VERSION/non-free-$NEW_VERSION-source-release.zip.*`
files.
* Delete all
`org/apache/sis/non-free/sis-epsg/$NEW_VERSION/sis-epsg-$NEW_VERSION-source.jar.*`
files.
diff --git a/source/source.md b/source/source.md
index 25e1915e..be3120b2 100644
--- a/source/source.md
+++ b/source/source.md
@@ -99,7 +99,7 @@ cd -
This is sufficient for allowing Apache {{% SIS %}} to create the geodetic
database
without the need for `sis-epsg` or `sis-embedded-data` module on the classpath.
-This setting is not done automatically because Apache projects can not
introduce
+This setting is not done automatically because Apache projects cannot introduce
non-free dependencies without explicit action from user.
If this action is not taken, some JUnit tests requiring EPSG data may be
skipped.
If any EPSG file is updated, deleting the
`$SIS_DATA/Databases/SpatialMetadata` directory
diff --git a/source/standards.md b/source/standards.md
index 1e8f14f1..b126435d 100644
--- a/source/standards.md
+++ b/source/standards.md
@@ -6,7 +6,7 @@ Apache {{% SIS %}} implements the following standards from
the Open Geospatial Consortium (OGC),
the International Organization for Standardization (ISO) or
the Java Community Process (JCP).
-The same standard is sometime published jointly by both {{% OGC %}} and {{%
ISO %}} organizations.
+The same standard is sometimes published jointly by both {{% OGC %}} and {{%
ISO %}} organizations.
Links to free versions of the standards are given when available.
The _Upgrade needed_ column indicates that a more recent version of the
standard
is available but that Apache {{% SIS %}} has not yet been upgraded to that
version.
diff --git a/static/openoffice/en/formula.html
b/static/openoffice/en/formula.html
index 85a8a9e9..05021e4c 100644
--- a/static/openoffice/en/formula.html
+++ b/static/openoffice/en/formula.html
@@ -68,7 +68,7 @@
It is much more efficient to take advantage of matrix nature of
above-cited functions:
in addition to selecting as many columns as necessary, select also as
many lines as there is points to transform.
This approach allows Apache <abbr>SIS</abbr> to compute information
related to <abbr>EPSG</abbr> codes only once
- for every lines in the output matrix, instead than repeating that
operation for each copied lines.
+ for every lines in the output matrix, instead of repeating that
operation for each copied lines.
</p>
@@ -123,7 +123,7 @@
Returns the name of the Coordinate Reference System identified by the
given code.
The reference system code is the only argument expected by this
function.
While this function is designed for operating on Coordinate Reference
System (<abbr>CRS</abbr>) objects by default,
- it can also work with other kinds of objects provided that the type is
explicitely specified
+ it can also work with other kinds of objects provided that the type is
explicitly specified
(for example: <code>"urn:ogc:def:<b>datum</b>:EPSG::6326"</code>).
</p>
<table>
@@ -143,7 +143,7 @@
Returns the scope of the Coordinate Reference System identified by the
given code.
The reference system code is the only argument expected by this
function.
While this function is designed for operating on Coordinate Reference
System (<abbr>CRS</abbr>) objects by default,
- it can also work with other kinds of objects provided that the type is
explicitely specified
+ it can also work with other kinds of objects provided that the type is
explicitly specified
(for example: <code>"urn:ogc:def:<b>datum</b>:EPSG::6326"</code>).
</p>
<table>
diff --git a/static/release-notes/0.7.html b/static/release-notes/0.7.html
index be06351d..26e52244 100644
--- a/static/release-notes/0.7.html
+++ b/static/release-notes/0.7.html
@@ -44,7 +44,7 @@
<li>[<a href='https://issues.apache.org/jira/browse/SIS-293'>SIS-293</a>] -
Complete JAXB annotations for PassThroughOperation</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-294'>SIS-294</a>] -
Complete JAXB annotations for DerivedCRS</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-173'>SIS-173</a>] -
Support references from xlink:href to gml:id</li>
-<li>[<a href='https://issues.apache.org/jira/browse/SIS-124'>SIS-124</a>] -
PT_FreeText should be able to marshall a CodeList instead than the
CharacterString</li>
+<li>[<a href='https://issues.apache.org/jira/browse/SIS-124'>SIS-124</a>] -
PT_FreeText should be able to marshall a CodeList instead of the
CharacterString</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-286'>SIS-286</a>] -
Add @XmlSchemaType annotations where appropriate</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-295'>SIS-295</a>] -
Verify validity of unmarshalled CRS</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-326'>SIS-326</a>] -
ISO 19111-2 : parametric CRS,CS,Datum and WKT parser implementations</li>
diff --git a/static/release-notes/0.8.html b/static/release-notes/0.8.html
index 87589345..ebf38964 100644
--- a/static/release-notes/0.8.html
+++ b/static/release-notes/0.8.html
@@ -44,7 +44,7 @@
<li>[<a href='https://issues.apache.org/jira/browse/SIS-368'>SIS-368</a>] -
When a coordinate operation change the longitude axis range from [-180 … +180]°
to [0 … 360]°, the Envelopes.transform(…) result should be normalized
accordingly</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-390'>SIS-390</a>] -
When datum shift information are missing, still apply ellipsoid change</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-330'>SIS-330</a>] -
Missing EPSG identifiers for Molodensky parameters</li>
-<li>[<a href='https://issues.apache.org/jira/browse/SIS-335'>SIS-335</a>] -
CRS.findOperation(…) sometime slow</li>
+<li>[<a href='https://issues.apache.org/jira/browse/SIS-335'>SIS-335</a>] -
CRS.findOperation(…) sometimes slow</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-327'>SIS-327</a>] -
Defer loading of datum shift grid files</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-298'>SIS-298</a>] -
Simplification in MetadataTreeFormat output</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-171'>SIS-171</a>] -
Upgrade NetCDF to ISO-19115 mapping</li>
@@ -55,7 +55,7 @@
<h2>Bug fixes</h2>
<ul>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-328'>SIS-328</a>] -
EPSG factory on PostgreSQL fails because of missing cast</li>
-<li>[<a href='https://issues.apache.org/jira/browse/SIS-329'>SIS-329</a>] -
Transformation of envelope from UTM to WGS84 sometime wrongly expanded to the
±180° longitude range</li>
+<li>[<a href='https://issues.apache.org/jira/browse/SIS-329'>SIS-329</a>] -
Transformation of envelope from UTM to WGS84 sometimes wrongly expanded to the
±180° longitude range</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-333'>SIS-333</a>] - In
GML, the second defining parameter of spheres should be
<gml:isSphere>true</gml:isSphere></li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-346'>SIS-346</a>] -
MetadataStandard.asValueMap(…) / asTreeTable(…) do not work if the argument
implements more than one metadata interface</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-347'>SIS-347</a>] -
Extents.area(GeographicBoundingBox) returns 0 if the longitude range is 360°
large.</li>
diff --git a/static/release-notes/1.0.html b/static/release-notes/1.0.html
index ca59880f..e1bdad88 100644
--- a/static/release-notes/1.0.html
+++ b/static/release-notes/1.0.html
@@ -14,7 +14,7 @@
<h2>Summary</h2>
<p>Apache SIS 1.0 can marshal and unmarshal metadata in XML documents using
the new ISO 19115-3 standard.
The previous ISO 19139 standard is still supported and automatically
recognized at unmarshalling time.
- This release contains also improvements in reading netCDF files
+ This release also contains improvements in reading netCDF files
and a beginning of raster support.</p>
<h2>Incompatible changes</h2>
@@ -56,7 +56,7 @@
<li>[<a href='https://issues.apache.org/jira/browse/SIS-396'>SIS-396</a>] -
Update EPSG geodetic dataset to version 9.4</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-468'>SIS-468</a>] -
Update EPSG geodetic dataset to version 9.7</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-395'>SIS-395</a>] -
Need a public way to get connection to "SpatialMetadata" database</li>
-<li>[<a href='https://issues.apache.org/jira/browse/SIS-338'>SIS-338</a>] -
Stores pre-defined metadata in the SpatialMetadata database</li>
+<li>[<a href='https://issues.apache.org/jira/browse/SIS-338'>SIS-338</a>] -
Stores predefined metadata in the SpatialMetadata database</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-81'>SIS-81</a>] -
Replace ModifiableMetadata.isModifiable() by an enum</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-345'>SIS-345</a>] -
Upgrade JAXB binding to ISO 19115-3</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-126'>SIS-126</a>] -
Replace the NamespacePrefixMapper hack by NamespaceContext</li>
diff --git a/static/release-notes/1.1.html b/static/release-notes/1.1.html
index 19013e4c..2a0a2ca9 100644
--- a/static/release-notes/1.1.html
+++ b/static/release-notes/1.1.html
@@ -90,7 +90,7 @@
<li>[<a href='https://issues.apache.org/jira/browse/SIS-486'>SIS-486</a>] -
Some map projections produce wrong results when |Δλ| > 180°</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-488'>SIS-488</a>] -
Handle wrap-around longitude in NADCON grid</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-492'>SIS-492</a>] -
Remove support for JavaDB (JDK 8)</li>
-<li>[<a href='https://issues.apache.org/jira/browse/SIS-496'>SIS-496</a>] -
GridCoverage.forConvertedValues(true) sometime creates an image that can not
store NaN values</li>
+<li>[<a href='https://issues.apache.org/jira/browse/SIS-496'>SIS-496</a>] -
GridCoverage.forConvertedValues(true) sometimes creates an image that cannot
store NaN values</li>
<li>[<a href='https://issues.apache.org/jira/browse/SIS-509'>SIS-509</a>] -
Migrate the web site to another site generator tool</li>
</ul>
