[Proj] Dataset mismatch?

Jarrett L. Redd jarrett_l_redd at yahoo.com
Mon Jan 30 00:23:05 EST 2006


Ed,

Indeed, the datum conversion was never the problem.  Instead, it was a faulty
assumption on my part.  I assumed that the skew between the dataset projections
was negligable on such a small area when it fact it is quite significant.  By
skew, I mean that if you project a square from one dataset into the other
dataset, you will not get exactly a square.  Therefore, if you just perform a
normal bi-nodal interpolation, you will get a significant error.  But if you
account for a 2D skew with a quad-nodal interpolation, then the error goes
away.  This is why the error vanished when I started translating every point
directly.  FYI, if you interpolate from just the 4 corners of the quad versus
hundreds of internal points, you get a max position difference of around 2.5
feet, just as you predicted.  This is obviously way below the DRG 24k
resolution and can be ignored.  Another interesting thing is that the 1/3 arc
second elevation data plots around 1.5m low on the topo maps.  That is, the
plotted contour lines are always just below the topo contour lines.  Since I
only care about slopes, lifting everything 1.5m makes them line up very nicely.

Thanks again to everyone for their help.  I think this tool is going to save
some lives once it gets out into the field.  At that time, I will be releasing
the source so that it can continue to be modified as avalanche prediction
models improve.

-Jarrett

--- Ed McNierney <ed at topozone.com> wrote:

> Jarrett -
> 
> Why do you think it is the problem?  Are you indeed operating at a scale
> where you're using two corner points per 7.5-minute quad?  And can you
> give examples (with specific coordinates) of where you see substantial
> datum shifts on multiple points on a single quad?  I'm skeptical...
> 
> Is it possible that the error is in the way you calculate the
> interpolated values?
> 
> 	- 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 
> 
> -----Original Message-----
> From: proj-bounces at lists.maptools.org
> [mailto:proj-bounces at lists.maptools.org] On Behalf Of Jarrett L. Redd
> Sent: Friday, January 27, 2006 2:03 PM
> To: PROJ.4 and general Projections Discussions
> Cc: proj-bounces at lists.maptools.org; gdal-dev at lists.maptools.org
> Subject: RE: [Proj] Dataset mismatch?
> 
> Sorry... saw these messages after my previous response.  Believe it or
> not, this seems to be the problem.  I had my suspicions that it was a
> non-linear problem associated with the datum conversion, and when I did
> the conversion, the error goes away (mostly).  I didn't bother at first
> because I also believed it was too small an area to show such an error.
> I guess not!  By the way, it may not be possible to answer this
> question, but I thought I'd try anyway: 
> anyone know what maximum error mismatch to expect due to the datasets
> themselves?  I'm seeing 50 feet in various areas, and occasionally up to
> 150 feet (in narrow canyons, etc).  Perhaps I still have a problem
> somewhere.
> 
> Thanks.
> 
> -Jarrett
> 
> --- Ed McNierney <ed at topozone.com> wrote:
> 
> > 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
> 
> _______________________________________________
> 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
> 



More information about the Proj mailing list