sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1629807 - in /sis/site/trunk/content/book: en/developer-guide.html fr/developer-guide.html
Date Tue, 07 Oct 2014 06:31:29 GMT
Author: desruisseaux
Date: Tue Oct  7 06:31:28 2014
New Revision: 1629807

URL: http://svn.apache.org/r1629807
Log:
Minor clarification attempts.

Modified:
    sis/site/trunk/content/book/en/developer-guide.html
    sis/site/trunk/content/book/fr/developer-guide.html

Modified: sis/site/trunk/content/book/en/developer-guide.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/en/developer-guide.html?rev=1629807&r1=1629806&r2=1629807&view=diff
==============================================================================
--- sis/site/trunk/content/book/en/developer-guide.html [UTF-8] (original)
+++ sis/site/trunk/content/book/en/developer-guide.html [UTF-8] Tue Oct  7 06:31:28 2014
@@ -643,7 +643,7 @@
       <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> standard
19115.
+      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>
@@ -675,7 +675,7 @@
       These decisions are made case-by-case based on a needs analysis.
     </p>
     <div class="example"><p><b>Example:</b>
-      <abbr>ISO</abbr> Standard 19111 defines different types of coordinate systems,
such as spherical, cylindrical, polar or Cartesian.
+      <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>,
@@ -692,7 +692,7 @@
       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> Standard 19115, which defines metadata structures,
+      <abbr>ISO</abbr> 19115 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 except
@@ -707,12 +707,12 @@
       regardless of the chronological order in which the standards were published.
     </p>
     <div class="example"><p><b>Exemple:</b>
-      <abbr>ISO</abbr> Standard 19115-2 is an extension of <abbr>ISO</abbr>
Standard 19115-1, adding image metadata structures.
+      <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> Standard 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>
Standard 19115-1 by adding attributes that would have appeared
+      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>
@@ -734,9 +734,9 @@
   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> Standard 19111.
