<!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> </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! For CONUS that's around 50,000 quads
worth. We're only talking about one quad that's only about 10 x 15
kilometers. 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> </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. The northwest corner of that quad is at
392131E 4345059N (NAD27) and 392084E 4345267N (NAD83). The NAD27 ->
NAD83 datum shift at that point is (-47E, +208N). If I go to the southeast
corner of that quad, the coordinates are 402746E 4331044N (NAD27) and 402699E
4331252N (NAD93). The NAD27 -> NAD83 datum shift at that opposite
corner is (-47E, +208N) - identical to the datum shift at the opposite
corner! 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. 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> </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.
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> </DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial
color=#0000ff size=2> - Ed</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </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 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> </DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=382400918-27012006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </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). 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"
<jarrett_l_redd@yahoo.com></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"
<proj@lists.maptools.org></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. 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.
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.
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. At the
worst, the error is around 500 feet. I'm<BR>using "libproj" to convert
coordinates between the two datums. I'm currently<BR>processing a section
of Colorado, and I'm building "libproj" to include the<BR>"conus" correction
file. I've also verified my coordinate conversions are<BR>correct by
comparing against openEV and topoUSA. 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. 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. I have a sneaky feeling that life isn't
that simple. Am I missing<BR>some fancy projection to correct for
curvature of the earth or something? Or<BR>is this just an inherent
mismatch between the data sets? Or both? 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. 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>