ENVI Navigating GeoTiff Image Incorrectly? [message #78134] |
Wed, 26 October 2011 14:08  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Folks,
Has anyone ever compared ENVI's map projection routines
with IDL's? (I am speaking about Map_Proj_Init, not
Map_Set.)
I have spent the past couple of days working with
a GeoTiff image and my active contouring software.
I am trying to produce output that matches the output
from ENVI. I know, for example, that ENVI counts from
1 and not 0, and that the origin is in the upper left
corner (where it is suppose to be!) and not in the
lower left corner as in IDL.
But, even so, I have not been able to reconcile my
results with ENVIs. And now I have come to the
conclusion that ENVI is just plain wrong. :-)
Here is what I have done. I have a GeoTiff image
(which I can provide, if anyone is interested). And,
Lord knows, I *know* how to navigate a GeoTiff image!
You get the tie points, which locate the upper-left
corner of the upper left pixel. This locates the upper
and left boundary of the image. Then you read the
X and Y pixel scales out of the Tiff file. I my
case, these are both 2.0 meters (a pixel is 2 meters
square). If you multiply the size of the image by
the pixel scales, you will obtain a value that marks
the lower and right boundaries of the image.
Consider a 10x10 image that used 1 meter scales.
If the upper-left corner of the upper-left pixel
was located at (0,0), then the lower-right corner
of the lower-right pixel would be located like this:
s = Size(image, /Dimensions)
x1 = x0 + s[0]*xscale
y1 = y0 + s[1]*yscale
IF x0 and y0 were equal to 0, and xscale and yscale were
equal to 1, then the (x1,y1) point would be (10,10).
You would say the boundaries of this image were 0 and 10
in both X and Y directions.
This is *exactly* what I do for the GeoTiff image. In my
image the tie point (x0,y0) is located at (519279,7443030),
and I calculate the (x1,y1) location for this 800x800 image
as (520879,7441430). Note that if you subtract these values,
you get 1600 in both X and Y dimensions, as you would expect.
ENVI, uses the very same (x0,y0) point, but calculates the
(x1,y1) point as (520877,7441432). In other words, ENVI is
one pixel short in X and one pixel long in Y!! (To get the
ENVI values, I used the Pixel Locator and entered 800 in both
the Sample and Line positions.)
But, my interest was really in locating an ROI in the
image. To investigate this, I made a sample feature
by creating a 25 pixel on a side square near the center of
the image. And then I calculated the projected XY locations
of the four corner pixels of this sample feature.
If you assume that the pixel index number identifies the
center of each pixel, then you could investigate the size
of the feature by subtracting the projected XY locations.
When I did this is my code, I found the sample feature to
be 48 meters on a side, exactly as I expected. (Centers,
remember, not edges.)
When I calculated the same values in ENVI I found the feature
to be 48 meters in X, but only 44 meters in Y!!!
I don't have ANY idea how to explain this descrepancy,
except to say I *know* my values are correct and I know
the values I am getting from ENVI are wrong. I conclude
that ENVI is navigating this GeoTiff image incorrectly
which is causing me a great deal of distress when I try
to match these ENVI values! :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
Re: ENVI Navigating GeoTiff Image Incorrectly? [message #78185 is a reply to message #78134] |
Sun, 30 October 2011 10:31  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
David Fanning writes:
> I feel 99.9% confident that ENVI is doing this calculation
> incorrectly. This may be a moot point, however, since
> ENVI has moved on to ESRI map projection code, and my
> client is thinking of upgrading from ENVI 4.5.
Whew! Glad I didn't say 100%!
Because now I am convinced it is IDL that is at fault
and that the IDL UTM map projection produces incorrect
results. (In all versions of IDL, as far as I know,
including IDL 8.1) :-(
Here is a copy of a note I sent to IDL technical support:
http://www.idlcoyote.com/map_tips/map_utm_bug.txt
I'll let you know if I hear something from them.
The bottom line is that the UTM projection *only* allows
a spherical datum to be used. I thought at first this
was because the UTM projection is set up incorrectly in
some of the map projection files distributed in IDL,
but after correcting these files, I obtain identical
(incorrect) results. So, I now believe the problem
is that the GCTP software itself only supports a
sphere as the datum in this projection. This is a
problem because most satellite data is gridded using
a WGS84 datum. Without a datum transformation, the
results can be several hundreds of meters off. Not
a problem, usually, on a global scale, but extremely
significant on a local scale, where these UTM projections
are often used.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
Re: ENVI Navigating GeoTiff Image Incorrectly? [message #78197 is a reply to message #78134] |
Fri, 28 October 2011 07:40  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Guillermo writes:
> See if your ModelTiePointTag[0:1]=[0,0]. If not, you were wrongly
> assuming that the geotiff coordinates referred to the upper left
> corner of the tie point pixel. This might not be necessarily be the
> case.
This is useful information, although I don't believe I have
ever encountered a TIFF file in which the tie point didn't
represent the upper-left corner of the tie point pixel.
But I'll be looking more closely from now on!
In any case, the file in question was using this convention,
so there is no mistake there. Aside from the obvious errors
ENVI is making in just the basic TIFF manipulations, the
pixels in the sample feature I was talking about, were located
anywhere from 2 to 200 meters away from where I calculate
they are suppose to be. (200 meters is 1/8 the length of the
entire feature, and the actual different from one pixel to
another is variable, not a simple offset. If it *were* a
simple offset, my confidence in my own code wouldn't be
nearly as strong. I would suspect ENVI was doing something
I didn't understand yet.)
I feel 99.9% confident that ENVI is doing this calculation
incorrectly. This may be a moot point, however, since
ENVI has moved on to ESRI map projection code, and my
client is thinking of upgrading from ENVI 4.5.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|