| AVHRR Image Mapping Problem [message #51852] |
Fri, 15 December 2006 07:42  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Folks,
Does anyone have any experience working with AVHRR NDVI
image data or Albers map projection? I have obtained
the data, which is of the African continent from here:
ftp://ftp.glcf.umiacs.umd.edu/glcf/GIMMS/Regional/Albers/Afr ica
The image is in an Albers Conical equal area projection
and the centers of the four corner pixels are known from
the documentation:
; YX coordinates of the four corners (LL, UL, UR, LR)
longitude = [-23.49, -24.6, 64.523, 63.414]
latitude = [-42.243, 43.711, 43.712, -42.242]
This is a GeoTiff file, so I also pull the Standard
Parallels out of the geotiff information stored in
the file (they are -19 and 21).
I follow the method outlined on this page (which has
worked perfectly for a polar stereo map projection),
using instead of a Stereo projection, an Albers
projection with standard parallels:
http://www.dfanning.com/map_tips/precipmap.html
The method *ALMOST* works! :-)
But the continental outlines do not QUITE line up properly.
You can see my result here:
http://www.dfanning.com/misc/africa.jpg
Do you think this might be an Albers projection problem?
A difference between MAP_PROJ_INIT and MAP_SET? (I have
tried different DATUMS with no change in effect.)
Or, do you think this might just be right? :-(
Cheers,
David
P.S. Don't worry about the colors. They are still screwed up.
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51974 is a reply to message #51852] |
Sun, 17 December 2006 20:11  |
Richard French
Messages: 173
Registered: December 2000
|
Senior Member |
|
|
Thanks for the post - as I mentioned in the part of my post not quoted
below:
"you need to find out from experience (or
preferably from the spacecraft/instrument teams) what the actual pointing
performance is likely to be."
Your post answered that question. It sounds as though pointing error is not
the culprit in David's example.
Dick
On 12/17/06 11:05 PM, in article
1166414746.299151.321950@79g2000cws.googlegroups.com, "kuyper@wizard.net"
<kuyper@wizard.net> wrote:
> Richard G. French wrote:
> ...
>
>> If one trusted the data headers from Hubble Space Telescope images as a
>> guide to where the spacecraft was actually pointed, one would be up to 10
>> pixels off - that's because what's listed in the header is where they
>> expected to be pointing, not a reconstructed view of where they were
>> actually pointing. The same is true of Cassini images of Saturn. I don't
>> know about Earth-pointing satellites, but unless one has done some pretty
>> accurate post-image checking, it is not obvious to me that the header
>> information for such an image would have anything other than the predicted
>> location of the image,
>
> I only know about one instrument (MODIS) on two Earth-pointing
> satellites (Terra and Aqua), but I'm personally responsible for the
> geolocation on the MODIS data from those satellites. The file
> attributes summarizing the location of a granule are just as accurate
> as the geolocation which is provided in the MOD03 files for every 1km
> pixel: the RMS error is nominally 50 meters, though we're actually
> doing a bit better than that, with our smallest pixel size being 250
> meters. Except during a maneuver, the actual orientation of the
> satellite is used, not the planned orientation.
>
> The software I'm responsible for was modified from software for earlier
> instruments, and has been borrowed as the basis for sofware for the
> VIIRS instrument on NPP, so I suspect this is not uncommon for
> earth-pointing satellite imagery.
>
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51975 is a reply to message #51852] |
Sun, 17 December 2006 20:05 |
James Kuyper
Messages: 425
Registered: March 2000
|
Senior Member |
|
|
Richard G. French wrote:
...
> If one trusted the data headers from Hubble Space Telescope images as a
> guide to where the spacecraft was actually pointed, one would be up to 10
> pixels off - that's because what's listed in the header is where they
> expected to be pointing, not a reconstructed view of where they were
> actually pointing. The same is true of Cassini images of Saturn. I don't
> know about Earth-pointing satellites, but unless one has done some pretty
> accurate post-image checking, it is not obvious to me that the header
> information for such an image would have anything other than the predicted
> location of the image,
I only know about one instrument (MODIS) on two Earth-pointing
satellites (Terra and Aqua), but I'm personally responsible for the
geolocation on the MODIS data from those satellites. The file
attributes summarizing the location of a granule are just as accurate
as the geolocation which is provided in the MOD03 files for every 1km
pixel: the RMS error is nominally 50 meters, though we're actually
doing a bit better than that, with our smallest pixel size being 250
meters. Except during a maneuver, the actual orientation of the
satellite is used, not the planned orientation.
The software I'm responsible for was modified from software for earlier
instruments, and has been borrowed as the basis for sofware for the
VIIRS instrument on NPP, so I suspect this is not uncommon for
earth-pointing satellite imagery.
|
|
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51977 is a reply to message #51852] |
Sun, 17 December 2006 12:36 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Chris Torrence writes:
> Anyway, hope this helps. You're right about the image registration. iMap
> looks good, but not perfect. I'll have to think about it some more. It looks
> like a couple of pixels, not just something like half a pixel, which would
> be easy to explain...
Chris, thanks for this. It helps.
I wouldn't be too hard on iMap. I believe now the problem
isn't an IDL problem at all. I think the center of
the pixels is just NOT what the documentation says they
are. (It, uh, wouldn't be the first time that satellite
data documentation was wrong, in my admittedly limited
experience. In fact, I've seldom found it to be RIGHT!)
In any case, experience leads me toward a documentation
error in the satellite docs rather than toward an
implementation error in IDL.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51978 is a reply to message #51852] |
Sun, 17 December 2006 12:11 |
Chris[2]
Messages: 39
Registered: August 2003
|
Member |
|
|
Hi David,
Good point about iMap. Currently, the problem is that the GeoTIFF tags
cannot be passed in as a keyword. It has to come from the file. I'll try to
address this in the next IDL version. In the meantime, you *can* pass in the
GeoTIFF as a data parameter, like this:
-----
file = 'AF03sep15b.n16-VIg.tif' ;dialog_pickfile()
image = Read_Tiff(file, GEOTIFF=geoTiff, ORIENTATION=orien)
if (orien eq 1) then image = Reverse(image,2)
LOADCT, 39, /SILENT
TVLCT, r, g, b, /GET
rgb = Transpose([[r],[g],[b]])
rgb[*,0] = 255 ; make background white
image >= 0 ; clip all negative values
; Ugly part which should go away in the next IDL version...
oParmSet = OBJ_NEW('IDLitParameterSet')
oParmSet->Add, OBJ_NEW('IDLitDataIDLImagePixels', image), $
PARAMETER_NAME='IMAGEPIXELS'
oParmSet->Add, OBJ_NEW('IDLitDataIDLPalette', rgb), $
PARAMETER_NAME='PALETTE'
oParmSet->Add, OBJ_NEW('IDLitDataIDLGeoTIFF', geotiff), $
PARAMETER_NAME='GEOTIFF'
iMap, INITIAL_DATA=oParmSet
; Change the map limits. Also should go away in next IDL version...
it = itgetcurrent(TOOL=oTool)
oDS = (oTool->GetSelectedItems())[0]->GetDataspace(/UNNORM)
oMap = oDS->_GetMapProjection()
oMap->SetProperty, LIMIT=[-45,-30,45,70]
oDS->OnProjectionChange
; Insert continents.
void = oTool->DoAction('Operations/Insert/Map/Continents')
oCont = (oTool->GetSelectedItems())[0]
oCont->SetProperty, FILL_BACKGROUND=0, COLOR=[255,0,0]
; Export to a bitmap file. This part is optional...
oDesc = oTool->GetByIdentifier('Operations/File/Export')
oExport = oDesc->GetObjectInstance()
; File suffix will automatically determine the file type.
oExport->SetProperty, FILENAME='outAfrica.png', $
SOURCE=1, $ ; do the entire window
SHOW_EXECUTION_UI=0, SCALE_FACTOR=2
void = oExport->DoAction(oTool)
oExport->SetProperty, SHOW_EXECUTION_UI=1
-----
You can see how you can mess around with both the image data and the palette
before passing them into the Parameter Set. In the next IDL version, this
should be much simpler, something like:
...read data...
...mess with image and palette...
iMap, image, GEOTIFF=geoTiff, RGB_TABLE=rgb, LIMIT=[-45,-30,45,70]
...insert continents...
Anyway, hope this helps. You're right about the image registration. iMap
looks good, but not perfect. I'll have to think about it some more. It looks
like a couple of pixels, not just something like half a pixel, which would
be easy to explain...
Cheers,
Chris
ITTVIS
"David Fanning" <news@dfanning.com> wrote in message
news:MPG.1fedbaf54e8d8289989e52@news.frii.com...
> Chris Torrence writes:
>
>> 1. Start iMap.
>> 2. File->Open, open one of your Africa images
>> 3. Double click on the image to bring up property sheet, edit the color
>> table to your liking
>> 4. Insert->Map continents
>> 5. Click on the Map tab on the right, change plot range to lon [-30,
>> +70],
>> lat [-45, +45]
>> 6. (bonus) Window->Data Manager, open your image data, click on GeoTIFF
>> tags
>> node, then click on the GeoTIFF tags property to view the tags.
>>
>> Everything looks fine to me:
>
> Yes, I agree, it looks a hell of a lot better
> than my attempt with iMap yesterday! But I'm not
> so sure it's any better than where I started. The
> color table you have chosen here masks the problem
> a little bit. If you inverse it, you see the problem
> more clearly.
>
> This iMap solution did give me a clue to set the
> CENTER_LAT keyword to 1, if I use the original
> standard parallels of -19 and 21. I like this
> better than changing them to -19,9999 and 20.0005
> the way I did yesterday.
>
> This gives me more or less what iMap is giving me,
> but--again--just not quite right. I find I still have
> to tweak the positions of the corner pixels just slightly
> to get everything aligned to my satisfaction.
>
> But, a couple of questions about iMap. I don't want
> to display the original data. I want to display a
> processed image with a particular set of colors
> (I think there are 15). So a processed, byte-scaled
> image with a particular color table. How would I get
> to this point after reading the GeoTiff file into
> iMap? Or, would I have to do this in a different way?
> I think this is what confused me about iMap yesterday.
>
> Cheers,
>
> David
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51979 is a reply to message #51852] |
Sat, 16 December 2006 07:13 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Chris Torrence writes:
> 1. Start iMap.
> 2. File->Open, open one of your Africa images
> 3. Double click on the image to bring up property sheet, edit the color
> table to your liking
> 4. Insert->Map continents
> 5. Click on the Map tab on the right, change plot range to lon [-30, +70],
> lat [-45, +45]
> 6. (bonus) Window->Data Manager, open your image data, click on GeoTIFF tags
> node, then click on the GeoTIFF tags property to view the tags.
>
> Everything looks fine to me:
Yes, I agree, it looks a hell of a lot better
than my attempt with iMap yesterday! But I'm not
so sure it's any better than where I started. The
color table you have chosen here masks the problem
a little bit. If you inverse it, you see the problem
more clearly.
This iMap solution did give me a clue to set the
CENTER_LAT keyword to 1, if I use the original
standard parallels of -19 and 21. I like this
better than changing them to -19,9999 and 20.0005
the way I did yesterday.
This gives me more or less what iMap is giving me,
but--again--just not quite right. I find I still have
to tweak the positions of the corner pixels just slightly
to get everything aligned to my satisfaction.
But, a couple of questions about iMap. I don't want
to display the original data. I want to display a
processed image with a particular set of colors
(I think there are 15). So a processed, byte-scaled
image with a particular color table. How would I get
to this point after reading the GeoTiff file into
iMap? Or, would I have to do this in a different way?
I think this is what confused me about iMap yesterday.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51980 is a reply to message #51852] |
Fri, 15 December 2006 21:43 |
Chris[2]
Messages: 39
Registered: August 2003
|
Member |
|
|
Hi all,
1. Start iMap.
2. File->Open, open one of your Africa images
3. Double click on the image to bring up property sheet, edit the color
table to your liking
4. Insert->Map continents
5. Click on the Map tab on the right, change plot range to lon [-30, +70],
lat [-45, +45]
6. (bonus) Window->Data Manager, open your image data, click on GeoTIFF tags
node, then click on the GeoTIFF tags property to view the tags.
Everything looks fine to me:
http://atoc.colorado.edu/~torrence/imapAfrica.png
-Chris
ITTVIS
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51981 is a reply to message #51852] |
Fri, 15 December 2006 17:45 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning writes:
> Whoa!! About the third number I switched suddenly solved
> the problem! Uh, how do I justify THIS!? Talk about an
> empirical programming style...
Just for completeness, here is my *final* solution. (That
is, I'm not fooling with it anymore!)
Here are the changes I made:
1. Changed standard parallels from -19 and 21 to
-19.9999 and 20.0001. (Don't know if this is
needed or not.)
2. Changed the locations of the center of the corner
pixels like this (found empirically):
; YX coordinates of the four corners (LL, UL, UR, LR)
; longitude = [-23.49, -24.6, 64.523, 63.414]
longitude = [-22.49, -24.6, 64.523, 61.414]
; latitude = [-42.243, 43.711, 43.712, -42.242]
latitude = [-42.743, 43.711, 43.712, -40.500]
Here is how the final map projection looks now:
http://www.dfanning.com/misc/final.png
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51985 is a reply to message #51852] |
Fri, 15 December 2006 12:33 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Matt writes:
> Not sure. I use the IDL+ENVI package, which may or may not be able to
> handle it. I say this because I have never tried doing anything with
> vector data but the most basic operarions in ENVI. Seing that it's an
> image analysis program, I would be suprised if it's vector capabilites
> are very robust. Conversely, if you had ArcGIS you could probalby
> convert your vector data to your required format in 5 minutes.
I recall a conversation with Adam, the main programmer
of ENVI, in which he told me ENVI was going to design their
own map projection software because "IDL's sucked". I took
this with a grain of salt because, well, you had to know Adam.
Nevertheless, I've never heard a word of protest about ENVI's
map projections, but I do, occasionally, hear complaints
about IDL's. I am wondering now if this is what he meant
by that remark. And if so, why don't we have access to those
ENVI routines?
This is the first time I've ever run into a problem with
the map projections, although I don't do much of this. I
have, on several occasions, had to work harder than I thought
I ought to be working to get a decent result, but I have
the same problem with my service game on a tennis court,
so I haven't been too bothered by it. This is the first
time I just have not been able to come up with what I consider
a satisfactory result.
The fact that Jean can get continental outlines on the image
in other software really points to a MAP_SET deficiency as
the culprit, it seems to me. At least that is my current
hypothesis.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51986 is a reply to message #51852] |
Fri, 15 December 2006 12:07 |
Matt[1]
Messages: 23
Registered: December 2006
|
Junior Member |
|
|
Not sure. I use the IDL+ENVI package, which may or may not be able to
handle it. I say this because I have never tried doing anything with
vector data but the most basic operarions in ENVI. Seing that it's an
image analysis program, I would be suprised if it's vector capabilites
are very robust. Conversely, if you had ArcGIS you could probalby
convert your vector data to your required format in 5 minutes.
You could work the problem from the opposite angle, meaning that you
could try and adjust the image to fit the projection of the vector
data. Can you warp the image to the projection of your country outline
(is it geographic)? This is done in envi using
envi_convert_projection_coordinates, which converts coordinates from
one projection to another. I don't know if this is available as another
function in stand-alone IDL.
Also, keep in mind that geographic coordinates are no good if you are
trying to measure areas or distances. So converting to geographic may
not be useful if you are trying to quantify rather than visualize.
Matt
On Dec 15, 2:33 pm, David Fanning <n...@dfanning.com> wrote:
> Matt writes:
>> Raster data in Albers centered on Africa
>> Vector data for the world in some other projection, probably centered
>> on the prime meridian
>
>> If you get all this data to a single format (extent of African
>> continent only - not the world, both datasets in Albers with same std
>> parallels), this this could resolve the misalignment...Well, you have identified my problem in a nutshell! :-)
>
> The real question for me and my client is this: can it
> be done in IDL? Any thoughts on that?
>
> Cheers,
>
> David
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51989 is a reply to message #51852] |
Fri, 15 December 2006 11:21 |
Matt[1]
Messages: 23
Registered: December 2006
|
Junior Member |
|
|
There is no right and wrong standard parallels. The standard parallels
are lines along which the distortion of the map projection is the
smallest, getting progressively larger as you move away from the lines.
Thus, you can change your standard parallels to ANYTHING you want,
depending on many factors, mainly, which area on the Earth's surface
you want to study.
So, by changing the stadard parallels all you are doing is telling your
projection engine (or whatever it's called) to center on a different
part of the globe/map. Your vector data is not reading these standard
parallel parameters in the same way as the raster data, becasue if it
was, it would be changing along with your raster data. My veredict is
that you have too many data types/parameters for the software to deal
with accurately:
Raster data in Albers centered on Africa
Vector data for the world in some other projection, probably centered
on the prime meridian
If you get all this data to a single format (extent of African
continent only - not the world, both datasets in Albers with same std
parallels), this this could resolve the misalignment...
Matt
On Dec 15, 1:50 pm, David Fanning <n...@dfanning.com> wrote:
> kuy...@wizard.net writes:
>> Actually, yes. I have no idea why the standard parrallels might be
>> incorrect, but given the symptoms you describe, it might be worthwile
>> to try 19.99999 and -20.00001. IDL doesn't like it when the standard
>> parallels add up to exactly zero. That is unfortunate, because a Albers
>> projection with standard parallels adding up to zero is a different way
>> of describing the cylindrical equal-area projection, one of my favorite
>> map projections, and one that IDL doesn't support.Here are the results. Possibly a bit better.
>
> Here are the results with parallels at "normal"
> -19 and 21.
>
> http://www.dfanning/misc/normal.png
>
> Here are the results with parallels at -19.9999 and 20.0001.
>
> http://www.dfanning/misc/kuyper.png
>
> The results using parallels of 19.9999 and -20.001 are
> identical to that above. As are the results if I switch
> the values for STANDARD_PAR1 and STANDARD_PAR2.
>
> If you load these in your browser and hit your back
> and forward buttons, you can see a little movie of
> these projections switching back and forth. Don't know
> what that shows, but it distracts me from the real
> problem. :-)
>
> Cheers,
>
> David
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51990 is a reply to message #51852] |
Fri, 15 December 2006 10:50 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
kuyper@wizard.net writes:
> Actually, yes. I have no idea why the standard parrallels might be
> incorrect, but given the symptoms you describe, it might be worthwile
> to try 19.99999 and -20.00001. IDL doesn't like it when the standard
> parallels add up to exactly zero. That is unfortunate, because a Albers
> projection with standard parallels adding up to zero is a different way
> of describing the cylindrical equal-area projection, one of my favorite
> map projections, and one that IDL doesn't support.
Here are the results. Possibly a bit better.
Here are the results with parallels at "normal"
-19 and 21.
http://www.dfanning/misc/normal.png
Here are the results with parallels at -19.9999 and 20.0001.
http://www.dfanning/misc/kuyper.png
The results using parallels of 19.9999 and -20.001 are
identical to that above. As are the results if I switch
the values for STANDARD_PAR1 and STANDARD_PAR2.
If you load these in your browser and hit your back
and forward buttons, you can see a little movie of
these projections switching back and forth. Don't know
what that shows, but it distracts me from the real
problem. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51995 is a reply to message #51852] |
Mon, 25 December 2006 12:27 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning writes:
> A ray of light today. :-)
Sick, sick, sick...
This damn AVHRR image registration problem has been
driving me bonkers. I spent about 10 hours on it
yesterday, right up until my wife forced me to drink
some eggnog for Christmas Eve, and I woke up thinking
about it this morning before opening some presents with
the family. (My wife thought I was concentrating
on the new Christmas CD she gave me.)
But about five minutes ago I finally figured it out.
Perfect!
I'll have an article that describes how it is done
out soon, but I just wanted to let everyone know so
you could enjoy your Christmas holidays. ;-)
Merry Christmas!
David
P.S. Just so you know, the documentation was wrong
(I guess we all assumed that), but everything you
need to know is built into the GeoTiff file, if you
can just figure out how to decipher it. Those MAP_PROJ*
routines are VERY interesting, if exceedingly poorly
documented. :-)
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #51999 is a reply to message #51852] |
Sun, 24 December 2006 10:03 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Chris Torrence writes:
> Just another data point: The PDF document on the GIMMS website states that
> the images are projected onto the Clarke 1866 Ellipsoid, while the GeoTIFF
> tags in the file indicate that it is WGS-84. I wonder which one is correct.
>
> Now, switching to the Clarke 1866 ellipsoid didn't actually help (it
> probably only changes it by a few hundred meters or so), but it makes you
> wonder whether the rest of the GeoTIFF information is accurate given that
> the ellipsoid is incorrect...
A ray of light today. :-)
Using Chris's initial instructions for how to open and
read this GeoTiff file in iMap resulted in the same slight
mismatch between the continental outlines and the image.
However, this morning I went back to iMap to try again.
This time, after I read the geotiff file into iMap, I
chose Map Register Image from the Operations menu. Viola!
Now when I add continental outlines, they map perfectly.
But, WHERE is this happening in the iTool code!?
Your guess is as good as mine. I'm now convinced this
can be done in IDL. But I still want to know HOW.
Chris, can you give us any insight into how that
iRegister Map wizard works?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #52005 is a reply to message #51852] |
Sat, 23 December 2006 17:31 |
Chris[2]
Messages: 39
Registered: August 2003
|
Member |
|
|
Hi all,
Just another data point: The PDF document on the GIMMS website states that
the images are projected onto the Clarke 1866 Ellipsoid, while the GeoTIFF
tags in the file indicate that it is WGS-84. I wonder which one is correct.
Now, switching to the Clarke 1866 ellipsoid didn't actually help (it
probably only changes it by a few hundred meters or so), but it makes you
wonder whether the rest of the GeoTIFF information is accurate given that
the ellipsoid is incorrect...
-Chris
ITTVIS
"David Fanning" <news@dfanning.com> wrote in message
news:MPG.1fec703a235800ae989e46@news.frii.com...
> Folks,
>
> Does anyone have any experience working with AVHRR NDVI
> image data or Albers map projection? I have obtained
> the data, which is of the African continent from here:
>
> ftp://ftp.glcf.umiacs.umd.edu/glcf/GIMMS/Regional/Albers/Afr ica
>
> The image is in an Albers Conical equal area projection
> and the centers of the four corner pixels are known from
> the documentation:
>
> ; YX coordinates of the four corners (LL, UL, UR, LR)
> longitude = [-23.49, -24.6, 64.523, 63.414]
> latitude = [-42.243, 43.711, 43.712, -42.242]
>
> This is a GeoTiff file, so I also pull the Standard
> Parallels out of the geotiff information stored in
> the file (they are -19 and 21).
>
> I follow the method outlined on this page (which has
> worked perfectly for a polar stereo map projection),
> using instead of a Stereo projection, an Albers
> projection with standard parallels:
>
> http://www.dfanning.com/map_tips/precipmap.html
>
> The method *ALMOST* works! :-)
>
> But the continental outlines do not QUITE line up properly.
> You can see my result here:
>
> http://www.dfanning.com/misc/africa.jpg
>
> Do you think this might be an Albers projection problem?
> A difference between MAP_PROJ_INIT and MAP_SET? (I have
> tried different DATUMS with no change in effect.)
>
> Or, do you think this might just be right? :-(
>
> Cheers,
>
> David
>
> P.S. Don't worry about the colors. They are still screwed up.
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
|
|
| Re: AVHRR Image Mapping Problem [message #52085 is a reply to message #51975] |
Thu, 28 December 2006 07:03 |
George N. White III
Messages: 56
Registered: September 2000
|
Member |
|
|
On Mon, 17 Dec 2006, kuyper@wizard.net wrote:
> I only know about one instrument (MODIS) on two Earth-pointing
> satellites (Terra and Aqua), but I'm personally responsible for the
> geolocation on the MODIS data from those satellites. The file
> attributes summarizing the location of a granule are just as accurate
> as the geolocation which is provided in the MOD03 files for every 1km
> pixel: the RMS error is nominally 50 meters, though we're actually
> doing a bit better than that, with our smallest pixel size being 250
> meters. Except during a maneuver, the actual orientation of the
> satellite is used, not the planned orientation.
>
> The software I'm responsible for was modified from software for earlier
> instruments, and has been borrowed as the basis for sofware for the
> VIIRS instrument on NPP, so I suspect this is not uncommon for
> earth-pointing satellite imagery.
I work with AVHRR and SeaWiFS as well as MODIS. With the older data,
each image must be registered using ground control points. This can be
done manually in Terascan and SeaDAS, and there are various automated
systems. MODIS geolocation eliminates this (tedious and much hated) step.
--
George N. White III <WhiteG@dfo-mpo.gc.ca>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
