start fixing spelling

docs/common.py

@@ -24,7 +24,7 @@
 
 # Add any Sphinx extension module names here, as strings. They can be extensions
 # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = ['sphinx.ext.todo','sphinx.ext.extlinks']
+extensions = ['sphinx.ext.todo','sphinx.ext.extlinks', 'sphinxcontrib.spelling']
 
 extlinks = { 
     'wiki': ('https://github.com/geotools/geotools/wiki/%s',''),
@@ -112,6 +112,11 @@
 # A list of ignored prefixes for module index sorting.
 #modindex_common_prefix = []
 
+# Spelling options
+
+spelling_lang='en_US'
+spelling_show_suggestions=True
+spelling_word_list_filename='./spelling/local.dict'
 
 # -- Options for HTML output ---------------------------------------------------
 

docs/developer/conventions/code/assumptions.rst

@@ -89,7 +89,7 @@ The above code is wrong for two reasons described below:
 
   If you are tempted to fetch different coefficients in an affine transform according some conditions, it is worth to take a paper and a pencil, write down the matrix and see if the equations can be written in some form invariant to rotation, flipping or axis swapping. This is often possible and leads to more robust and generic code.
 
-  It may sound like paranoiac, but it is not. Old Geotools code was assuming (longitude,latitude) axis order in all cases, for example through unconditional calls to AffineTransform.getScaleX(). It required a great amount of energy from nice volunter in order to handle the (latitude,longitude) axis order as well. Unfortunatly the initial fix for this axis order issue, based on the "Axis Interchange with Modal Code" approach, has just pushed the problem a little bit further away. The code will fails for the next great Geotools step: 3D-Coverage. Users will want to see 2D slices using a wide range axis that are not longitude or latitude. It is better to make the best possible use of affine transform mathematic early than revisiting again the whole Geotools code base as in the "axis order issue" case.
+  It may sound like paranoiac, but it is not. Old GeoTools code was assuming (longitude,latitude) axis order in all cases, for example through unconditional calls to AffineTransform.getScaleX(). It required a great amount of energy from nice volunter in order to handle the (latitude,longitude) axis order as well. Unfortunatly the initial fix for this axis order issue, based on the "Axis Interchange with Modal Code" approach, has just pushed the problem a little bit further away. The code will fails for the next great GeoTools step: 3D-Coverage. Users will want to see 2D slices using a wide range axis that are not longitude or latitude. It is better to make the best possible use of affine transform mathematic early than revisiting again the whole GeoTools code base as in the "axis order issue" case.
 
 Prefer MathTransform over GridRange - Envelope pair
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -101,4 +101,4 @@ In some place of GeoTools API, a MathTransform is inferred automatically from a
 
 While the GridRange - Envelope pair seems easier and more intuitive, it is also ambiguous. There is no way to infer a MathTransform from this pair without making some assumptions on axis order and axis reversal. For example GeneralGridGeometry assumes that the y axis must be reversed in order to match the direction used in most screen devices (y values increasing down). Only the constructor with MathTransform argument is unambiguous.
 
-GridRange - Envelope pairs are provided as a convenience for helping users to get their first math transform right in a majority (but not all) cases. From that point, Geotools code should perform all their internal work on MathTransform, never on Envelope. Need to expand an envelope? Compute a scale affine transform and concatenate it with the user math transform. Need to translate, flip or swap axis? Same approach: express your change as an other transform, then concatenate.
+GridRange - Envelope pairs are provided as a convenience for helping users to get their first math transform right in a majority (but not all) cases. From that point, GeoTools code should perform all their internal work on MathTransform, never on Envelope. Need to expand an envelope? Compute a scale affine transform and concatenate it with the user math transform. Need to translate, flip or swap axis? Same approach: express your change as an other transform, then concatenate.

docs/developer/conventions/code/log.rst

@@ -130,7 +130,7 @@ Provides fairly detailed logging message from the GML module, but not from the r
 Log4J interoperability
 ^^^^^^^^^^^^^^^^^^^^^^
 
-Geotools can produces a console output similar to the Log4J one (single-line instead of multi-line log message) if the following code is invoked once at application starting time::
+GeoTools can produces a console output similar to the Log4J one (single-line instead of multi-line log message) if the following code is invoked once at application starting time::
 
    Logging.ALL.forceMonolineConsoleOutput();
 

docs/developer/conventions/module.rst

@@ -1,7 +1,7 @@
 Module Directory Structure
 ==========================
 
-Geotools 2.4 and above complies to the Maven standard layout regarding nested modules; and the layout
+GeoTools 2.4 and above complies to the Maven standard layout regarding nested modules; and the layout
 of source code directories.
 
 This section provides a summary of module structure and a examples how we have groupled modules

docs/developer/conventions/profile.rst

@@ -18,7 +18,7 @@ License management
 YourKit is a commercial product, which provides open source project
 committers with free licenses.
 
-Geotools PMC has been granted 10 licenses, each one can be used by at most
+GeoTools PMC has been granted 10 licenses, each one can be used by at most
 one developer in a given period of time.
 Andrea Aime is managing the licenses now, so if you feel like using
 YourKit for profiling the gt2 source code base please:

docs/developer/conventions/refactor.rst

@@ -16,7 +16,7 @@ This is especially important when using either of the tools at the end of this p
 Changing public API
 ^^^^^^^^^^^^^^^^^^^
 
-Before to refactor a method, make sure that it did not have public access in the previous Geotools release.
+Before to refactor a method, make sure that it did not have public access in the previous GeoTools release.
 
 * If it was public, then we need to go through a "deprecate, then remove" cycle.
 * If not was not public, go ahead with with the refactoring. 
@@ -30,7 +30,7 @@ For example consider the following method::
        // Do something
    }
 
