sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1621151 - /sis/site/trunk/content/book/en/developer-guide.html
Date Thu, 28 Aug 2014 15:09:03 GMT
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>



Mime
View raw message