| Re: weird behavior of Triangulate [message #81333 is a reply to message #81286] |
Thu, 06 September 2012 07:31   |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Yngvar Larsen writes:
>
> On Saturday, 1 September 2012 16:45:46 UTC+2, David Fanning wrote:
>
>> My conclusion is that if you need things regridded (and
>> if you work with satellite images, this is *always*
>> required, eventually), you will have to use something other
>> than IDL to do the job.
>
> Could you elaborate a bit on that conclusion?
>
> I work in an institute where IDL has been used as the main tool for analysis of remote sensing data for nearly 3 decades, so this statement puzzles me...
>
> I can only think of the following issues:
>
> * IDL didn't have support for map projections until version 5.6 or so. Before that, we wrapped the PROJ.4 library to do the job. But the MAP_PROJ_* functionality has now been available for almost a decade (with some inherent problems that are possible to work around).
>
> * Satellite data are large, so GRIDDATA might not work too well if you operate directly on the entire data set. Solution: divide-and-conquer. Divide your output grid in blocks, and process separately. Should normally be possible to make an efficient solution based on GRIDDATA and/or INTERPOLATE.
>
> But I have a feeling you have something else in mind?
Typically, when you work with satellite data you have some
notion of a "study area". For example, in my lab we are
doing some research on the big High Park fire that burned
a large portion of the forest near here this summer.
Typically, the study area is a rectangular region or grid
that you place on top of the area of the Earth you wish to
study.
Then, you look for data that covers the study area. Many times
the data only covers a portion of the study area. The data you
do find is often in different resolutions (LandSat, 30m, Quickbird
5m, etc.) To make sense of this data, it needs to be gridded
according to the resolution of the study area grid. This is a
difficult problem, and there are various ways that the data can
be gridded (nearest neighbor, natural neighbor, weighted gridding,
etc.).
At NSIDC, we used a C program named mapx to do this gridding for
us. Given a study grid resolution and map projection, data from
various sensors could be "gridded" (and mosaicked, if needed) in
various ways. This is the part I don't know how to do in IDL.
It seems as if GridData would be useful. But, unless you are
working with 50x50 pixel blocks of data, GridData is ungodly
slow! Interpolate is probably better, but you don't have
many gridding options (linear, bilinear, cubic).
Once you get the data into your rectangular study grid, you
generally set up a map coordinate system that describes it.
As you can see this morning, this is either impossible to do
in the new IDL function graphics system, or so opaque as to
be invisible.
In any case, I'd be interested to know how you solve these
problems. :-)
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.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