-Suppose that Geotools 2.3 is already released and we are working on Geotools 2.4. Suppose that we want to add a String argument to the above method. Do not refactor this method directly like this:
+Suppose that GeoTools 2.3 is already released and we are working on GeoTools 2.4. Suppose that we want to add a String argument to the above method. Do not refactor this method directly like this:
 
 WRONG::
 
@@ -41,7 +41,7 @@ WRONG::
        // Do something
    }
 
-Instead, duplicate the method for at least one Geotools release:
+Instead, duplicate the method for at least one GeoTools release:
 
 Better::
 
@@ -63,7 +63,7 @@ Better::
        // Do something
    }
 
-Note the @since 2.4 javadoc tag. It is an important hint for both users and the module maintainer, so do not forget it. The deprecated method can be removed in Geotools 2.5.
+Note the @since 2.4 javadoc tag. It is an important hint for both users and the module maintainer, so do not forget it. The deprecated method can be removed in GeoTools 2.5.
 
 Keep methods private
 ^^^^^^^^^^^^^^^^^^^^^
@@ -84,7 +84,7 @@ RefactorIt
    * and provide code metrics.
    * More details can be found from the online help.
 
-   RefactorIt is commercial, but provides free licences for Open Source projects like Geotools.
+   RefactorIt is commercial, but provides free licences for Open Source projects like GeoTools.
    See the RefactorIt web pages for details. It can be plugged into a variety of IDEs, including
    Netbeans.
 

docs/developer/conventions/test/junit.rst

@@ -15,7 +15,7 @@ The general idea:
 * create a file test/org/geotools/module/HelloWorldTest.java
 * any public void methods starting with test will be run by JUnit
 * maven will run all tests for your module using: mvn test 
-* tests can be ignored using you pom.xml file
+* tests can be ignored using you ``pom.xml`` file
 * maven will not "release" your module into the repository while it still fails unit testing
 
 Example TestCase

docs/developer/conventions/test/online.rst

@@ -1,7 +1,7 @@
 Online Tests
 ------------
 
-We make use of a naming convention, ie ensure the name of your TestCase ends in OnlineTest, to indicate the use of external web services and databases. If a unit test requires a network connection to pass, it is an online test.
+We make use of a naming convention, i.e. ensure the name of your TestCase ends in OnlineTest, to indicate the use of external web services and databases. If a unit test requires a network connection to pass, it is an online test.
 
 These tests will be skipped as part of the normal build process, but will be executed by certain build boxes.
 

docs/developer/conventions/version.rst

@@ -72,7 +72,7 @@ The release process has changed a bit since moving to subversion for details ple
 @since javadoc tag
 ^^^^^^^^^^^^^^^^^^^
 
