<!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.2802" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2>Mike -</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2>Yes, the USGS used thousands of points, but they needed to 
cover the whole country!&nbsp; For CONUS that's around 50,000&nbsp;quads 
worth.&nbsp; We're only talking about one quad that's only about 10 x 15 
kilometers.&nbsp; If the NGS used 400 points per quad they would have needed 
over 20 million points.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2>I took a look at the Mount Sherman, CO quad that is the 
subject of the original post.&nbsp; The northwest corner of that quad is at 
392131E 4345059N (NAD27) and 392084E 4345267N (NAD83).&nbsp; The NAD27 -&gt; 
NAD83 datum shift at that point is (-47E, +208N).&nbsp; If I go to the southeast 
corner of that quad, the coordinates are 402746E 4331044N (NAD27) and 402699E 
4331252N (NAD93).&nbsp; The NAD27 -&gt; NAD83 datum shift at that opposite 
corner is (-47E, +208N) - identical to the datum shift at the opposite 
corner!&nbsp; I cannot imagine one would require 400 intermediate control points 
to accurately calculate a datum shift across an area the size of a 7.5-minute 
quad - especially when the shift at opposite corners is the same.&nbsp; You 
might, I suppose, manage to get off by a meter or two, but since a single pixel 
on a 1:24K DRG is 2.4384 meters on a side, you're literally below the threshold 
of precision on the data.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2>Jarrett's seeing discrepancies of hundreds of meters.&nbsp; 
Even if you measured only one point and presumed the datum shift was identical 
across the entire quad, you couldn't produce an error that 
large.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2>&nbsp;&nbsp;&nbsp;&nbsp; - Ed</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006>
<P><FONT size=2>Ed McNierney<BR>President and Chief Mapmaker<BR>TopoZone.com / 
Maps a la carte, Inc.<BR>73 Princeton Street, Suite 305<BR>North Chelmsford, 
MA&nbsp; 01863<BR>ed@topozone.com<BR>(978) 251-4242 </FONT></P></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> proj-bounces@lists.maptools.org 
[mailto:proj-bounces@lists.maptools.org] <B>On Behalf Of </B>Michael P 
Finn<BR><B>Sent:</B> Friday, January 27, 2006 12:52 PM<BR><B>To:</B> PROJ.4 and 
general Projections Discussions<BR><B>Cc:</B> geotiff@lists.maptools.org; 
proj@lists.maptools.org; gdal-dev@lists.maptools.org; 
proj-bounces@lists.maptools.org<BR><B>Subject:</B> Re: [Proj] Dataset 
mismatch?<BR></FONT><BR></DIV>
<DIV></DIV><BR><FONT size=2><TT>From my colleague Lynn Usery (USGS/ Geospatial 
Information Office). &nbsp; Mike Finn</TT></FONT> <BR><BR><BR><BR><BR><FONT 
size=2><TT>Using 2 points is not sufficient. The user should use a grid of at 
least <BR>20 x 20 points (400 total points) over the quad. Transform those 
between <BR>the datums and resample the pixels based on this approach. This is a 
<BR>simple operation in Imagine which automatically locates the control 
<BR>points then applies the datum tranformation, interpolates and resamples 
<BR>the data. Of course Jarrett said no commercial software, so he must find 
<BR>a way to implement this process with open source code.<BR><BR>To perform the 
datum transformation, two points is just not enough to <BR>handle the 
differences between the two datums. NGS used thousands of <BR>points in the 
transformation to determine the NADCON shifts between NAD <BR>27 and NAD 83 for 
the US.<BR><BR>Lynn</TT></FONT> <BR><BR><BR><BR><BR>
<TABLE width="100%">
  <TBODY>
  <TR vAlign=top>
    <TD width="40%"><FONT face=sans-serif size=1><B>"Jarrett L. Redd" 
      &lt;jarrett_l_redd@yahoo.com&gt;</B> </FONT><BR><FONT face=sans-serif 
      size=1>Sent by: proj-bounces@lists.maptools.org</FONT> 
      <P><FONT face=sans-serif size=1>01/27/2006 02:59 AM</FONT> 
      <TABLE border=1>
        <TBODY>
        <TR vAlign=top>
          <TD bgColor=white>
            <DIV align=center><FONT face=sans-serif size=1>Please respond 
            to<BR>"PROJ.4 and general Projections Discussions" &nbsp; &nbsp; 
            &nbsp; 
      &nbsp;&lt;proj@lists.maptools.org&gt;</FONT></DIV></TR></TBODY></TABLE><BR></P>
    <TD width="59%">
      <TABLE width="100%">
        <TBODY>
        <TR vAlign=top>
          <TD>
            <DIV align=right><FONT face=sans-serif size=1>To</FONT></DIV>
          <TD><FONT face=sans-serif size=1>gdal-dev@lists.maptools.org, 
            proj@lists.maptools.org, geotiff@lists.maptools.org</FONT> 
        <TR vAlign=top>
          <TD>
            <DIV align=right><FONT face=sans-serif size=1>cc</FONT></DIV>
          <TD>
        <TR vAlign=top>
          <TD>
            <DIV align=right><FONT face=sans-serif size=1>Subject</FONT></DIV>
          <TD><FONT face=sans-serif size=1>[Proj] Dataset 
        mismatch?</FONT></TR></TBODY></TABLE><BR>
      <TABLE>
        <TBODY>
        <TR vAlign=top>
          <TD>
          <TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><FONT 
