Added note on virtual earth, and null shifts to WGS84.

git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1395 4e78687f-474d-0410-85f9-8d5e500ac6b2

1 files changed, 53 insertions, 7 deletions

diff --git a/html/faq.html b/html/faq.html
index 19d64601..38f6fa3d 100644
--- a/html/faq.html
+++ b/html/faq.html
@@ -7,7 +7,7 @@
 
 <!-------------------------------------------------------------------------->
 
-<h2>Where can I find the list of projections and their arguments?</h2>
+<h2><a name="proj_docs">Where can I find the list of projections and their arguments?</a></h2>
 
 There is no simple single location to find all the required information. The
 PostScript/PDF documents listed on the <a href="index.html">main</a> PROJ.4
@@ -27,7 +27,7 @@ a definition of the projection specific options for each.<p>
 
 <!-------------------------------------------------------------------------->
 
-<h2>How do I do datum shifts between NAD27 and NAD83?</h2>
+<h2><a name="nad2783">How do I do datum shifts between NAD27 and NAD83?</a></h2>
 
 While the <b>nad2nad</b> program can be used in some cases, the <b>cs2cs</b>
 is now the preferred mechanism.   The following example demonstrates using
@@ -52,7 +52,7 @@ must be available.  See below.  More details are available in the
 
 <!-------------------------------------------------------------------------->
 
-<h2>How do I build/configure PROJ.4 to support datum shifting.</h2>
+<h2><a name="datumshifting">How do I build/configure PROJ.4 to support datum shifting.</a></h2>
 
 After downloading and unpacking the PROJ.4 source, also download and unpack
 the set of datum shift files.  This would be a file like
@@ -76,7 +76,7 @@ environment can be defined with the correct directory.<p>
 
 <!-------------------------------------------------------------------------->
 
-<h2>How do I debug problems with NAD27/NAD83 datum shifting?</h2>
+<h2><a name="nad2783_debug">How do I debug problems with NAD27/NAD83 datum shifting?</a></h2>
 
 <ol>
 <li> Verify that you have the binary files (eg. /usr/local/share/proj/conus)
@@ -113,7 +113,7 @@ include expanding the definition of +datum clause. <p>
 
 <!-------------------------------------------------------------------------->
 
-<h2>How do I use EPSG coordinate system codes with PROJ.4?</h2>
+<h2><a name="epsg">How do I use EPSG coordinate system codes with PROJ.4?</a></h2>
 
 There is somewhat imperfect translation between 2d geographic and
 projected coordinate system codes and PROJ.4 descriptions of the
@@ -144,7 +144,7 @@ meridian or other quirkyness are unlikely to work properly.  Caveat Emptor!<p>
 
 <!-------------------------------------------------------------------------->
 
-<h2>How do I use 3 parameter and 7 parameter datum shifting</h2>
+<h2><a name="datum_37">How do I use 3 parameter and 7 parameter datum shifting</a></h2>
 
 Datum shifts can be approximated with 3 and 7 parameter transformations.  
 Their use is more fully described in the 
@@ -153,7 +153,7 @@ Their use is more fully described in the
 
 <!-------------------------------------------------------------------------->
 
-<h2>Does PROJ.4 work in different international numeric locales?</h2>
+<h2><a name="locale">Does PROJ.4 work in different international numeric locales?</a></h2>
 
 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 
@@ -172,6 +172,52 @@ $ proj ...
 
 <!-------------------------------------------------------------------------->
 
+<h2><a name="sphere_as_wgs84">Changing Ellipsoid / Why can't I convert from WGS84 to Virtual Earth Mercator?</a></h2>
+
+The coordinate system definition for Virtual Earth Mercator is as follows, 
+which uses a sphere as the earth model for the mercator projection. 
+
+<pre>
++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
+</pre>
+
+But, if you do something like:
+
+<pre>
+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
+</pre>
+
+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.<p>
+
+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 <i>null</i> grid shift file 
+for switching from your spherical lat/long coordinates to WGS84.<p>
+
+<pre>
+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
+</pre>
+
+Note the strategic addition of <tt>+nadgrids=@null</tt> to the spherical
+projection definition.<p>
+
+Similar issues apply with many other datasets distributed with projections
+based on a spherical earth model - such as many NASA datasets, and also
+(I think) the Google Maps mercator projection.<p>
+
+<!-------------------------------------------------------------------------->
+
 <hr>
 
 Requests to add items to the frequently asked questions list