-Every public and protected class, interface, method or field should have a @since javadoc tag. If the Geotools 2.2 release is under development, then every new API should be identified with a @since 2.2 tag. For the end user, it means that:
+Every public and protected class, interface, method or field should have a @since javadoc tag. If the GeoTools 2.2 release is under development, then every new API should be identified with a @since 2.2 tag. For the end user, it means that:
 
 * All classes and methods with a @since 2.0 or @since 2.1 javadoc tag are safe. Because they were there is previous releases, they will not change except for bug fixes (a few of them may be deprecated however).
 

docs/developer/docs/tutorial.rst

@@ -72,7 +72,7 @@ Here is an example template to get you started.
         and you will have a chance to try out using PostGIS or a Web Feature Server at the end of this
         example.
 
-        1. Please ensure your pom.xml includes the following:
+        1. Please ensure your ``pom.xml`` includes the following:
 
            .. literalinclude:: artifacts/pom.xml
               :language: xml

docs/developer/procedures/add.rst

@@ -30,7 +30,7 @@ Review a couple of the repository search websites:
         <version>1.0.2</version>
       </dependency>
 
-3. Navigate to the root pom.xml for the project and go to the dependency management section.
+3. Navigate to the root ``pom.xml`` for the project and go to the dependency management section.
 
    Cut and past paste the dependency information here as well::
 
@@ -40,7 +40,7 @@ Review a couple of the repository search websites:
         <version>1.0.2</version>
       </dependency>
 
