You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sis.apache.org by de...@apache.org on 2014/08/28 17:09:03 UTC

svn commit: r1621151 - /sis/site/trunk/content/book/en/developer-guide.html

Author: desruisseaux
Date: Thu Aug 28 15:09:03 2014
New Revision: 1621151

URL: http://svn.apache.org/r1621151
Log:
Replacement of a few quote characters by the Unicode “” symbols.

Modified:
    sis/site/trunk/content/book/en/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=1621151&r1=1621150&r2=1621151&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] Thu Aug 28 15:09:03 2014
@@ -281,7 +281,7 @@
   <abbr title="Open Geospatial Consortium">OGC</abbr> standards are specified in several dozen documents.
   Each document outlines a service — for example, the transformation of coordinates.
   The function of each service is described by a collection of object classes and their interactions.
-  These elements are illustrated by <abbr>UML</abbr> (Unified Modeling Language) diagrams in specifications called "abstracts."
+  These elements are illustrated by <abbr>UML</abbr> (Unified Modeling Language) diagrams in specifications called “abstracts.”
 </p><p>
   <a href="http://www.opengeospatial.org/standards/as">Abstract specifications</a> do not refer to any specific information language.
   Their concepts may be applied more or less directly to a programming language, a database or an <abbr>XML</abbr> schema.
@@ -303,17 +303,17 @@
 </ul>
 <p>
   At the turn of the millennium, the abstract specifications were explicitly concretized in <i>implementation specifications</i>.
-  The term "implementation" is used here in the sense of all types of interfaces (Java or others) derived from <abbr title="Unified Modeling Language">UML</abbr> diagrams, and not implementations in the Java sense.
+  The term “implementation” is used here in the sense of all types of interfaces (Java or others) derived from <abbr title="Unified Modeling Language">UML</abbr> diagrams, and not implementations in the Java sense.
   Such specifications exist for <abbr title="Structured Query Language">SQL</abbr>, <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr>, and Java languages.
   As these languages are capable of executing procedures, the specifications of this period define not only data structures,
   but also operations that apply to these structures.
 </p><p>
-  Thereafter, enthusiasm for "Web 2.0" increased interest <abbr>XML</abbr> over other languages.
+  Thereafter, enthusiasm for “Web 2.0” increased interest <abbr>XML</abbr> over other languages.
   Older implementation specifications were deprecated,
   and <abbr title="XML Schema Definition">XSD</abbr> schemas became the principle concretization of abstract specifications.
   Even the way abstract specifications are designed has evolved: they are less likely to define operations, and so what remains is closer to descriptions of database schemas.
   Some operations that were defined in older standards now appear, in another form, in web service specifications.
-  Finally, the term "implementation specification" has been deprecated, to be subsumed under the term "<abbr title="Open Geospatial Consortium">OGC</abbr> standard."
+  Finally, the term “implementation specification” has been deprecated, to be subsumed under the term “<abbr title="Open Geospatial Consortium">OGC</abbr> standard.”
   But despite their depreciation, <a href="http://www.opengeospatial.org/standards/retired">old implementation specifications</a> remain useful to programs in Java, because:
 </p>
 <ul>
@@ -330,7 +330,7 @@
 </ul>
 <p>
   The Apache <abbr title="Spatial Information System">SIS</abbr> project is based on the most recent specifications, drawing from the archives of the <abbr title="Open Geospatial Consortium">OGC</abbr> to complete certain abstract standards or make them more usable.
-  Some old definitions are preserved as "methods of convenience," not always bringing new functionality, but facilitating the practical use of a library.
+  Some old definitions are preserved as “methods of convenience,” not always bringing new functionality, but facilitating the practical use of a library.
 </p><p>
   The following table lists the principal norms used by the project.
   Many norms are published both as <abbr title="International Organization for Standardization">ISO</abbr> standards and as
@@ -549,7 +549,7 @@
     At this time, the wave of web services had not yet eclipsed classical programming interfaces.
     The interfaces of the <abbr title="Open Geospatial Consortium">OGC</abbr> did anticipate a networked world,
     but invested rather — in the case of Java — in <abbr>RMI</abbr> (<i>Remote Method Invocation</i>) technology.
-    As the GeoAPI project did not yet exist, we retroactively designate these historical interfaces "<a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a>."
+    As the GeoAPI project did not yet exist, we retroactively designate these historical interfaces “<a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a>.”
     These interfaces already used the pacet name <code class="GeoAPI">org.opengis</code>, which would be adopted by GeoAPI.
   </p><p>
     In 2002, developers of free projects launched a <a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">call
@@ -557,7 +557,7 @@
     The initial proposal attracted the interest of at least five free projects.
     The project was created using <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
     which has since hosted the source code in a <a href="http://www.geoapi.org/source-repository.html">Subversion repository</a>.
-    It was then that the project assumed the name "GeoAPI," and used the interfaces of the <abbr>OGC</abbr> specification 01-009 as a starting point.
+    It was then that the project assumed the name “GeoAPI,” and used the interfaces of the <abbr>OGC</abbr> specification 01-009 as a starting point.
   </p><p>
     A few months later, the <abbr title="Open Geospatial Consortium">OGC</abbr> launched the <a href="http://www.opengeospatial.org/standards/go"><abbr>GO</abbr>-1: <i>Geographic Objects</i></a> project,
     which pursued goals similar to those of GeoAPI.
