| MODIS L1B - 250m [message #37524] |
Tue, 06 January 2004 08:31 |
david.hildebrand
Messages: 1
Registered: January 2004
|
Junior Member |
|
|
I am responding to a thread by posting a new message because I have no
newsgroup client except Google and and it is difficult to post a
follow-up thread. I have an interest in this topic because I also
have been working on a swath-to-grid utility. The content of the
thread you posted is given below. Please note the in-line comments.
> Maybe I'm just being defensive, because it implies that there was an
> error in my geolocation code, but I don't think "correction" is the
> right term. The radiances you see are, to the accuracy of the L1B
> calibration, the correct radiances. The specified locations are, to
> about 50m accuracy, the correct ground locations from which those
> radiances were collected. The bow-tie effect is a real characteristic of
> the way the data was collected, not an error that needs correction. I
> apologize if I sound a bit defensive about this.
The bow-tie effect may not be an error but does it not require
adjustment in > order to bring the imagery into a mappable framework?
> Liam Gumley has written some code for correctly displaying MODIS image
> data, try <ftp://origin.ssec.wisc.edu/pub/MODIS/IDL/>.
> The best way to handle the butterfly effect in MODIS image data is to
> treat each scan of data (which corresponds to 40 consecutive scan lines,
> at 250m resolution) as a seperate image, 10 km wide at the center, 20km
> wide at the outer edges, and a few thousand kilometers long. Each such
> image will overlap the preceeding and following image. Create each image
> seperately, and then decide how you want to handle the overlaps.
> Averaging in the overlap region is best, but it's quicker to just let
> later scans overwrite parts of the image that were filled in by the
> earlier scans.
Would I be correct to assume that averaging eliminates banding (or
striping) in the output?
> Note: the satellite's altitude above the ground varies slightly. It
> sometime flies low enough that there are actually gaps between scans
> near the center of the scans. It sometimes flies high enough that as
> many as three different scans of data overlap the same ground position,
> near the outer edges of the scans.
>
> That's just in normal operations; when the spacecraft is flying with a
> yaw near 90 degrees, as many as a hundred scans of data can overlap at
> the same point; I was called in once to help resolve a problem caused by
> this. It turned out that they were trying to process MODIS geolocation
> data during a maneuver, and they were using an algorithm that kept track
> of the overlaps in fixed sized arrays that allowed for a maximum of 10
> overlaps. They weren't really interested in processing the maneuver
> data, they just hadn't bothered to check.
>
> Please note that you must NOT interpolate the geolocation data across
> scan boundaries. Just last week I got a complaint from someone about the
> accuracy of our geolocation code; it turned out that he had made
> precisely that mistake. The resulting pictures had bizarre ripples of
> distortion running across them, at the boundaries between successive
> scans. You can interpolate within a scan, but since the geolocation data
> is at 1km resolution, you'll have to extrapolate it at the edges of each
> scan when displaying 250m data.
The algorithm I have developed is simple and works well where multiple
bands need to be extracted from a Level1B image. It processes the
image in memory without temporary disk space requirements. However, I
have the same ripple effect you mention. Perhaps you have some sage
word of advice for me. The algorithm works as follows. Geolocations
are transformed to a planar projection and expanded to the resolution
required. An index grid is created of the size and dimensions
required in the output (i.e.; one cell per pixel). For each cell in
the grid the nearest geolocated pixel is found and assigned to that
particular cell (this is actually performed during the expansion
process). Since each expanded geolocation corresponds to an input
pixel the nearest neighbour can be stored as an index into the image
array which applies to all bands in a particular SDS. The output
mechanism simply scans the index grid and extracts the required image
pixel which is nearest to the centre of the particular grid cell being
output. I suppose my question to you would be: apart from a total
re-design, would you be able to suggest a way that I can modify this
algorithm to get rid of the distortion and also adjust for the bow-tie
effect?
I hope my explanation has been sufficient. Any suggestions would be
appreciated. If you respond to this thread please also email me
directly (david.hildebrand@gov.ab.ca).
-----------------------------------------------
David V. Hildebrand
Conservation and Development Branch
Alberta Agriculture, Food and Rural Development
(780) 427-3558
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