-3. You can then adjust your pom.xml to not include the version number (as it will be retrieved
+3. You can then adjust your ``pom.xml`` to not include the version number (as it will be retrieved
    from the dependency management section).::
 
       <dependency>
@@ -52,14 +52,14 @@ Review a couple of the repository search websites:
 Recommended reading on Dependencies
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If you are not familiar with the way to declare a dependency in a Maven pom.xml file, see "How do I use external dependencies?" in the Maven Getting started guide. More information can also be found in the Guide to deploying 3rd party JARs to remote repository in Maven documentation.
+If you are not familiar with the way to declare a dependency in a Maven ``pom.xml`` file, see "How do I use external dependencies?" in the Maven Getting started guide. More information can also be found in the Guide to deploying 3rd party JARs to remote repository in Maven documentation.
 
 References:
 
 * http://maven.apache.org/guides/getting-started/index.html
 * http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
 
-Our build process does not include jar files inside the subversion repository, instead Maven downloads jar files it needs from remote repositories (web sites). The location of these web sites is specified in the parent pom.xml file, which is inherited by all modules. There are mainly three sites available:
+Our build process does not include jar files inside the subversion repository, instead Maven downloads jar files it needs from remote repositories (web sites). The location of these web sites is specified in the parent ``pom.xml`` file, which is inherited by all modules. There are mainly three sites available:
 
 * Java.net repository
 
@@ -82,14 +82,14 @@ Our build process does not include jar files inside the subversion repository, i
 
   General utility open source projects, especially apache related
 
-Take a look at these sites and some of the "mystery" out of how Maven works. You may notice that the directory structure matches the dependency entries that you see in the pom.xml files. If the dependency entry has a groupId tag then this will be the name of the folder, if it just has an id tag then this will be used for the name of the folder and the jar within it.
+Take a look at these sites and some of the "mystery" out of how Maven works. You may notice that the directory structure matches the dependency entries that you see in the ``pom.xml`` files. If the dependency entry has a groupId tag then this will be the name of the folder, if it just has an id tag then this will be used for the name of the folder and the jar within it.
 
 It is always worth taking a look at these sites (particularly the maven one) just to check that a version of the jar you want to use is not already available.
 
 It really is not available - how to upload?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Assuming the jar you want is not already hosted on one of these sites you need to upload it and add a dependency entry to your pom.xml file.
+Assuming the jar you want is not already hosted on one of these sites you need to upload it and add a dependency entry to your ``pom.xml`` file.
 
 * Upload with Maven (not by copy-and-paste)
 
@@ -169,7 +169,7 @@ Uploading to Ibiblio
 Examples of Updating JTS Jar
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-1. Change into one of the GeoTools directories (the geotools pom.xml has all the
+1. Change into one of the GeoTools directories (the geotools ``pom.xml`` has all the
    repository definitions so changing directories is easier than editing your settings.xml)::
 
      C:\> cd java\geotools\trunk

docs/developer/procedures/check.rst

@@ -25,7 +25,7 @@ Here is how a plugin (aka hooks into the geotools library) may earn a star:
 
 * Passes IP check, basically has correct headers
 * Releasable - has no non blocking bugs in jira
-* Used in anger - Used by GeoServer or uDig or Geomajas (ie some kind of large real world datasets)
+* Used in anger - Used by GeoServer or uDig or Geomajas (i.e. some kind of large real world datasets)
 * Optimised - has been tuned to meet hard performance requirements (example shapefile)
 * Supported - user docs, module maintainer watches user list, answers email etc.. (example referencing)
 

docs/developer/procedures/create.rst

@@ -85,7 +85,7 @@ The modules/unsupported/ directory is there to welcome your experimental work; t
 
 #. pom.xml
 
-   We start by getting the pom.xml configured since maven will need that to work against the module. The following will start you out:
+   We start by getting the ``pom.xml`` configured since maven will need that to work against the module. The following will start you out:
 
    Change all occurances of the word example to the name of your module::
 

docs/developer/procedures/git.rst

@@ -244,7 +244,7 @@ of for rebasing include:
 
    It is **critically important** that rebasing never occur on a shared or primary
    branch. The rule of thumb with rebasing is that you must **never** rewrite commits
-   that are not strictly local, ie commits that have been pushed up to an online
+   that are not strictly local, i.e. commits that have been pushed up to an online
    repository.
 
 Other Tips

docs/developer/procedures/release.rst

@@ -29,7 +29,7 @@ Versions and revisions
 
 When performing a release we don't require a "code freeze" in which no developers can commit to the repository. Instead we release from a revision that is known to pass all tests, including unit/integration tests as well as CITE tests on the GeoServer side. These instructions are valid in case you are making a release in combination with GeoServer, if you are making a stand alone release it's up to you to choose the proper GIT revision number for the GeoTools released to be picked from.
 
-To obtain the GeoServer and Geotools revisions that have passed the `CITE test <https://build.geoserver.org/view/testing-cite/>`_, navigate to the latest Jenkins run of the CITE test  and view it's console output and select to view its full log. For example:
+To obtain the GeoServer and GeoTools revisions that have passed the `CITE test <https://build.geoserver.org/view/testing-cite/>`_, navigate to the latest Jenkins run of the CITE test  and view it's console output and select to view its full log. For example:
 
     https://build.geoserver.org/job/2.11-cite-wms-1.1/286/consoleText
 
@@ -77,10 +77,10 @@ When creating the first release candidate of a series, there are some extra step
 
 * Enable `GitHub branch protection <https://github.com/geotools/geotools/settings/branches>`_ for the new stable branch: tick "Protect this branch" (only) and press "Save changes".
 
-* Checkout the master branch and update the version in all pom.xml files and a few miscellaneous files; for example, if changing master from ``17-SNAPSHOT`` to ``18-SNAPSHOT``::
+* Checkout the master branch and update the version in all ``pom.xml`` files and a few miscellaneous files; for example, if changing master from ``17-SNAPSHOT`` to ``18-SNAPSHOT``::
 
     git checkout master
-    find . -name pom.xml -exec sed -i 's/17-SNAPSHOT/18-SNAPSHOT/g' {} \;
+    find . -name ``pom.xml`` -exec sed -i 's/17-SNAPSHOT/18-SNAPSHOT/g' {} \;
     sed -i 's/17-SNAPSHOT/18-SNAPSHOT/g' \
         build/rename.xml \
         docs/build.xml \
@@ -129,7 +129,7 @@ Run the `geotools-release <https://build.geoserver.org/view/geotools/job/geotool
 
 **REV**
 
-  The Git revision number to release from. eg, "24ae10fe662c....". If left blank the latest revision (ie HEAD) on the ``BRANCH`` being released is used.
+  The Git revision number to release from. eg, "24ae10fe662c....". If left blank the latest revision (i.e. HEAD) on the ``BRANCH`` being released is used.
 
 **VERSION**