size=2><TT>Howdy...<BR><BR>Please forgive the long cross-posting. &nbsp;I'm new 
to this and don't know exactly<BR>who will have a possible answer for this issue 
of mine.<BR><BR>I'm a volunteer working on a avalanche terrain and runout 
mapping project for<BR>potential use by our mountain search and rescue teams. 
&nbsp;I'm using DRG 24k<BR>topographical geotiff slices in UTM NAD27 and then 
processing 1/3 arc-sec<BR>elevation .adf files in lat/lon NAD83 to match up and 
plot slopes and such. <BR>All this is downloaded from the NED seamless 
website.<BR><BR>Problem is, the two data sets don't match up precisely. 
&nbsp;That is, the features<BR>on the topo seem to match up precisely with 
elevation data in some places and<BR>not so precisely in others. &nbsp;At the 
worst, the error is around 500 feet. &nbsp;I'm<BR>using "libproj" to convert 
coordinates between the two datums. &nbsp;I'm currently<BR>processing a section 
of Colorado, and I'm building "libproj" to include the<BR>"conus" correction 
file. &nbsp;I've also verified my coordinate conversions are<BR>correct by 
comparing against openEV and topoUSA. &nbsp;I'm also using "libgdal" to<BR>pull 
out the elevation data and "libgeotiff" to grab the image raster data and<BR>geo 
tags.<BR><BR>However, like I said, I'm new to this. &nbsp;I'm converting the NW 
and SE corners of<BR>the geotiff into NAD83 and then interpolating for each 
pixel to match up with<BR>the elevation data using the origin and resolution of 
the various elevation<BR>pieces. &nbsp;I have a sneaky feeling that life isn't 
that simple. &nbsp;Am I missing<BR>some fancy projection to correct for 
curvature of the earth or something? &nbsp;Or<BR>is this just an inherent 
mismatch between the data sets? &nbsp;Or both? &nbsp;Other<BR>suggestions to 
try?<BR><BR>Please don't suggest using a commercially available mapping package 
since we<BR>have no money and I need to do very extensive data processing once I 
have the<BR>data sets matching up 
properly.<BR><BR>Thanks.<BR><BR>-Jarrett<BR><BR>P.S. &nbsp;Here's an example of 
a nearly 500 foot mismatch error:<BR><BR>A tiny rock spire on the topo 
map:<BR>13 0394704 4334970<BR><BR>And the corresponding spike in elevation 
data:<BR>13 0394571 4335039<BR><BR>[Coords provided by OpenEV cursor]<BR><BR>I 
don't expect a perfect matchup, but the worst areas need to be 
corrected<BR>somehow to make the avalanche terrain maps useful.<BR><BR>I can 
email an example image showing the error if someone is really 
interested.<BR><BR>Thanks 
again.<BR><BR>_______________________________________________<BR>Proj mailing 
list<BR>Proj@lists.maptools.org<BR>http://lists.maptools.org/mailman/listinfo/proj<BR></TT></FONT><BR></BODY></HTML>