Merge branch 'hobu-docs-refactor'

11 files changed, 1865 insertions, 0 deletions

diff --git a/docs/source/_templates/layout.html b/docs/source/_templates/layout.html
new file mode 100644
index 00000000..df00789a
--- /dev/null
+++ b/docs/source/_templates/layout.html
@@ -0,0 +1,20 @@
+{# Import the theme's layout. #}
+{% extends "!layout.html" %}
+
+{# Add some extra stuff before and use existing with 'super()' call. #}
+
+{%- block footer %}
+    <div class="footer">
+        <div class="container">
+                    &copy;  {{ copyright }}
+                        Gerald Evenden,
+                        <a href="https://github.com/warmerdam">Frank Warmerdam</a>,
+                        and
+                        <a href="https://github.com/OSGeo/proj.4/graphs/contributors">others</a>,
+            {%- if last_updated %}
+                {% trans last_updated=last_updated|e %}Last updated
+                    on {{ last_updated }}.{% endtrans %}
+            {%- endif %}
+        </div>
+    </div>
+{%- endblock %}
diff --git a/docs/source/conf.py b/docs/source/conf.py
new file mode 100644
index 00000000..5f6f3125
--- /dev/null
+++ b/docs/source/conf.py
@@ -0,0 +1,352 @@
+# -*- coding: utf-8 -*-
+#
+# proj.4 documentation build configuration file, created by
+# sphinx-quickstart on Wed Feb 24 10:47:15 2016.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+import sphinx_bootstrap_theme
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.insert(0, os.path.abspath('.'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# 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.mathjax',
+]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'proj.4'
+copyright = u'1992-2016, Gerald Evenden, Frank Warmerdam, and others'
+author = u'Gerald Evenden'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = u'4.9.2'
+# The full version, including alpha/beta/rc tags.
+release = u'4.9.2'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = []
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'bootstrap'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+html_theme_options = {
+    # Navigation bar title. (Default: ``project`` value)
+    'navbar_title': "",
+
+    # Tab name for entire site. (Default: "Site")
+    'navbar_site_name': "Docs",
+
+    # A list of tuples containing pages or urls to link to.
+    # Valid tuples should be in the following forms:
+    #    (name, page)                 # a link to a page
+    #    (name, "/aa/bb", 1)          # a link to an arbitrary relative url
+    #    (name, "http://example.com", True) # arbitrary absolute url
+    # Note the "1" or "True" value above as the third argument to indicate
+    # an arbitrary url.
+    'navbar_links': [
+        ("Download", "download"),
+        ("GitHub", "https://github.com/OSGeo/proj.4", True),
+    ],
+
+    # Render the next and previous page links in navbar. (Default: true)
+    'navbar_sidebarrel': True,
+
+    # Render the current pages TOC in the navbar. (Default: true)
+    'navbar_pagenav': True,
+
+    # Tab name for the current pages TOC. (Default: "Page")
+    'navbar_pagenav_name': "Here",
+
+    # Global TOC depth for "site" navbar tab. (Default: 1)
+    # Switching to -1 shows all levels.
+    'globaltoc_depth': 2,
+
+    # Include hidden TOCs in Site navbar?
+    #
+    # Note: If this is "false", you cannot have mixed ``:hidden:`` and
+    # non-hidden ``toctree`` directives in the same page, or else the build
+    # will break.
+    #
+    # Values: "true" (default) or "false"
+    'globaltoc_includehidden': "true",
+
+    # HTML navbar class (Default: "navbar") to attach to <div> element.
+    # For black navbar, do "navbar navbar-inverse"
+    'navbar_class': "navbar",
+
+    # Fix navigation bar to top of page?
+    # Values: "true" (default) or "false"
+    'navbar_fixed_top': "true",
+
+    # Location of link to source.
+    # Options are "nav" (default), "footer" or anything else to exclude.
+    'source_link_position': "nav",
+
+    # Bootswatch (http://bootswatch.com/) theme.
+    #
+    # Options are nothing (default) or the name of a valid theme
+    # such as "amelia" or "cosmo".
+    'bootswatch_theme': "paper",
+
+    # Choose Bootstrap version.
+    # Values: "3" (default) or "2" (in quotes)
+    'bootstrap_version': "3",
+}
+
+
+# Add any paths that contain custom themes here, relative to this directory.
+html_theme_path = sphinx_bootstrap_theme.get_html_theme_path()
+
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+html_show_sourcelink = False
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+#   'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
+#   'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# Now only 'ja' uses this config value
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'proj4doc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+    (master_doc, 'proj4.tex', u'proj.4 Documentation',
+     u'Gerald Evenden', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, 'proj4', u'proj.4 Documentation',
+     [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (master_doc, 'proj4', u'proj.4 Documentation',
+     author, 'proj4', 'One line description of project.',
+     'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
diff --git a/docs/source/download.rst b/docs/source/download.rst
new file mode 100644
index 00000000..69878748
--- /dev/null
+++ b/docs/source/download.rst
@@ -0,0 +1,22 @@
+.. _download:
+
+================================================================================
+Download
+================================================================================
+
+
+Current Release
+--------------------------------------------------------------------------------
+
+* **2015-09-13** `proj-4.9.2.tar.gz`_ `Release Notes`_ (`md5`_)
+
+Past Releases
+--------------------------------------------------------------------------------
+
+* **2015-03-04** `proj-4.9.1.tar.gz`_
+
+
+.. _`proj-4.9.1.tar.gz`: http://download.osgeo.org/proj/proj-4.9.1.tar.gz
+.. _`proj-4.9.2.tar.gz`: http://download.osgeo.org/proj/proj-4.9.2.tar.gz
+.. _`md5`: http://download.osgeo.org/proj/proj-4.9.2.tar.gz.md5
+.. _`Release Notes`: http://lists.maptools.org/pipermail/proj/2015-September/007270.html
diff --git a/docs/source/faq.rst b/docs/source/faq.rst
new file mode 100644
index 00000000..a289494c
--- /dev/null
+++ b/docs/source/faq.rst
@@ -0,0 +1,327 @@
+.. _faq:
+
+******************************************************************************
+FAQ
+******************************************************************************
+
+
+Where can I find the list of projections and their arguments?
+--------------------------------------------------------------------------------
+
+There is no simple single location to find all the required information. The
+!PostScript/PDF documents listed on the [http://trac.osgeo.org/proj/wiki main]
+PROJ.4 page under documentation are the authoritative source but projections
+and options are spread over several documents in a form more related to their
+order of implementation than anything else.
+
+The '''proj''' command itself can report the list of projections using the
+'''-lp''' option, the list of ellipsoids with the '''-le''' option, the list of
+units with the '''-lu''' option, and the list of built-in datums with the
+'''-ld''' option.
+
+The [http://www.remotesensing.org/geotiff/proj_list/ GeoTIFF Projections Pages]
+include most of the common PROJ.4 projections, and a definition of the
+projection specific options for each.
+
+* How do I do datum shifts between NAD27 and NAD83?
+
+While the '''nad2nad''' program can be used in some cases, the '''cs2cs''' is
+now the preferred mechanism.   The following example demonstrates using the
+default shift parameters for NAD27 to NAD83:
+
+
+::
+
+    % cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83 -117 30
+
+
+producing:
+
+::
+
+    117d0'2.901"W   30d0'0.407"N 0.000
+
+In order for datum shifting to work properly the various grid shift files must
+be available.  See below.  More details are available in the
+[wiki:GenParms#nadgrids-GridBasedDatumAdjustments General Parameters] document.
+
+How do I build/configure PROJ.4 to support datum shifting?
+--------------------------------------------------------------------------------
+
+After downloading and unpacking the PROJ.4 source, also download and unpack the
+set of datum shift files.  See :ref:`download` for instructions how to fetch
+and install these files
+
+On Windows the extra nadshift target must be used.  For instance
+``nmake /f makefile.vc nadshift`` in the ``proj/src`` directory.
+
+A default build and install on Unix will normally build knowledge of the
+directory where the grid shift files are installed into the PROJ.4 library
+(usually /usr/local/share/proj).  On Windows the library is normally built
+thinking that C:\PROJ\NAD is the installed directory for the grid shift files.
+If the built in concept of the PROJ.4 data directory is incorrect, the ``PROJ_LIB``
+environment can be defined with the correct directory.
+
+How do I debug problems with NAD27/NAD83 datum shifting?
+--------------------------------------------------------------------------------
+
+1. Verify that you have the binary files (eg. /usr/local/share/proj/conus)
+   installed on your system.  If not, see the previous question.
+2. Try a datum shifting operation in relative isolation, such as with the cs2cs
+   command listed above.  Do you get reasonable results?  If not it is likely
+   the grid shift files aren't being found.  Perhaps you need to define
+   PROJ_LIB?
+3. The cs2cs command and the underlying pj_transform() API know how to do a
+   grid shift as part of a more complex coordinate transformation; however, it
+   is imperative that both the source and destination coordinate system be
+   defined with appropriate datum information.  That means that implicitly or
+   explicitly there must be a +datum= clause, a +nadgrids= clause or a
+   +towgs84= clause.  For instance
+   ``cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +ellps=WGS84`` won't work because defining the output
+   coordinate system as using the ellipse WGS84 isn't the same as defining it
+   to use the datum WGS84 (use +datum=WGS84).  If either the input or output
+   are not identified as having a datum, the datum shifting (and ellipsoid
+   change) step is just quietly skipped!
+4. The ``PROJ_DEBUG`` environment can be defined (any value) to force extra output
+   from the PROJ.4 library to stderr (the text console normally) with
+   information on what data files are being opened and in some cases why a
+   transformation fails.
+
+   ::
+
+        export PROJ_DEBUG=ON
+        cs2cs ...
+
+
+   .. note::
+        ``PROJ_DEBUG`` support is not yet very mature in the PROJ.4 library.
+
+5. The ``-v`` flag to cs2cs can be useful in establishing more detail on what
+   parameters being used internally for a coordinate system.  This will include
+   expanding the definition of +datum clause.
+
+How do I use EPSG coordinate system codes with PROJ.4?
+--------------------------------------------------------------------------------
+
+There is somewhat imperfect translation between 2d geographic and projected
+coordinate system codes and PROJ.4 descriptions of the coordinate system
+available in the epsg definition file that normally lives in the proj/nad
+directory.  If installed (it is installed by default on Unix), it is possible
+to use EPSG numbers like this:
+
+::
+
+
+    % cs2cs -v +init=epsg:26711
+    # ---- From Coordinate System ----
+    #Universal Transverse Mercator (UTM)
+    #       Cyl, Sph
+    #       zone= south
+    # +init=epsg:26711 +proj=utm +zone=11 +ellps=clrk66 +datum=NAD27 +units=m
+    # +no_defs +nadgrids=conus,ntv1_can.dat
+    #--- following specified but NOT used
+    # +ellps=clrk66
+    # ---- To Coordinate System ----
+    #Lat/long (Geodetic)
+    #
+    # +proj=latlong +datum=NAD27 +ellps=clrk66 +nadgrids=conus,ntv1_can.dat
+
+The proj/nad/epsg file can be browsed and searched in a text editor for
+coordinate systems.  There are known to be problems with some coordinate
+systems, and any coordinate systems with odd axes, a non-greenwich prime
+meridian or other quirkyness are unlikely to work properly.  Caveat Emptor!
+
+How do I use 3 parameter and 7 parameter datum shifting
+--------------------------------------------------------------------------------
+
+Datum shifts can be approximated with 3 and 7 parameter transformations.  Their
+use is more fully described in the
+[wiki:GenParms#towgs84-DatumtransformationtoWGS84 towgs84] parameter
+discussion.
+
+Does PROJ.4 work in different international numeric locales?
+--------------------------------------------------------------------------------
+
+No.  PROJ.4 makes extensive use of sprintf() and atof() internally to translate
+numeric values.  If a locale is in effect that modifies formatting of numbers,
+altering the role of commas and periods in numbers, then PROJ.4 will not work.
+This problem is common in some European locales.
+
+On unix-like platforms, this problem can be avoided by forcing the use of the
+default numeric locale by setting the LC_NUMERIC environment variable to C.
+
+::
+
+    $ export LC_NUMERIC=C
+    $ proj ...
+
+.. note::
+
+    NOTE: Per ticket #49, in PROJ 4.7.0 and later pj_init() operates with locale
+    overriden to "C" to avoid most locale specific processing for applications
+    using the API.  Command line tools may still have issues.
+
+Changing Ellipsoid / Why can't I convert from WGS84 to Google Earth / Virtual Globe Mercator?
+----------------------------------------------------------------------------------------------
+
+The coordinate system definition for Google Earth, and Virtual Globe Mercator
+is as follows, which uses a sphere as the earth model for the Mercator
+projection.
+
+::
+
+    +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+         +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs
+
+But, if you do something like:
+
+::
+
+    cs2cs +proj=latlong +datum=WGS84
+        +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+                       +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs
+
+to convert between WGS84 and mercator on the sphere there will be substantial
+shifts in the Y mercator coordinates.  This is because internally cs2cs is
+having to adjust the lat/long coordinates from being on the sphere to being on
+the WGS84 datum which has a quite differently shaped ellipsoid.
+
+In this case, and many other cases using spherical projections, the desired
+approach is to actually treat the lat/long locations on the sphere as if they
+were on WGS84 without any adjustments when using them for converting to other
+coordinate systems.  The solution is to "trick" PROJ.4 into applying no change
+to the lat/long values when going to (and through) WGS84.  This can be
+accomplished by asking PROJ to use a null grid shift file for switching from
+your spherical lat/long coordinates to WGS84.
+
+::
+
+    cs2cs +proj=latlong +datum=WGS84 \
+        +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 \
+        +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
+
+Note the strategic addition of +nadgrids=@null to the spherical projection
+definition.
+
+Similar issues apply with many other datasets distributed with projections
+based on a spherical earth model - such as many NASA datasets.  This coordinate
+system is now known by the EPSG code 3857 and has in the past been known as
+EPSG:3785 and EPSG:900913.  When using this coordinate system with GDAL/OGR it
+is helpful to include the +wktext so the exact proj.4 string will be preserved
+in the WKT representation (otherwise key parameters like `+nadgrids=@null` will
+be dropped):
+
+::
+
+    +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0
+               +units=m +nadgrids=@null +wktext  +no_defs
+
+Why do I get different results with 4.5.0 and 4.6.0?
+--------------------------------------------------------------------------------
+
+The default datum application behavior changed with the 4.6.0 release.  PROJ.4
+will now only apply a datum shift if both the source and destination coordinate
+system have valid datum shift information.
+
+From the PROJ.4 4.6.0 Release Notes (in NEWS):
+ * MAJOR: Rework pj_transform() to avoid applying ellipsoid to ellipsoid
+   transformations as a datum shift when no datum info is available.
+
+
+How do I calculate distances/directions on the surface of the earth?
+--------------------------------------------------------------------------------
+
+These are called geodesic calculations. There is a page about it here:
+[wiki:GeodesicCalculations]
+
+What is the HEALPix projection and how can I use it?
+--------------------------------------------------------------------------------
+
+.. figure::
+    ../images/rhealpix.png
+    :scale: 40%
+    :align: left
+
+The HEALPix projection is area preserving and can be used with a
+spherical and ellipsoidal model.  It was initially developed for mapping cosmic
+background microwave radiation.  The image below is the graphical
+representation of the mapping and consists of eight isomorphic triangular
+interrupted map graticules.  The north and south contains four in which
+straight meridians converge polewards to a point and unequally spaced
+horizontal parallels.  HEALPix provides a mapping in which points of equal
+latitude and equally spaced longitude are mapped to points of equal latitude
+and equally spaced longitude with the module of the polar interruptions. ||
+
+To run a forward HEALPix projection on a unit sphere model, use the following command:
+
+::
+
+    proj +proj=healpix +lon_0=0 +a=1 -E <<EOF
+    0 0
+    EOF
+
+Output of the above command.
+
+::
+
+    0 0 0.00 0.00
+
+What is the rHEALPix projection and how can I use it?
+--------------------------------------------------------------------------------
+
+.. figure::
+    ../images/healpix.png
+    :scale: 40%
+    :align: left
+
+rHEALPix is a projection based on the HEALPix projection.  The implementation
+of rHEALPix uses the HEALPix projection.  The rHEALPix combines the peaks of
+the HEALPix into a square.  The square's position can be translated and rotated
+across the x-axis which is a noval approach for the rHEALPix projection.  The
+initial intention of using rHEALPix in the Spatial Computation Engine Science
+Collaboration Environment (SCENZGrid).
+
+To run a inverse rHEALPix projection on a WGS84 ellipsoidal model, use the following command:
+
+::
+
+    proj +proj=rhealpix -f '%.2f' -I +lon_0=0 +a=1 +ellps=WGS84 +npole=0 +spole=0 -E <<EOF
+    0 0.7853981633974483
+    EOF
+
+Where spole and npole are integers from the range of 0 to 3 inclusive and represent the positions of the north polar and south polar squares.
+
+Output of above command:
+
+::
+
+    0 0.7853981633974483 0.00 41.94
+
+What options does proj.4 allow for the shape of the Earth (geodesy)?
+--------------------------------------------------------------------------------
+
+See https://github.com/OSGeo/proj.4/blob/master/src/pj_ellps.c
+for possible ellipse options. For example, putting ``+ellps=WGS84`` uses
+the ``WGS84`` Earth shape.
+
+What if I want a spherical Earth?
+--------------------------------------------------------------------------------
+
+Use ``+ellps=sphere``.  See https://github.com/OSGeo/proj.4/blob/master/src/pj_ellps.c
+for the radius used in this case.
+
+How do I change the radius of the Earth?  How do I use proj.4 for work on Mars?
+--------------------------------------------------------------------------------
+
+You can supply explicit values for the semi minor and semi major axes instead
+of using the symbolic "sphere" value.  Eg, if the radius were 2000000m:
+
+::
+
+     +proj=laea +lon_0=-40.000000 +lat_0=74.000000 +x_0=1000000 +y_0=1700000 +a=2000000 +b=2000000"
+
+How do I do False Eastings and False Northings?
+--------------------------------------------------------------------------------
+
+Use ``+x_0`` and ``+y_0`` in the projection string.
+
diff --git a/docs/source/geodesic.rst b/docs/source/geodesic.rst
new file mode 100644
index 00000000..474cfdc1
--- /dev/null
+++ b/docs/source/geodesic.rst
@@ -0,0 +1,212 @@
+.. _geodesic:
+
+================================================================================
+Geodesic Calculations
+================================================================================
+
+Geodesic Calculations
+--------------------------------------------------------------------------------
+
+Geodesic calculations are calculations along lines (great circle) on the
+surface of the earth. They can answer questions like:
+
+ * What is the distance between these two points?
+ * If I travel X meters from point A at bearing phi, where will I be.  They are
+   done in native lat-long coordinates, rather than in projected coordinates.
+
+Relevant mailing list threads
+................................................................................
+
+ * http://thread.gmane.org/gmane.comp.gis.proj-4.devel/3361
+ * http://thread.gmane.org/gmane.comp.gis.proj-4.devel/3375
+ * http://thread.gmane.org/gmane.comp.gis.proj-4.devel/3435
+ * http://thread.gmane.org/gmane.comp.gis.proj-4.devel/3588
+ * http://thread.gmane.org/gmane.comp.gis.proj-4.devel/3925
+ * http://thread.gmane.org/gmane.comp.gis.proj-4.devel/4047
+ * http://thread.gmane.org/gmane.comp.gis.proj-4.devel/4083
+
+Terminology
+--------------------------------------------------------------------------------
+
+The shortest distance on the surface of a solid is generally termed a geodesic,
+be it an ellipsoid of revolution, aposphere, etc.  On a sphere, the geodesic is
+termed a Great Circle.
+
+HOWEVER, when computing the distance between two points using a projected
+coordinate system, that is a conformal projection such as Transverse Mercator,
+Oblique Mercator, Normal Mercator, Stereographic, or Lambert Conformal Conic -
+that then is a GRID distance which can be converted to an equivalent GEODETIC
+distance using the function for "Scale Factor at a Point."  The conversion is
+then termed "Grid Distance to Geodetic Distance," even though it will not be as
+exactly correct as a true ellipsoidal geodesic.  Closer to the truth with a TM
+than with a Lambert or other conformal projection, but still not exactly "on."
+
+
+So, it can be termed "geodetic distance" or a  "geodesic distance," depending
+on just how you got there ...
+
+
+The Math
+--------------------------------------------------------------------------------
+
+Spherical Approximation
+................................................................................
+
+The simplest way to compute geodesics is using a sphere as an approximation for
+the earth. This from Mikael Rittri on the Proj mailing list:
+
+    If 1 percent accuracy is enough, I think you can use spherical formulas
+    with a fixed Earth radius.  You can find good formulas in the Aviation
+    Formulary of Ed Williams, http://williams.best.vwh.net/avform.htm.
+
+    For the fixed Earth radius, I would choose the average of the:
+
+        c   = radius of curvature at the poles,
+        b^2^ / a = radius of curvature in a meridian plane at the equator,
+
+    since these are the extreme values for the local radius of curvature of the
+    earth ellipsoid.
+
+    If your coordinates are given in WGS84, then
+
+        c   = 6 399 593.626 m,
+        b^2^ / a = 6 335 439.327 m,
+
+    (see http://home.online.no/~sigurdhu/WGS84_Eng.html) so their average is 6,367,516.477 m.
+    The maximal error for distance calculation should then be less than 0.51 percent.
+
+    When computing the azimuth between two points by the spherical formulas,  I
+    think the maximal error on WGS84 will be 0.2 degrees, at least if the
+    points are not too far away (less than 1000 km apart, say). The error
+    should be maximal near the equator, for azimuths near northeast etc.
+
+I am not sure about the spherical errors for the forward geodetic problem:
+point positioning given initial point, distance and azimuth.
+
+Ellipsoidal Approximation
+................................................................................
+
+For more accuracy, the earth can be approximated with an ellipsoid,
+complicating the math somewhat.  See the wikipedia page, `Geodesics on an
+ellipsoid <https://en.wikipedia.org/wiki/Geodesics_on_an_ellipsoid>`__, for
+more information.
+
+Thaddeus Vincenty's method, April 1975
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For a very good procedure to calculate inter point distances see:
+
+http://www.ngs.noaa.gov/PC_PROD/Inv_Fwd/ (Fortan code, DOS executables, and an online app)
+
+and algorithm details published in: `Vincenty, T. (1975) <http://www.ngs.noaa.gov/PUBS_LIB/inverse.pdf>`__
+
+Javascript code
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Chris Veness has coded Vincenty's formulas as !JavaScript.
+
+distance: http://www.movable-type.co.uk/scripts/latlong-vincenty.html
+
+direct:   http://www.movable-type.co.uk/scripts/latlong-vincenty-direct.html
+
+C code
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+From Gerald Evenden: a library of the converted NGS Vincenty geodesic procedure
+and an application program, 'geodesic'.  In the case of a spherical earth
+Snyder's preferred equations are used.
+
+* http://article.gmane.org/gmane.comp.gis.proj-4.devel/3588/
+
+The link in this message is broken.  The correct URL is
+http://home.comcast.net/~gevenden56/proj/
+
+Earlier Mr. Evenden had posted to the PROJ.4 mailing list this code for
+determination of true distance and respective forward and back azimuths between
+two points on the ellipsoid.  Good for any pair of points that are not
+antipodal.
+Later he posted that this was not in fact the translation of NGS FORTRAN code,
+but something else. But, for what it's worth, here is the posted code (source
+unknown):
+
+* http://article.gmane.org/gmane.comp.gis.proj-4.devel/3478
+
+
+PROJ.4 - geod program
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+The PROJ.4 [wiki:man_geod geod] program can be used for great circle distances
+on an ellipsoid.  As of proj verion 4.9.0, this uses a translation of
+GeographicLib::Geodesic (see below) into C.  The underlying geodesic
+calculation API is exposed as part of the PROJ.4 library (via the geodesic.h
+header).  Prior to version 4.9.0, the algorithm documented here was used:
+`
+Paul D. Thomas, 1970
+Spheroidal Geodesics, Reference Systems, and Local Geometry"
+U.S. Naval Oceanographic Office, p. 162
+Engineering Library 526.3 T36s
+
+http://handle.dtic.mil/100.2/AD0703541
+
+GeographicLib::Geodesic
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Charles Karney has written a C++ class to do geodesic calculations and a
+utility GeodSolve to call it.  See
+
+* http://geographiclib.sourceforge.net/geod.html
+
+An online version of GeodSolve is available at
+
+* http://geographiclib.sourceforge.net/cgi-bin/GeodSolve
+
+This is an attempt to do geodesic calculations "right", i.e.,
+
+* accurate to round-off (i.e., about 15 nm);
+* inverse solution always succeeds (even for near anti-podal points);
+* reasonably fast (comparable in speed to Vincenty);
+* differential properties of geodesics are computed (these give the scales of
+  geodesic projections);
+* the area between a geodesic and the equator is computed (allowing the
+  area of geodesic polygons to be found);
+* included also is an implementation in terms of elliptic integrals which
+  can deal with ellipsoids with 0.01 < b/a < 100.
+
+A JavaScript implementation is included, see
+
+* `geo-calc <http://geographiclib.sourceforge.net/scripts/geod-calc.html>`__,
+   a text interface to geodesic calculations;
+* `geod-google <http://geographiclib.sourceforge.net/scripts/geod-google.html>`__,
+   a tool for drawing geodesics on Google Maps.
+
+Implementations in `Python <http://pypi.python.org/pypi/geographiclib>`__,
+`Matlab <http://www.mathworks.com/matlabcentral/fileexchange/39108>`__,
+`C <http://geographiclib.sourceforge.net/html/C/>`__,
+`Fortran <http://geographiclib.sourceforge.net/html/Fortran/>`__ , and
+`Java <http://geographiclib.sourceforge.net/html/java/>`__ are also available.
+
+The algorithms are described in
+ * C. F. F. Karney, `Algorithms for gedesics <http://dx.doi.org/10.1007/s00190-012-0578-z>`__,
+   J. Geodesy '''87'''(1), 43-55 (2013),
+   DOI: `10.1007/s00190-012-0578-z <http://dx.doi.org/10.1007/s00190-012-0578-z>`__; `geo-addenda.html <http://geographiclib.sf.net/geod-addenda.html>`__.
+
+Triaxial Ellipsoid
+................................................................................
+
+A triaxial ellipsoid is a marginally better approximation to the shape of the earth
+than an ellipsoid of revolution.
+The problem of geodesics on a triaxial ellipsoid was solved by Jacobi in 1838.
+For a discussion of this problem see
+* http://geographiclib.sourceforge.net/html/triaxial.html
+* the wikipedia entry: `Geodesics on a triaxial ellipsoid <https://en.wikipedia.org/wiki/Geodesics_on_an_ellipsoid#Geodesics_on_a_triaxial_ellipsoid>`__
+
+The History
+--------------------------------------------------------------------------------
+
+The bibliography of papers on the geodesic problem for an ellipsoid is
+available at
+
+* http://geographiclib.sourceforge.net/geodesic-papers/biblio.html
+
+this includes links to online copies of the papers.
diff --git a/docs/source/grids.rst b/docs/source/grids.rst
new file mode 100644
index 00000000..77d4c019
--- /dev/null
+++ b/docs/source/grids.rst
@@ -0,0 +1,167 @@
+.. _grids:
+
+================================================================================
+Grids
+================================================================================
+
+.. contents:: Contents
+   :depth: 3
+   :backlinks: none
+
+
+Grid files are important for shifting and transforming between datums
+
+US, Canadian, French and New Zealand
+--------------------------------------------------------------------------------
+
+* http://download.osgeo.org/proj/proj-datumgrid-1.5.zip: US, Canadian, French
+  and New Zealand datum shift grids - unzip in the `nad` directory before
+  configuring to add NAD27/NAD83 and NZGD49 datum conversion
+
+Switzerland
+--------------------------------------------------------------------------------
+
+Background in ticket [#145](https://github.com/OSGeo/proj.4/issues/145)
+
+We basically have two shift grids available. An official here:
+
+`Swiss CHENyx06 dataset in NTv2 format <http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/lv03-lv95/chenyx06/distortion_grids.html>`__
+
+And a derived in a temporary location which is probably going to disappear soon.
+
+Main problem seems to be there's no mention of distributivity of the grid from
+the official website.  It just tells: "you can use freely".  The "contact" link
+is also broken, but maybe someone could make a phone call to ask for rephrasing
+that.
+
+HARN
+--------------------------------------------------------------------------------
+
+With the support of `i-cubed <http://www.i-cubed.com>`__, Frank Warmerdam has
+written tools to translate the HPGN grids from NOAA/NGS from ``.los/.las`` format
+into NTv2 format for convenient use with PROJ.4.  This project included
+implementing a `.los/.las reader <https://github.com/OSGeo/gdal/tree/trunk/gdal/frmts/raw/loslasdataset.cpp>`__
+for GDAL, and an `NTv2 reader/writer <https://github.com/OSGeo/gdal/tree/trunk/gdal/frmts/raw/ntv2dataset.cpp>`__.
+Also, a script to do the bulk translation was implemented in
+https://github.com/OSGeo/gdal/tree/trunk/gdal/swig/python/samples/loslas2ntv2.py.
+The command to do the translation was:
+
+::
+
+    loslas2ntv2.py -auto *hpgn.los
+
+As GDAL uses NAD83/WGS84 as a pivot datum, the sense of the HPGN datum shift offsets were negated to map from HPGN to NAD83 instead of the other way.  The files can be used with PROJ.4 like this:
+
+::
+
+      cs2cs +proj=latlong +datum=NAD83
+            +to +proj=latlong +nadgrids=./azhpgn.gsb +ellps=GRS80
+
+::
+
+    # input:
+    -112 34
+
+::
+
+    # output:
+    111d59'59.996"W 34d0'0.006"N -0.000
+
+This was confirmed against the `NGS HPGN calculator
+<http://www.ngs.noaa.gov/cgi-bin/nadcon2.prl>`__.
+
+The grids are available at http://download.osgeo.org/proj/hpgn_ntv2.zip
+
+.. seealso::
+    :ref:`htpd` describes similar grid shifting
+
+HTDP
+--------------------------------------------------------------------------------
+
+:ref:`htpd` describes the situation with HTDP grids based on NOAA/NGS HTDP Model.
+
+
+Non-Free Grids
+--------------------------------------------------------------------------------
+
+Not all grid shift files have licensing that allows them to be freely
+distributed, but can be obtained by users through free and legal methods.
+
+Canada NTv2.0
+................................................................................
+Although NTv1 grid shifts are provided freely with PROJ.4, the higher-quality
+NTv2.0 file needs to be downloaded from Natural Resources Canada. More info:
+http://www.geod.nrcan.gc.ca/tools-outils/ntv2_e.php.
+
+Procedure:
+
+1. Visit the [NTv2](http://webapp.geod.nrcan.gc.ca/geod/tools-outils/applications.php?locale=en#ntv2), and register/login
+2. Follow the Download NTv2 link near the bottom of the page.
+3. Unzip `ntv2_100325.zip` (or similar), and move the grid shift file `NTV2_0.GSB` to the proj directory (be sure to change the name to lowercase for consistency)
+   * e.g.: `mv NTV2_0.GSB /usr/local/share/proj/ntv2_0.gsb`
+4. Test it using:
+    ::
+
+        cs2cs +proj=latlong +ellps=clrk66 +nadgrids=@ntv2_0.gsb +to +proj=latlong +ellps=GRS80 +datum=NAD83
+        -111 50
+
+    ::
+
+        111d0'3.006"W   50d0'0.103"N 0.000  # correct answer
+
+Australia
+................................................................................
+
+`Geocentric Datum of Australia AGD66/AGD84 <http://www.icsm.gov.au/gda/tech.html>`__
+
+Canada
+................................................................................
+
+`Canadian NTv2 grid shift binary <http://open.canada.ca/data/en/dataset/b3534942-31ea-59cf-bcc3-f8dc4875081a>`__ for NAD27 <=> NAD83.
+
+Germany
+................................................................................
+
+`German BeTA2007 DHDN GK3 => ETRS89/UTM <http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php>`__
+
+Great Britain
+................................................................................
+
+`Great Britain's OSTN02_NTv2: OSGB 1936 => ETRS89 <http://www.ordnancesurvey.co.uk/business-and-government/help-and-support/navigation-technology/os-net/ostn02-ntv2-format.html>`__
+
+Austria
+................................................................................
+
+`Austrian Grid <http://www.bev.gv.at/portal/page?_pageid=713,2204753&_dad=portal&_schema=PORTAL>`__ for MGI
+
+Spain
+................................................................................
+
+`Spanish grids <http://www.ign.es/ign/layoutIn/herramientas.do#DATUM>`__ for ED50.
+
+Portugal
+................................................................................
+
+`Portuguese grids <http://www.fc.up.pt/pessoas/jagoncal/coordenadas/index.htm>`__ for ED50, Lisbon 1890, Lisbon 1937 and Datum 73
+
+Brazil
+................................................................................
+
+`Brazilian grids <http://www.ibge.gov.br/home/geociencias/geodesia/param_transf/default_param_transf.shtm>`__ for datums Corrego Alegre 1961, Corrego Alegre 1970-72, SAD69 and SAD69(96)
+
+South Africa
+................................................................................
+
+`South African grid <http://eepublishers.co.za/article/datum-transformations-using-the-ntv2-grid.html>`__ (Cape to Hartebeesthoek94 or WGS84)
+
+Netherlands
+................................................................................
+
+`Dutch grid <https://www.kadaster.nl/web/Themas/Registraties/Rijksdriehoeksmeting/Transformatie-van-coordinaten.htm) (Registration required before download>`__
+
+Hungary
+................................................................................
+
+`Hungarian grid <https://github.com/OSGeoLabBp/eov2etrs/>`__ ETRS89 - HD72/EOV (epsg:23700), both horizontal and elevation grids
+
+
diff --git a/docs/source/htpd.rst b/docs/source/htpd.rst
new file mode 100644
index 00000000..2209c865
--- /dev/null
+++ b/docs/source/htpd.rst
@@ -0,0 +1,136 @@
+.. _htpd:
+
+================================================================================
+HTPD
+================================================================================
+
+.. contents:: Contents
+   :depth: 2
+   :backlinks: none
+
+This page documents use of the `crs2crs2grid.py` script and the HTDP
+(Horizontal Time Dependent Positioning) grid shift modelling program from
+NGS/NOAA to produce PROJ.4 compatible grid shift files for fine grade
+conversions between various NAD83 epochs and WGS84.  Traditionally PROJ.4 has
+treated NAD83 and WGS84 as equivalent and failed to distinguish between
+different epochs or realizations of those datums.  At the scales of much
+mapping this is adequate but as interest grows in high resolution imagery and
+other high resolution mapping this is inadequate.  Also, as the North American
+crust drifts over time the displacement between NAD83 and WGS84 grows (more
+than one foot over the last two decades).
+
+Getting and building HTDP
+--------------------------------------------------------------------------------
+
+The HTDP modelling program is in written FORTRAN.  The source and documentation
+can be found on the HTDP page at http://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml
+
+On linux systems it will be necessary to install `gfortran` or some FORTRAN
+compiler.  For ubuntu something like the following should work.
+
+::
+
+    apt-get install gfortran
+
+To compile the program do something like the following to produce the binary "htdp" from the source code.
+
+::
+
+    gfortran htdp.for -o htdp
+
+Getting crs2crs2grid.py
+--------------------------------------------------------------------------------
+
+The `crs2crs2grid.py` script can be found at
+https://github.com/OSGeo/gdal/tree/trunk/gdal/swig/python/samples/crs2crs2grid.py
+
+It depends on having the GDAL Python bindings operational.  If they are not
+available you will get an error something like the following:
+
+
+::
+
+    Traceback (most recent call last):
+      File "./crs2crs2grid.py", line 37, in <module>
+        from osgeo import gdal, gdal_array, osr
+    ImportError: No module named osgeo
+
+Usage
+--------------------------------------------------------------------------------
+
+::
+
+    crs2crs2grid.py
+            <src_crs_id> <src_crs_date> <dst_crs_id> <dst_crs_year>
+            [-griddef <ul_lon> <ul_lat> <ll_lon> <ll_lat> <lon_count> <lat_count>]
+            [-htdp <path_to_exe>] [-wrkdir <dirpath>] [-kwf]
+            -o <output_grid_name>
+
+ -griddef: by default the following values for roughly the continental USA
+           at a six minute step size are used:
+           -127 50 -66 25 251 611
+ -kwf: keep working files in the working directory for review.
+
+::
+
+    crs2crs2grid.py 29 2002.0 8 2002.0 -o nad83_2002.ct2
+
+The goal of `crs2crs2grid.py` is to produce a grid shift file for a designated
+region.  The region is defined using the `-griddef` switch.  When missing a
+continental US region is used.  The script creates a set of sample points for
+the grid definition, runs the "htdp" program against it and then parses the
+resulting points and computes a point by point shift to encode into the final
+grid shift file.  By default it is assumed the `htdp` program will be in the
+executable path.  If not, please provide the path to the executable using the
+`-htdp` switch.
+
+The `htdp` program supports transformations between many CRSes and for each (or
+most?) of them you need to provide a date at which the CRS is fixed.  The full
+set of CRS Ids available in the HTDP program are:
+
+::
+
+  1...NAD_83(2011) (North America tectonic plate fixed)
+  29...NAD_83(CORS96)  (NAD_83(2011) will be used)
+  30...NAD_83(2007)    (NAD_83(2011) will be used)
+  2...NAD_83(PA11) (Pacific tectonic plate fixed)
+  31...NAD_83(PACP00)  (NAD 83(PA11) will be used)
+  3...NAD_83(MA11) (Mariana tectonic plate fixed)
+  32...NAD_83(MARP00)  (NAD_83(MA11) will be used)
+
+  4...WGS_72                             16...ITRF92
+  5...WGS_84(transit) = NAD_83(2011)     17...ITRF93
+  6...WGS_84(G730) = ITRF92              18...ITRF94 = ITRF96
+  7...WGS_84(G873) = ITRF96              19...ITRF96
+  8...WGS_84(G1150) = ITRF2000           20...ITRF97
+  9...PNEOS_90 = ITRF90                  21...IGS97 = ITRF97
+ 10...NEOS_90 = ITRF90                   22...ITRF2000
+ 11...SIO/MIT_92 = ITRF91                23...IGS00 = ITRF2000
+ 12...ITRF88                             24...IGb00 = ITRF2000
+ 13...ITRF89                             25...ITRF2005
+ 14...ITRF90                             26...IGS05 = ITRF2005
+ 15...ITRF91                             27...ITRF2008
+                                         28...IGS08 = ITRF2008
+
+The typical use case is mapping from NAD83 on a particular date to WGS84 on
+some date.  In this case the source CRS Id "29" (NAD_83(CORS96)) and the
+destination CRS Id is "8 (WGS_84(G1150)).  It is also necessary to select the
+source and destination date (epoch).  For example:
+
+::
+
+    crs2crs2grid.py 29 2002.0 8 2002.0 -o nad83_2002.ct2
+
+The output is a CTable2 format grid shift file suitable for use with PROJ.4
+(4.8.0 or newer).  It might be utilized something like:
+
+
+::
+
+    cs2cs +proj=latlong +ellps=GRS80 +nadgrids=./nad83_2002.ct2 +to +proj=latlong +datum=WGS84
+
+See Also
+--------------------------------------------------------------------------------
+
+* http://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml - NGS/NOAA page about the HTDP
+  model and program.  Source for the HTDP program can be downloaded from here.
diff --git a/docs/source/index.rst b/docs/source/index.rst
new file mode 100644
index 00000000..86dda51f
--- /dev/null
+++ b/docs/source/index.rst
@@ -0,0 +1,47 @@
+.. _home:
+
+******************************************************************************
+proj.4
+******************************************************************************
+
+
+=============  ================================================================
+ Platform                Test Status and Coverage
+=============  ================================================================
+Travis         |travis|
+AppVeyor       |appveyor|
+Coverage       |coverals|
+=============  ================================================================
+
+.. |travis| image:: https://travis-ci.org/OSGeo/proj.4.svg?branch=master
+                    :target:  https://travis-ci.org/OSGeo/proj.4
+.. |appveyor| image:: https://ci.appveyor.com/api/projects/status/584j49uguwoo5evi?svg=true
+                    :target: https://ci.appveyor.com/project/OSGeo/proj-4
+.. |coverals| image:: https://coveralls.io/repos/OSGeo/proj.4/badge.svg?branch=master
+                    :target: https://coveralls.io/r/OSGeo/proj.4?branch=master
+
+Documentation
+=================
+
+.. toctree::
+   :maxdepth: 1
+
+   download
+   faq
+   geodesic
+   grids
+   license
+   htpd
+   threads
+   parameters
+
+
+
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`search`
+
diff --git a/docs/source/license.rst b/docs/source/license.rst
new file mode 100644
index 00000000..bd4f633c
--- /dev/null
+++ b/docs/source/license.rst
@@ -0,0 +1,46 @@
+.. _license:
+
+================================================================================
+License
+================================================================================
+
+:Author: Frank Warmerdam
+:Contact: warmerdam@pobox.com
+:Date: 2001
+
+PROJ.4 has been placed under an MIT license. I believe this to be as close as
+possible to public domain while satisfying those who say that a copyright
+notice is required in some countries. The COPYING file read as follows:
+
+All source, data files and other contents of the PROJ.4 package are available
+under the following terms. Note that the PROJ 4.3 and earlier was "public
+domain" as is common with US government work, but apparently this is not a well
+defined legal term in many countries. I am placing everything under the
+following MIT style license because I believe it is effectively the same as
+public domain, allowing anyone to use the code as they wish, including making
+proprietary derivatives.
+
+Though I have put my own name as copyright holder, I don't mean to imply I did
+the work. Essentially all work was done by Gerald Evenden.
+
+::
+
+     Copyright (c) 2000, Frank Warmerdam
+
+     Permission is hereby granted, free of charge, to any person obtaining a
+     copy of this software and associated documentation files (the "Software"),
+     to deal in the Software without restriction, including without limitation
+     the rights to use, copy, modify, merge, publish, distribute, sublicense,
+     and/or sell copies of the Software, and to permit persons to whom the
+     Software is furnished to do so, subject to the following conditions:
+
+     The above copyright notice and this permission notice shall be included
+     in all copies or substantial portions of the Software.
+
+     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+     OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+     FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+     THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+     LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+     DEALINGS IN THE SOFTWARE.
diff --git a/docs/source/parameters.rst b/docs/source/parameters.rst
new file mode 100644
index 00000000..3cf1b632
--- /dev/null
+++ b/docs/source/parameters.rst
@@ -0,0 +1,457 @@
+.. _parameters:
+
+================================================================================
+Parameters
+================================================================================
+
+:Author: Micah Cochran
+:Contact: http://github.com/micahcochran
+:Date: 01/28/2016
+
+.. contents:: Contents
+   :depth: 3
+   :backlinks: none
+
+
+This document attempts to describe a variety of the PROJ.4 parameters which can
+be applied to all, or many coordinate system definitions.  This document does
+not attempt to describe the parameters particular to particular projection
+types.  Some of these can be found in the GeoTIFF `Projections Transform List
+<http://www.remotesensing.org/geotiff/proj_list/>`__.  The definitive
+documentation for most parameters is Gerald's original documentation available
+from the main PROJ.4 page.
+
+Parameter list
+--------------------------------------------------------------------------------
+
+Common parameters:
+
+(this PROJ.4 distribution including `cs2cs` and datum support)
+
+::
+
+    +a         Semimajor radius of the ellipsoid axis
+    +alpha     ? Used with Oblique Mercator and possibly a few others
+    +axis      Axis orientation (new in 4.8.0)
+    +b         Semiminor radius of the ellipsoid axis
+    +datum     Datum name (see `proj -ld`)
+    +ellps     Ellipsoid name (see `proj -le`)
+    +k         Scaling factor (old name)
+    +k_0       Scaling factor (new name)
+    +lat_0     Latitude of origin
+    +lat_1     Latitude of first standard parallel
+    +lat_2     Latitude of second standard parallel
+    +lat_ts    Latitude of true scale
+    +lon_0     Central meridian
+    +lonc      ? Longitude used with Oblique Mercator and possibly a few others
+    +lon_wrap  Center longitude to use for wrapping (see below)
+    +nadgrids  Filename of NTv2 grid file to use for datum transforms (see below)
+    +no_defs   Don't use the /usr/share/proj/proj_def.dat defaults file
+    +over      Allow longitude output outside -180 to 180 range, disables wrapping (see below)
+    +pm        Alternate prime meridian (typically a city name, see below)
+    +proj      Projection name (see `proj -l`)
+    +south     Denotes southern hemisphere UTM zone
+    +to_meter  Multiplier to convert map units to 1.0m
+    +towgs84   3 or 7 term datum transform parameters (see below)
+    +units     meters, US survey feet, etc.
+    +vto_meter vertical conversion to meters.
+    +vunits    vertical units.
+    +x_0       False easting
+    +y_0       False northing
+    +zone      UTM zone
+
+Extended list provided by Gerald Evenden "grepped out of the RCS directory".
+
+(libproj4 by G.E.; no datum support)
+
+::
+
+    +a         Semimajor radius of the ellipsoid axis
+    +alpha     ? Used with Oblique Mercator and possibly a few others
+    +azi
+    +b         Semiminor radius of the ellipsoid axis
+    +belgium
+    +beta
+    +czech
+    +e         Eccentricity of the ellipsoid = sqrt(1 - b^2/a^2) = sqrt( f*(2-f) )
+    +ellps     Ellipsoid name (see `proj -le`)
+    +es        Eccentricity of the ellipsoid squared
+    +f         Flattening of the ellipsoid = 1-sqrt(1-e^2) (often presented as an inverse, e.g. 1/298)
+    +geoc
+    +guam
+    +h
+    +k         Scaling factor (old name)
+    +K
+    +k_0       Scaling factor (new name)
+    +lat_0     Latitude of origin
+    +lat_1     Latitude of first standard parallel
+    +lat_2     Latitude of second standard parallel
+    +lat_b
+    +lat_t
+    +lat_ts    Latitude of true scale
+    +lon_0     Central meridian
+    +lon_1
+    +lon_2
+    +lonc      ? Longitude used with Oblique Mercator and possibly a few others
+    +lsat
+    +m
+    +M
+    +n
+    +no_cut
+    +no_off
+    +no_rot
+    +ns
+    +o_alpha
+    +o_lat_1
+    +o_lat_2
+    +o_lat_c
+    +o_lat_p
+    +o_lon_1
+    +o_lon_2
+    +o_lon_c
+    +o_lon_p
+    +o_proj
+    +over
+    +p
+    +path
+    +proj      Projection name (see `proj -l`)
+    +q
+    +R
+    +R_a
+    +R_A       Compute radius such that the area of the sphere is the same as the area of the ellipsoid
+    +rf        Reciprocal of the ellipsoid flattening term (e.g. 298)
+    +R_g
+    +R_h
+    +R_lat_a
+    +R_lat_g
+    +rot
+    +R_V
+    +s
+    +south     Denotes southern hemisphere UTM zone
+    +sym
+    +t
+    +theta
+    +tilt
+    +to_meter  Multiplier to convert map units to 1.0m
+    +units     meters, US survey feet, etc.
+    +vopt
+    +W
+    +westo
+    +x_0       False easting
+    +y_0       False northing
+    +zone      UTM zone
+
+See GE's `libproj4
+manual <http://members.verizon.net/~gerald.evenden/proj4/manual.pdf>`__ for
+further details (`copy in wayback machine <http://web.archive.org/web/20080807155507/http://members.verizon.net/~gerald.evenden/proj4/manual.pdf>`__).
+
+Further details for projection at http://www.remotesensing.org/geotiff/proj_list/
+
+Units
+--------------------------------------------------------------------------------
+
+Horizontal units can be specified using the +units= keyword with a symbolic
+name for a unit (ie. us-ft).  Alternatively the translation to meters can be
+specified with the +to_meter keyword (ie. 0.304800609601219 for US feet).  The
+``-lu`` argument to cs2cs or proj can be used to list symbolic unit names.  The
+default unit is degrees.
+
+Vertical Units
+--------------------------------------------------------------------------------
+
+Vertical (Z) units can be specified using the ``+vunits=`` keyword with a
+symbolic name for a unit (ie. ``us-ft``).  Alternatively the translation to
+meters can be specified with the ``+vto_meter`` keyword (ie. 0.304800609601219
+for US feet).  The ``-lu`` argument to cs2cs or proj can be used to list symbolic
+unit names.  If no vertical units are specified, the vertical units will
+default to be the same as the horizontal coordinates.
+
+Note that vertical unit transformations are only supported in pj_transform()
+and programs built on that such as cs2cs.  The low level projections functions
+pj_fwd() and pj_inv() and programs using them directly such as proj do not
+handle vertical units at all.
+
+False Easting/Northing
+--------------------------------------------------------------------------------
+
+Virtually all coordinate systems allow for the presence of a false easting
+(``+x_0``) and northing (``+y_0``).  Note that these values are always expressed in
+meters even if the coordinate system is some other units.  Some coordinate
+systems (such as UTM) have implicit false easting and northing values.
+
+lon_wrap, over - Longitude Wrapping
+--------------------------------------------------------------------------------
+
+By default PROJ.4 wraps output longitudes in the range -180 to 180.  The +over
+switch can be used to disable the default wrapping which is done at a low level
+- in ``pj_inv()``.  This is particularly useful with projections like eqc where
+it would desirable for X values past -20000000 (roughly) to continue past
+-180 instead of wrapping to +180.
+
+The ``+lon_wrap`` option can be used to provide an alternative means of doing
+longitude wrapping within ``pj_transform()``.  The argument to this option is a
+center longitude.  So ``+lon_wrap=180`` means wrap longitudes in the range 0 to
+360.  Note that ``+over`` does **not** disable ``+lon_wrap``.
+
+pm - Prime Meridian
+--------------------------------------------------------------------------------
+
+A prime meridian may be declared indicating the offset between the prime
+meridian of the declared coordinate system and that of greenwich.  A prime
+meridian is clared using the "pm" parameter, and may be assigned a symbolic
+name, or the longitude of the alternative prime meridian relative to greenwich.
+
+Currently prime meridian declarations are only utilized by the
+``pj_transform()`` API call, not the ``pj_inv()`` and ``pj_fwd()`` calls.
+Consequently the user utility ``cs2cs`` does honour prime meridians but the
+proj user utility ignores them.
+
+The following predeclared prime meridian names are supported.  These can be
+listed using the cs2cs argument -lm.
+
+::
+
+   greenwich 0dE
+      lisbon 9d07'54.862"W
+       paris 2d20'14.025"E
+      bogota 74d04'51.3"E
+      madrid 3d41'16.48"W
+        rome 12d27'8.4"E
+        bern 7d26'22.5"E
+     jakarta 106d48'27.79"E
+       ferro 17d40'W
+    brussels 4d22'4.71"E
+   stockholm 18d3'29.8"E
+      athens 23d42'58.815"E
+        oslo 10d43'22.5"E
+
+Example of use.  The location ``long=0``, ``lat=0`` in the greenwich based lat/long
+coordinates is translated to lat/long coordinates with Madrid as the prime
+meridian.
+
+::
+
+    cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
+    0 0                           <i>(input)</i>
+    3d41'16.48"E    0dN 0.000     <i>(output)</i>
+
+towgs84 - Datum transformation to WGS84
+--------------------------------------------------------------------------------
+
+Datum shifts can be approximated by 3 parameter spatial translations (in
+geocentric space), or 7 parameter shifts (translation + rotation + scaling).
+The parameters to describe this can be described using the towgs84 parameter.
+
+In the three parameter case, the three arguments are the translations to the
+geocentric location in meters.
+
+For instance, the following demonstrates converting from the Greek GGRS87 datum
+to WGS84.
+
+::
+
+    cs2cs +proj=latlong +ellps=GRS80 +towgs84=-199.87,74.79,246.62
+        +to +proj=latlong +datum=WGS84
+    20 35
+    20d0'5.467"E    35d0'9.575"N 8.570
+
+The EPSG database provides this example for transforming from WGS72 to WGS84
+using an approximated 7 parameter transformation.
+
+::
+
+    cs2cs +proj=latlong +ellps=WGS72 +towgs84=0,0,4.5,0,0,0.554,0.219 \
+        +to +proj=latlong +datum=WGS84
+    4 55
+    4d0'0.554"E     55d0'0.09"N 3.223
+
+The seven parameter case uses ``delta_x``, ``delta_y``, ``delta_z``, ``Rx -
+rotation X``, ``Ry - rotation Y``, ``Rz - rotation Z``, ``M_BF - Scaling``.
+The three translation parameters are in meters as in the three parameter case.
+The rotational parameters are in seconds of arc.  The scaling is apparently the
+scale change in parts per million.
+
+A more complete discussion of the 3 and 7 parameter transformations can be
+found in the EPSG database (trf_method's 9603 and 9606).  Within PROJ.4 the
+following calculations are used to apply the ``towgs84`` transformation (going
+to WGS84).  The x, y and z coordinates are in geocentric coordinates.
+
+Three parameter transformation (simple offsets):
+
+::
+
+  x[io] = x[io] + defn->datum_params[0];
+  y[io] = y[io] + defn->datum_params[1];
+  z[io] = z[io] + defn->datum_params[2];
+
+Seven parameter transformation (translation, rotation and scaling):
+
+::
+
+    #define Dx_BF (defn->datum_params[0])
+    #define Dy_BF (defn->datum_params[1])
+    #define Dz_BF (defn->datum_params[2])
+    #define Rx_BF (defn->datum_params[3])
+    #define Ry_BF (defn->datum_params[4])
+    #define Rz_BF (defn->datum_params[5])
+    #define M_BF  (defn->datum_params[6])
+
+    x_out = M_BF*(       x[io] - Rz_BF*y[io] + Ry_BF*z[io]) + Dx_BF;
+    y_out = M_BF*( Rz_BF*x[io] +       y[io] - Rx_BF*z[io]) + Dy_BF;
+    z_out = M_BF*(-Ry_BF*x[io] + Rx_BF*y[io] +       z[io]) + Dz_BF;
+
+Note that EPSG method 9607 (coordinate frame rotation) coefficients can be
+converted to EPSG method 9606 (position vector 7-parameter) supported by PROJ.4
+by reversing the sign of the rotation vectors.  The methods are otherwise the
+same.
+
+nadgrids - Grid Based Datum Adjustments
+--------------------------------------------------------------------------------
+
+In many places (notably North America and Austrialia) national geodetic
+organizations provide grid shift files for converting between different datums,
+such as NAD27 to NAD83.  These grid shift files include a shift to be applied
+at each grid location. Actually grid shifts are normally computed based on an
+interpolation between the containing four grid points.
+
+PROJ.4 currently supports use of grid shift files for shifting between datums
+and WGS84 under some circumstances.  The grid shift table formats are ctable
+(the binary format produced by the PROJ.4 ``nad2bin`` program), NTv1 (the old
+Canadian format), and NTv2 (``.gsb`` - the new Canadian and Australian format).
+
+Use of grid shifts is specified using the ``nadgrids`` keyword in a coordinate
+system definition.  For example:
+
+
+::
+
+    % cs2cs +proj=latlong +ellps=clrk66 +nadgrids=ntv1_can.dat \
+        +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
+    -111 50
+    EOF
+    111d0'2.952"W   50d0'0.111"N 0.000
+
+In this case the ``/usr/local/share/proj/ntv1_can.dat`` grid shift file was
+loaded, and used to get a grid shift value for the selected point.
+
+It is possible to list multiple grid shift files, in which case each will be
+tried in turn till one is found that contains the point being transformed.
+
+::
+
+    cs2cs +proj=latlong +ellps=clrk66 \
+              +nadgrids=conus,alaska,hawaii,stgeorge,stlrnc,stpaul \
+        +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
+    -111 44
+    EOF
+    111d0'2.788"W   43d59'59.725"N 0.000
+
+Skipping Missing Grids
+................................................................................
+
+The special prefix ``@`` may be prefixed to a grid to make it optional.  If it
+not found, the search will continue to the next grid.  Normally any grid not
+found will cause an error.  For instance, the following would use the
+``ntv2_0.gsb`` file if available (see [[NonFreeGrids]]), otherwise it would
+fallback to using the ``ntv1_can.dat`` file.
+
+::
+
+    cs2cs +proj=latlong +ellps=clrk66 +nadgrids=@ntv2_0.gsb,ntv1_can.dat \
+        +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
+    -111 50
+    EOF
+    111d0'3.006"W   50d0'0.103"N 0.000
+
+The null Grid
+................................................................................
+
+A special ``null`` grid shift file is shift with releases after 4.4.6 (not
+inclusive).  This file provides a zero shift for the whole world.  It may be
+listed at the end of a nadgrids file list if you want a zero shift to be
+applied to points outside the valid region of all the other grids.  Normally if
+no grid is found that contains the point to be transformed an error will occur.
+
+::
+
+    cs2cs +proj=latlong +ellps=clrk66 +nadgrids=conus,null \
+        +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
+    -111 45
+    EOF
+    111d0'3.006"W   50d0'0.103"N 0.000
+
+    cs2cs +proj=latlong +ellps=clrk66 +nadgrids=conus,null \
+        +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
+    -111 44
+    -111 55
+    EOF
+    111d0'2.788"W   43d59'59.725"N 0.000
+    111dW   55dN 0.000
+
+Downloading and Installing Grids
+................................................................................
+
+The source distribution of PROJ.4 contains only the ntv1_can.dat file.  To get
+the set of US grid shift files it is necessary to download an additional
+distribution of files from the PROJ.4 site, such as
+ftp://ftp.remotesensing.org/pub/proj/proj-nad27-1.1.tar.gz.  Overlay it on the
+PROJ.4 source distribution, and re-configure, compile and install.  The
+distributed ASCII .lla files are converted into binary (platform specific)
+files that are installed.  On windows using the nmake /f makefile.vc nadshift
+command in the proj\src directory to build and install these files.
+
+It appears we can't redistribute the Canadian NTv2 grid shift file freely,
+though it is better than the NTv1 file.  However, end users can download it for
+free from the `NRCan web site
+<http://www.geod.nrcan.gc.ca/tools-outils/ntv2_e.php>`__.  After downloading
+it, just dump it in the data directory with the other installed data files
+(usually `/usr/local/share/proj`). See [[NonFreeGrids]] for details.
+
+Caveats
+................................................................................
+
+* Where grids overlap (such as conus and ntv1_can.dat for instance) the first
+  found for a point will be used regardless of whether it is appropriate or
+  not.  So, for instance, ```+nadgrids=ntv1_can.dat```,conus would result in
+  the Canadian data being used for some areas in the northern United States
+  even though the conus data is the approved data to use for the area.
+  Careful selection of files and file order is necessary.  In some cases
+  border spanning datasets may need to be pre-segmented into Canadian and
+  American points so they can be properly grid shifted
+* There are additional grids for shifting between NAD83 and various HPGN
+  versions of the NAD83 datum.  Use of these haven't been tried recently so
+  you may encounter problems.  The FL.lla, WO.lla, MD.lla, TN.lla and WI.lla
+  are examples of high precision grid shifts.  Take care!
+* Additional detail on the grid shift being applied can be found by setting
+  the PROJ_DEBUG environment variable to a value.  This will result in output
+  to stderr on what grid is used to shift points, the bounds of the various
+  grids loaded and so forth
+* PROJ.4 always assumes that grids contain a shift **to**  NAD83 (essentially
+  WGS84).  Other types of grids might or might not be usable
+
+Axis orientation
+--------------------------------------------------------------------------------
+
+Starting in PROJ 4.8.0, the +axis argument can be used to control the axis
+orientation of the coordinate system.  The default orientation is "easting,
+northing, up" but directions can be flipped, or axes flipped using combinations
+of the axes in the +axis switch.  The values are:
+
+* "e" - Easting
+* "w" - Westing
+* "n" - Northing
+* "s" - Southing
+* "u" - Up
+* "d" - Down
+
+They can be combined in +axis in forms like:
+
+* ``+axis=enu`` - the default easting, northing, elevation.
+* ``+axis=neu`` - northing, easting, up - useful for "lat/long" geographic
+  coordinates, or south orientated transverse mercator.
+* ``+axis=wnu`` - westing, northing, up - some planetary coordinate systems
+  have "west positive" coordinate systems
+
+Note that the ``+axis`` argument only applies to coordinate transformations done
+through ``pj_transform()`` (so it works with ``cs2cs``, but not with the proj
+commandline program).
diff --git a/docs/source/threads.rst b/docs/source/threads.rst
new file mode 100644
index 00000000..736d15b5
--- /dev/null
+++ b/docs/source/threads.rst
@@ -0,0 +1,79 @@
+.. _threads:
+
+================================================================================
+Threads
+================================================================================
+
+This page is about efforts to make PROJ.4 thread safe.
+
+Key Thread Safety Issues
+--------------------------------------------------------------------------------
+
+* the global pj_errno variable is shared between threads and makes it
+  essentially impossible to handle errors safely.  Being addressed with the
+  introduction of the projCtx execution context.
+* the datum shift using grid files uses globally shared lists of loaded grid
+  information. Access to this has been made safe in 4.7.0 with the introduction
+  of a proj.4 mutex used to protect access to these memory structures (see
+  pj_mutex.c).
+
+projCtx
+--------------------------------------------------------------------------------
+
+Primarily in order to avoid having pj_errno as a global variable, a "thread
+context" structure has been introduced into a variation of the PROJ.4 API for
+the 4.8.0 release.  The pj_init() and pj_init_plus() functions now have context
+variations called pj_init_ctx() and pj_init_plus_ctx() which take a projections
+context.
+
+The projections context can be created with pj_ctx_alloc(), and there is a
+global default context used when one is not provided by the application.  There
+is a pj_ctx_ set of functions to create, manipulate, query, and destroy
+contexts.  The contexts are also used now to handle setting debugging mode, and
+to hold an error reporting function for textual error and debug messages.   The
+API looks like:
+
+::
+
+    projPJ pj_init_ctx( projCtx, int, char ** );
+    projPJ pj_init_plus_ctx( projCtx, const char * );
+
+    projCtx pj_get_default_ctx(void);
+    projCtx pj_get_ctx( projPJ );
+    void pj_set_ctx( projPJ, projCtx );
+    projCtx pj_ctx_alloc(void);
+    void    pj_ctx_free( projCtx );
+    int pj_ctx_get_errno( projCtx );
+    void pj_ctx_set_errno( projCtx, int );
+    void pj_ctx_set_debug( projCtx, int );
+    void pj_ctx_set_logger( projCtx, void (*)(void *, int, const char *) );
+    void pj_ctx_set_app_data( projCtx, void * );
+    void *pj_ctx_get_app_data( projCtx );
+
+Multithreaded applications are now expected to create a projCtx per thread
+using pj_ctx_alloc().  The context's error handlers, and app data may be
+modified if desired, but at the very least each context has an internal error
+value accessed with pj_ctx_get_errno() as opposed to looking at pj_errno.
+
+Note that pj_errno continues to exist, and it is set by pj_ctx_set_errno() (as
+well as setting the context specific error number), but pj_errno still suffers
+from the global shared problem between threads and should not be used by
+multithreaded applications.
+
+Note that pj_init_ctx(), and pj_init_plus_ctx() will assign the projCtx to the
+created projPJ object.  Functions like pj_transform(), pj_fwd() and pj_inv()
+will use the context of the projPJ for error reporting.
+
+src/multistresstest.c
+--------------------------------------------------------------------------------
+
+A small multi-threaded test program has been written (src/multistresstest.c)
+for testing multithreaded use of PROJ.4.  It performs a series of reprojections
+to setup a table expected results, and then it does them many times in several
+threads to confirm that the results are consistent.  At this time this program
+is not part of the builds but it can be built on linux like:
+
+::
+
+    gcc -g multistresstest.c .libs/libproj.so -lpthread -o multistresstest
+    ./multistresstest