@@ -571,9 +571,9 @@
     The <abbr>GO</abbr>-1 project was largely supported by a company called <i>Polexis</i>.
     Its acquisition by <i>Sys Technology</i>, and the change in priorities under the new owners,
     brought a halt to the <abbr>GO</abbr>-1 project, which in turn slowed development on GeoAPI.
-    In order to resume development, a new working group entitled "GeoAPI 3.0" was created at the <abbr title="Open Geospatial Consortium">OGC</abbr>.
+    In order to resume development, a new working group entitled “GeoAPI 3.0” was created at the <abbr title="Open Geospatial Consortium">OGC</abbr>.
     This group took a narrower focus compared to GeoAPI 2.0, concentrating on the most stable interfaces, and putting the others
-    — such as geometries — in a module entitled "<a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a>," for future consideration.
+    — such as geometries — in a module entitled “<a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a>,” for future consideration.
     <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> became an <a href="http://www.opengeospatial.org/standards/geoapi"><abbr>OGC</abbr> standard</a> in 2011.
     This version was the first to be deployed in the <a href="http://search.maven.org/#search|ga|1|geoapi">Maven central repository</a>.
   </p>
@@ -628,7 +628,7 @@
       <code class="GeoAPI">Identifier</code> interface in the <code class="GeoAPI">org.opengis.metadata</code> package.
       The <abbr>OGC</abbr> class <code class="OGC">SC_CRS</code> becomes the <code class="GeoAPI">CoordinateReferenceSystem</code> interface,
       and the <code class="OGC">usesDatum</code> association becomes a <code class="GeoAPI">getDatum()</code> method,
-      rather than the "<code>getUsesDatum()</code>" that would result from an automatic conversion tool.
+      rather than the “<code>getUsesDatum()</code>” that would result from an automatic conversion tool.
       We do not allow programs to blindly apply rules that ignore the conventions of the community whose schemas we translate.
     </p></div>
   </li>
@@ -680,7 +680,7 @@
       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
       directly in the parent class if there had been time.
-      In GeoAPI, we have chosen to "repair" these anomalies by fusing these two classes into a single interface.
+      In GeoAPI, we have chosen to “repair” these anomalies by fusing these two classes into a single interface.
     </p></div>
   </li>
 </ul>
@@ -1499,7 +1499,7 @@ System.out.println("The GeoAPI interface
     <abbr title="Java Architecture for XML Binding">JAXB</abbr> adaptors for all types of <abbr>ISO</abbr> objects.
     These adaptors are required in any case to allow <abbr>JAXB</abbr> to get
     <abbr title="Spatial Information System">SIS</abbr> classes while implementing GeoAPI interfaces.
-    Conveniently, <abbr>SIS</abbr> made both <abbr>JAXB</abbr> adaptors and objects wrapping the "real" object
+    Conveniently, <abbr>SIS</abbr> made both <abbr>JAXB</abbr> adaptors and objects wrapping the “real” object
     to be read or written.
     This double usage avoids having to double the number of classes (already quite high) present in the internal packages.
   </p>
@@ -2066,7 +2066,7 @@ System.out.println("The GeoAPI interface
     Apache <abbr>SIS</abbr> inspects these attributes to determine the way in which it must perform these operations.
     Thus, any axis associated with the code <code class="GeoAPI">RangeMeaning.WRAPAROUND</code> benefit from
     the same treatment as does longitude.
-    For example, this could be a time axis for climatological data (one "year" represents the average temperature in all the
+    For example, this could be a time axis for climatological data (one “year” represents the average temperature in all the
     months of January, followed by the average of all the months of February, etc.)
     This generalization also applies to longitude axes defined by a range of 0° to 360° rather than -180° to 180°.
   </p>
@@ -2107,8 +2107,8 @@ System.out.println("The GeoAPI interface
 <h1 id="Coverage">Data Coverages</h1>
 <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),
+  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),
   nicely summarizes the two essential elements of coverages:
 </p>
 <ul>
@@ -2133,7 +2133,7 @@ System.out.println("The GeoAPI interface
       Different types of coverages may be characterized by the geometry of their cells.
       In particular, a coverage is not necessarily composed of quadrilateral cells.
       However, given that quadrilateral cells are by far the most frequent (since this is the usual geometry of image pixels),
-      we often use the term "grid coverage" to specify coverages composed of such cells.
+      we often use the term “grid coverage” to specify coverages composed of such cells.
       In <abbr title="Spatial Information System">SIS</abbr>, the geometry of coverages is described by the <code class="SIS">GridGeometry</code> class.
     </p>
   </li>
@@ -2143,7 +2143,7 @@ System.out.println("The GeoAPI interface
   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.
-  For example, the values returned by a coverage may come from an enumeration ("this is a forest," "this is a lake," etc.).
+  For example, the values returned by a coverage may come from an enumeration (“this is a forest,” “this is a lake,” etc.).
   However, the standard defines two important types of coverage which have an impact on the types of authorized ranges:
   <i>discrete</i> coverages and <i>continuous</i> coverages.
   Stated simply, continuous coverages are functions that can use interpolation methods.
@@ -2159,7 +2159,7 @@ System.out.println("The GeoAPI interface
     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,
-    except that the comma is replaced by the character "..." as the separator of minimal and maximal values.
+    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>
   <p>