[Gdal-dev] RE: [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 Gdal-dev
mailing list