+  (<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> Standard 19111,
+  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>
 
@@ -1349,7 +1349,7 @@ System.out.println("The GeoAPI interface
   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> Standard 19115-1 (an
abstract specification),
+  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>
@@ -1838,7 +1838,7 @@ System.out.println("The GeoAPI interface
   same instance of <code class="GeoAPI">CoordinateOperation</code>,
   even if the projection has a different name depending on the country.
   Moreover, certain types of <code class="GeoAPI">CoordinateOperation</code>
may require coordinate transformation matrices,
-  so sharing a single instance becomes even more preferable in order to conserve memory.
+  so sharing a single instance becomes even more preferable in order to reduce memory consumption.
 </p>
 
 
@@ -1952,7 +1952,7 @@ System.out.println("The GeoAPI interface
 
 <h1 id="Geometry">Geometries</h1>
 <p>
-  This chapter introduces a few aspects of <abbr>ISO</abbr> Standard 19107 (<i>Spatial
schema</i>) and the
+  This chapter introduces a few aspects of <abbr>ISO</abbr> 19107 standard (<i>Spatial
schema</i>) and the
   Apache <abbr title="Spatial Information System">SIS</abbr> classes that implement
them.
 </p>
 
@@ -1962,21 +1962,20 @@ System.out.println("The GeoAPI interface
 <p>
   Each geometric object is considered an infinite set of points.
   As a set, their most fundamental operations are of the same nature as the standard operations
of Java collections.
-  We may therefore see a geometry as a sort of <code>java.util.Set</code> in
which the elements are points,
+  We may therefore see a geometry as a kind of <code>java.util.Set</code> in
which the elements are points,
   except that the number of elements contained in the set is infinite (with the exception
of geometries representing a simple point).
   To better represent this concept, the <abbr title="International Organization for Standardization">ISO</abbr>
standard
   and GeoAPI define a <code class="OGC">TransfiniteSet</code> interface which
we could see as a <code>Set</code> of infinite size.
   Although a parent relationship exists conceptually between these interfaces,
-  GeoAPI does not define <code class="GeoAPI">TransfiniteSet</code> as a sub-interface
of <code>java.util.Collection</code>,
+  GeoAPI does not define <code class="GeoAPI">TransfiniteSet</code> as a sub-interface
of <code>java.util.Set</code>,
   as the definition of certain methods such as <code>size()</code> and <code>iterator()</code>
would be problematic.
   However, we find very similar methods such as <code class="GeoAPI">contains(…)</code>
and <code class="GeoAPI">intersects(…)</code>.
 </p>
 <p>
-  The parent class of all geometries is called <code class="OGC">GM_Object</code>
in <abbr>ISO</abbr> Standard 19107.
-  GeoAPI interfaces use the name <code class="GeoAPI">Geometry</code> instead,
as the omission of the prefix
-  <code class="OGC">GM_</code> (as prescribed in GeoAPI convention) would leave
a name too similar to Java's
-  <code>Object</code> class.
   All geometries are specializations of <code class="GeoAPI">TransfiniteSet</code>.
+  The parent class of those geometries is called <code class="OGC">GM_Object</code>
in <abbr>ISO</abbr> 19107 standard.
+  GeoAPI interfaces use the <code class="GeoAPI">Geometry</code> name instead,
as the omission of the <code class="OGC">GM_</code>
+  prefix (as prescribed in GeoAPI convention) would leave a name too similar to Java's <code>Object</code>
class.
 </p>
 
 
@@ -2075,7 +2074,7 @@ System.out.println("The GeoAPI interface
   We could stipulate that all longitudes below -180° or above 180° are considered excluded,
   but this would be an arbitrary decision that would not be an exact counterpart to the usual
case (green rectangle).
   A developer may wish to use these values, for example, in a mosaic where the map of the
world is repeated several times
-  horizontally so as not to cause confusion.
+  horizontally and each repetition is considered distinct.
   If developers wish to perform operations as though the regions of inclusion or exclusion
were repeated every 360°,
   they themselves will have to bring the longitudinal values between -180° and 180° in
advance.
   All the <code class="SIS">add(…)</code>, <code class="SIS">contains(…)</code>,
@@ -2121,7 +2120,7 @@ System.out.println("The GeoAPI interface
     But in <abbr title="Spatial Information System">SIS</abbr> envelopes,
     they may actually return opposite results for axes using <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
     An envelope whose range is [0 … 0], [-0 … -0] or [-0 … +0] would normally
be considered an empty envelope,
-    but the [+0 … -0] range would in fact be considered to include the entire, infinite
totality of values.
+    but the [+0 … -0] range would in fact be considered to include the entire set of
values all around the world.
     This behaviour conforms to the definition of <code class="SIS">lowerCorner</code>
and <code class="SIS">upperCorner</code>,
     which considers +0 as the starting point, and -0 as the end-point after cycling through
all possible values.
     Such behaviour only occurs for the pair of values +0 and -0, and only in that order.
@@ -2136,7 +2135,7 @@ System.out.println("The GeoAPI interface
 <p>
   Images, or <i>rasters</i>, are a particular case of a data structure called
a <i>coverage</i>.
   We could think of this as a “coverage of data.”
-  The title of the standard that describes them, “Coverage Geometry and Functions,” (<abbr>ISO</abbr>
19123),
+  The title of the <abbr>ISO</abbr> 19123 standard that describes them, “Coverage
Geometry and Functions”,
   nicely summarizes the two essential elements of coverages:
 </p>
 <ul>
@@ -2167,7 +2166,7 @@ System.out.println("The GeoAPI interface
   </li>
 </ul>
 <p>
-  The characteristics of the spatial domain are defined by <abbr>ISO</abbr> Standard
19123,
+  The characteristics of the spatial domain are defined by <abbr>ISO</abbr> 19123
standard,
   while the characteristics of range are not included in the standard.
   The standard simply mentions that ranges may be finite or infinite,
   and are not necessarily numerical.
@@ -2186,7 +2185,7 @@ System.out.println("The GeoAPI interface
     classes respectively.
     The <code class="SIS">NumberRange</code> is used more often, and is also
the one that most closely approaches the
     <a href="http://fr.wikipedia.org/wiki/Intervalle_%28math%C3%A9matiques%29">the
common mathematical concept of an interval</a>.
-    This textual representation approaches the specifications of <abbr>ISO</abbr>
Standard 31-11,
+    This textual representation approaches the specifications of <abbr>ISO</abbr>
31-11 standard,
     except that the comma is replaced by the character “…” as the separator of minimal
and maximal values.
     For example, “[0 … 256)” represents the range of values from 0 inclusive to 256
exclusive.
   </p>

Modified: sis/site/trunk/content/book/fr/developer-guide.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/fr/developer-guide.html?rev=1629807&r1=1629806&r2=1629807&view=diff
==============================================================================
--- sis/site/trunk/content/book/fr/developer-guide.html [UTF-8] (original)
+++ sis/site/trunk/content/book/fr/developer-guide.html [UTF-8] Tue Oct  7 06:31:28 2014
@@ -2034,15 +2034,15 @@ System.out.println("L’interface GeoAPI
   à ceci près que le nombre d’éléments contenus dans cet ensemble est infini (à l’exception
des géométries représentant un simple point).
   Pour mieux représenter ce concept, la norme <abbr title="International Organization
for Standardization">ISO</abbr> et GeoAPI définissent une interface <code class="OGC">TransfiniteSet</code>
   que l’on peut voir comme un <code>Set</code> de taille infini. Bien qu’un
lien de parenté existe conceptuellement entre ces interfaces,
-  GeoAPI ne définit pas <code class="GeoAPI">TransfiniteSet</code> comme une
sous-interface de <code>java.util.Collection</code>
+  GeoAPI ne définit pas <code class="GeoAPI">TransfiniteSet</code> comme une
sous-interface de <code>java.util.Set</code>
   car la définition de certaines méthodes telles que <code>size()</code> et
<code>iterator()</code> serait problématique.
   On y retrouve toutefois des méthodes très similaires telles que <code class="GeoAPI">contains(…)</code>
et <code class="GeoAPI">intersects(…)</code>.
 </p>
 <p>
-  La classe parente de toutes les géométries est appelée <code class="OGC">GM_Object</code>
dans la norme <abbr>ISO</abbr> 19107.
+  Toutes les géométries sont des spécialisations de <code class="GeoAPI">TransfiniteSet</code>.
+  La classe parente de toutes ces géométries est appelée <code class="OGC">GM_Object</code>
dans la norme <abbr>ISO</abbr> 19107.
   Les interfaces de GeoAPI utilisent plutôt le nom <code class="GeoAPI">Geometry</code>,
car l’omission du préfixe <code class="OGC">GM_</code>
   (comme le veut la convention dans GeoAPI) aurait laissé un nom trop proche de la classe
<code>Object</code> du Java.
-  Toutes les géométries sont des spécialisations de <code class="GeoAPI">TransfiniteSet</code>.
 </p>
 
 
@@ -2145,7 +2145,7 @@ System.out.println("L’interface GeoAPI
   Nous pourrions stipuler que toute longitude inférieure à -180° ou supérieure à 180°
est considérée exclue,
   mais ça serait une décision arbitraire qui ne serait pas un reflet symétrique du cas
habituel (rectangle vert).
   Un développeur pourrait vouloir utiliser ces valeurs, par exemple dans une mosaïque où
la carte du monde
-  est répétée plusieurs fois horizontalement sans pour autant les confondre.
+  est répétée plusieurs fois horizontalement tout en considérant chaque répétition
comme distincte des autres.
   Si un développeur souhaite effectuer des opérations comme si les régions d’inclusions
ou d’exclusions étaient
   répétées tous les 360°, alors il doit lui-même ramener ses valeurs de longitudes entre
-180° et 180° au préalable.
   Toutes les fonctions <code class="SIS">add(…)</code>, <code class="SIS">contains(…)</code>,



Mime
View raw message