<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=515581415-04052006><FONT face=Tahoma 
color=#0000ff>I don't know about the internal workings of ArcView, but if you 
use Corpscon, this is correct.&nbsp; Corpscon will first convert from NAD27 to 
NAD83, then from NAD83 to NAD83 HARN.&nbsp; If you are using NAD27 State Plane 
Coordinates (SPCs), this is further complicated by the fact that there was a 
major shift in the NAD27 SPCs to NAD83 SPCs, then if you go to Lat-Long, there 
is another conversion, and so on and so on .&nbsp;. .</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=515581415-04052006><FONT face=Tahoma 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=515581415-04052006><FONT face=Tahoma 
color=#0000ff>I have found out (through trial and error - mostly error) that if 
software is not set up to Quad Precision*, mathematical errors get into the 
picture as well.&nbsp; Right now, I am playing around with projecting Lat-Long 
to FDEP Albers using a FORTRAN program I wrote.&nbsp; The results using Double 
Precision vs. Triple Precision* are in the centimeter range.&nbsp; My compiler 
doesn't have&nbsp;Quad Precision, but I wish it did.</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><B><SPAN lang=en-us><FONT face="Brush Script MT" size=6>-- 
John</FONT></SPAN></B><SPAN lang=en-us></SPAN> </P>
<DIV><FONT face=Tahoma color=#0000ff><SPAN class=515581415-04052006>* Triple 
Precision is actually 80 bit, or about 18 significant digits,&nbsp;utilizing the 
built-in math coprocessor in the Intel chips.</SPAN></FONT></DIV><STRONG><FONT 
face="Brush Script MT" size=6></FONT></STRONG><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> shrug-l-bounces@lists.dep.state.fl.us 
[mailto:shrug-l-bounces@lists.dep.state.fl.us] <B>On Behalf Of </B>Thomas, 
Jim<BR><B>Sent:</B> Thursday, May 04, 2006 11:14 AM<BR><B>To:</B> 
shrug-l@lists.dep.state.fl.us<BR><B>Subject:</B> shrug-l: NAD 83 to NAD83 
HARN<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=397370415-04052006>Shruggers,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=397370415-04052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=397370415-04052006>Is this 
true?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=397370415-04052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=397370415-04052006>"<FONT 
face="Times New Roman" size=3>To project data from State Plane NAD 27 West to 
NAD 83 HARN takes two (2) transformations."</FONT></SPAN></FONT></DIV>
<DIV><FONT face="Times New Roman" size=3><SPAN 
class=397370415-04052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=397370415-04052006>I'm dealing with 
data referenced as FLSP-W NAD83 HARN and it's not overlaying my NAD27 
data.&nbsp; Could it be that ArcMap is incorrectly projecting on the fly?&nbsp; 
If I change the reference system from NAD83 HARN to NAD83, it overlays 
properly.&nbsp; Am I missing something?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=397370415-04052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=397370415-04052006>Jim 
T.</SPAN></FONT></DIV></BODY></HTML>