Remove html folder

author: Kristian Evers <kristianevers@gmail.com> 2018-03-06 09:23:33 +0100
committer: Kristian Evers <kristianevers@gmail.com> 2018-03-06 09:23:33 +0100
commit: ec2b67d5df927f58af7445e589b347bf03698a30 (patch)
tree: 2429815ffd6bcac59fd1e054cf0dd067e96a6d62 /html/gen_parms.html
parent: ffc0a463f07b60f8cc17a3630f740584fa18c95f (diff)
download: PROJ-ec2b67d5df927f58af7445e589b347bf03698a30.tar.gz
PROJ-ec2b67d5df927f58af7445e589b347bf03698a30.zip
1 files changed, 0 insertions, 276 deletions
diff --git a/html/gen_parms.html b/html/gen_parms.html
deleted file mode 100644
index 8cd8e161..00000000
--- a/html/gen_parms.html
+++ /dev/null
@@ -1,276 +0,0 @@
-<html>
-<head>
-<title>PROJ.4 - General Parameters</title>
-</head>
-<body BGCOLOR="#FFFFFF">
-<h1>PROJ.4 - General Parameters</h1>
-
-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 
-<a href="http://www.remotesensing.org/geotiff/proj_list/">Projections 
-Transform List</a>.  The definitive documentation for most parameters
-is Gerald's original documentation available from the main PROJ.4 page. <p>
-
-<hr>
-<h2><a name="false_easting_northing">False Easting/Northing</a></h2>
-
-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.<p>
-
-<hr>
-<h2><a name="pm">pm - Prime Meridian</a></h2>
-
-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. <p>
-
-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 <b>cs2cs</b> does honour prime meridians but the <b>proj</b>
-user utility ignores them. <p>
-
-The following predeclared prime meridian names are supported.  These
-can be listed using the cs2cs argument <b>-lm</b>.<p>
-<pre>
-   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                  
-</pre>
-
-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. <p>
-
-<pre>
- 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>
-</pre>
-
-<hr>
-<h2><a name="towgs84">towgs84 - Datum transformation to WGS84</a></h2>
-
-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 <b>towgs84</b> 
-parameter.<p>
-
-In the three parameter case, the three arguments are the translations to the
-geocentric location in meters.<p>
-
-For instance, the following demonstrates converting from the Greek GGRS87
-datum to WGS84.<p>
-
-<pre>
-% 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
-</pre>
-
-The EPSG database provides this example for transforming from WGS72 to WGS84
-using an approximated 7 parameter transformation.<p>
-<pre>
-% 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
-</pre>
-
-The seven parameter case uses <i>delta_x</i>, <i>delta_y</i>, <i>delta_z</i>,
-<i>Rx - rotation X</i>, <i>Ry - rotation Y</i>, <i>Rz - rotation Z</i>, 
-<i>M_BF - Scaling</i>.  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.<p>
-
-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 <b>towgs84</b> transformation
-(going to WGS84).  The x, y and z coordinates are in geocentric coordinates.
-
-Three parameter transformation (simple offsets):
-
-<pre>
-  x[io] = x[io] + defn->datum_params[0];
-  y[io] = y[io] + defn->datum_params[1];
-  z[io] = z[io] + defn->datum_params[2];
-</pre>
-
-Seven parameter transformation (translation, rotation and scaling):
-
-<pre>
-  #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;
-</pre>
-
-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.<p>
-
-<hr>
-<h2><a name="nadgrids">nadgrids - Grid Based Datum Adjustments</a></h2>
-
-In many places (notably North America and Australia) 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.<p>
-
-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).<p>
-
-Use of grid shifts is specified using the "nadgrids" keyword in a coordinate
-system definition.  For example:<p>
-
-<pre>
-% 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
-</pre>
-
-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. <p>
-
-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.<p>
-
-<pre>
-% 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
-</pre>
-
-<h3>Skipping Missing Grids</h3>
-
-The special prefix <b>@</b> 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, otherwise it would fallback to using
-the ntv1_can.dat file. <p>
-
-<pre>
-% 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
-</pre>
-
-<h3>The null Grid</h3>
-
-A special <b>null</b> 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.<p>
-
-<pre>
-% 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
-</pre>
-
-<pre>
-% 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
-</pre>
-
-<h3>Downloading and Installing Grids</h3>
-
-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
-<a href="ftp://ftp.remotesensing.org/pub/proj/proj-nad27-1.1.tar.gz">
-proj-nad27-1.1.tar.gz</a>.  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 <tt>nmake /f makefile.vc nadshift</tt> command in
-the <tt>proj\src</tt> directory to build and install these files. <p>
-
-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 at
-<a href="http://www.geod.nrcan.gc.ca/software/ntv2_e.php">
-http://www.geod.nrcan.gc.ca/software/ntv2_e.php</a>.  After
-downloading it, just dump it in the data directory with the other 
-installed data files (usually /usr/local/share/proj). <p>
-
-<h3>Caveats</h3>
-
-<ol>
-
-<li> 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.<p>
-
-<li> 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!<p>
-
-<li> 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.<p>
-
-<li> PROJ.4 always assumes that grids contain a shift <b>to</b> NAD83 
-(essentially WGS84).  Other types of grids might or might not be usable.<p>
-
-</ol>
-
-</body>
-</html>
-
-
-
-
-
-
-
author	Kristian Evers <kristianevers@gmail.com>	2018-03-06 09:23:33 +0100
committer	Kristian Evers <kristianevers@gmail.com>	2018-03-06 09:23:33 +0100
commit	ec2b67d5df927f58af7445e589b347bf03698a30 (patch)
tree	2429815ffd6bcac59fd1e054cf0dd067e96a6d62 /html/gen_parms.html
parent	ffc0a463f07b60f8cc17a3630f740584fa18c95f (diff)
download	PROJ-ec2b67d5df927f58af7445e589b347bf03698a30.tar.gz PROJ-ec2b67d5df927f58af7445e589b347bf03698a30.zip