[Proj] Dataset mismatch?

Fri Jan 27 14:13:05 EST 2006

Ed,

Thank you for the reply. I haven't rolled up my sleeves on this problem 
but I follow you points clearly. Off the top of my head then, if a 
transformation of this sort is only a meter or two, and a pixel is 2.4m, 
then Jarrett's discrepancy of a couple hundred meters, smells like a 
blunder somewhere to me. (Or, perhaps, he is at the max accuracy he can 
expect considering the two sources he is using and their pedigrees (the 
accuracies (errors) in their sources and methods of collection).

Mike

"Ed McNierney" <ed at topozone.com> 
Sent by: proj-bounces at lists.maptools.org
01/27/2006 12:29 PM
Please respond to
"PROJ.4 and general Projections Discussions"    <proj at lists.maptools.org>

To
"PROJ.4 and general Projections Discussions" <proj at lists.maptools.org>
cc
proj-bounces at lists.maptools.org, gdal-dev at lists.maptools.org
Subject
RE: [Proj] Dataset mismatch?

Mike -

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.

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.

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.

     - Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
ed at topozone.com
(978) 251-4242 

From: proj-bounces at lists.maptools.org 
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Michael P Finn
Sent: Friday, January 27, 2006 12:52 PM
To: PROJ.4 and general Projections Discussions
Cc: geotiff at lists.maptools.org; proj at lists.maptools.org; 
gdal-dev at lists.maptools.org; proj-bounces at lists.maptools.org
Subject: Re: [Proj] Dataset mismatch?

>From my colleague Lynn Usery (USGS/ Geospatial Information Office).   Mike 
Finn 

Using 2 points is not sufficient. The user should use a grid of at least 
20 x 20 points (400 total points) over the quad. Transform those between 
the datums and resample the pixels based on this approach. This is a 
simple operation in Imagine which automatically locates the control 
points then applies the datum tranformation, interpolates and resamples 
the data. Of course Jarrett said no commercial software, so he must find 
a way to implement this process with open source code.

To perform the datum transformation, two points is just not enough to 
handle the differences between the two datums. NGS used thousands of 
points in the transformation to determine the NADCON shifts between NAD 
27 and NAD 83 for the US.

Lynn 

"Jarrett L. Redd" <jarrett_l_redd at yahoo.com> 
Sent by: proj-bounces at lists.maptools.org 
01/27/2006 02:59 AM 

Please respond to
"PROJ.4 and general Projections Discussions" <proj at lists.maptools.org>

To
gdal-dev at lists.maptools.org, proj at lists.maptools.org, 
geotiff at lists.maptools.org 
cc

Subject
[Proj] Dataset mismatch?

Howdy...

Please forgive the long cross-posting.  I'm new to this and don't know 
exactly
who will have a possible answer for this issue of mine.

I'm a volunteer working on a avalanche terrain and runout mapping project 
for
potential use by our mountain search and rescue teams.  I'm using DRG 24k
topographical geotiff slices in UTM NAD27 and then processing 1/3 arc-sec
elevation .adf files in lat/lon NAD83 to match up and plot slopes and 
such. 
All this is downloaded from the NED seamless website.

Problem is, the two data sets don't match up precisely.  That is, the 
features
on the topo seem to match up precisely with elevation data in some places 
and
not so precisely in others.  At the worst, the error is around 500 feet. 
I'm
using "libproj" to convert coordinates between the two datums.  I'm 
currently
processing a section of Colorado, and I'm building "libproj" to include 
the
"conus" correction file.  I've also verified my coordinate conversions are
correct by comparing against openEV and topoUSA.  I'm also using "libgdal" 
to
pull out the elevation data and "libgeotiff" to grab the image raster data 
and
geo tags.

However, like I said, I'm new to this.  I'm converting the NW and SE 
corners of
the geotiff into NAD83 and then interpolating for each pixel to match up 
with
the elevation data using the origin and resolution of the various 
elevation
pieces.  I have a sneaky feeling that life isn't that simple.  Am I 
missing
some fancy projection to correct for curvature of the earth or something? 
Or
is this just an inherent mismatch between the data sets?  Or both?  Other
suggestions to try?

Please don't suggest using a commercially available mapping package since 
we
have no money and I need to do very extensive data processing once I have 
the
data sets matching up properly.

Thanks.

-Jarrett

P.S.  Here's an example of a nearly 500 foot mismatch error:

A tiny rock spire on the topo map:
13 0394704 4334970

And the corresponding spike in elevation data:
13 0394571 4335039

[Coords provided by OpenEV cursor]

I don't expect a perfect matchup, but the worst areas need to be corrected
somehow to make the avalanche terrain maps useful.

I can email an example image showing the error if someone is really 
interested.

Thanks again.

_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20060127/b7afd641/attachment.html