[Gdal-dev] RE: [Proj] Dataset mismatch?

Ed McNierney ed at topozone.com
Fri Jan 27 14:24:09 EST 2006


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




More information about the Gdal-dev mailing list