comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Random problem with Delaunay triangulation
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Random problem with Delaunay triangulation [message #55803] Wed, 12 September 2007 06:10 Go to next message
Kenneth Bowman is currently offline  Kenneth Bowman
Messages: 86
Registered: November 2006
Member
In article <1189545358.026232.78690@i13g2000prf.googlegroups.com>,
Bill Gallery <wgallery@aer.com> wrote:

> Does anyone has any experience with the relative merits of the
> following routines for interpolation on a sphere?
>
> 1. qhull and griddata
>
> 2. sph_scat.pro
>
> 3. triangulate and trigrid
>
> Bill

Have you considered doing least-squares fitting to spherical harmonics
instead of interpolation?

Ken Bowman
Re: Random problem with Delaunay triangulation [message #55821 is a reply to message #55803] Tue, 11 September 2007 14:15 Go to previous messageGo to next message
wgallery is currently offline  wgallery
Messages: 32
Registered: December 1998
Member
On Sep 11, 3:27 pm, "Haje Korth" <haje.ko...@nospam.jhuapl.edu> wrote:
> Bill, here a practical tip: Have you tried to randomly reshuffle your input
> data? Does this make a difference? H.
>
> "Haje Korth" <haje.ko...@nospam.jhuapl.edu> wrote in message
>
> news:fc6oi5$ei3$1@aplnetnews.jhuapl.edu...
>
>> Bill,
>> you just hit a nerve with me. I thought I was the only one having those


Haje,

I did not try reshuffling the input data, but did find a fix.
Originally, the input data had a minimum latitude of 30.0 deg N and
the specified regular grid also had a minimum latitude of 30.0. When
I expanded the input data to have a minimum latitude of 20 deg N, the
error message went away. Apparently you need data outside the area of
interest for the interpolation to be robust.

Further experimentation showed that when the minimum latitude of the
input data was 30. deg, the interpolated values at 30 deg for the
cases that did not fail showed large excursions from expected values.
This may be partially due to the nature of the input data, which is
poorly sampled below ~40 deg N (temperature data from the SABER
instrument on the TIMED satellite.)

Does anyone has any experience with the relative merits of the
following routines for interpolation on a sphere?

1. qhull and griddata

2. sph_scat.pro

3. triangulate and trigrid

Bill
Re: Random problem with Delaunay triangulation [message #55822 is a reply to message #55821] Tue, 11 September 2007 12:27 Go to previous messageGo to next message
Haje Korth is currently offline  Haje Korth
Messages: 651
Registered: May 1997
Senior Member
Bill, here a practical tip: Have you tried to randomly reshuffle your input
data? Does this make a difference? H.


"Haje Korth" <haje.korth@nospam.jhuapl.edu> wrote in message
news:fc6oi5$ei3$1@aplnetnews.jhuapl.edu...
> Bill,
> you just hit a nerve with me. I thought I was the only one having those
> trouble. I would love to find out where this error comes from and how to
> prevent it. The problem drove me to going external and using ssrfpack and
> stripack from netlib to do spherical interpolation. This method is not
> fool proof either but at least this way I have the source code and can
> find out why an error occurs and, more important, I can determine what it
> actually means.
>
> Anyway, this response won't help you much in solving your problem but
> supports your case for better documentation of the interpolation routines
> (I previously suggested to ITTVIS to write a tutorial on the subject) or,
> at the least, more meaningful error messages. (The folks at ITTVIS do read
> this newsgroup.)
>
> Good luck,
> Haje
>
>
> "Bill Gallery" <wgallery@aer.com> wrote in message
> news:1189535983.796705.67590@o80g2000hse.googlegroups.com...
>> I am interpolating satellite data (lat, lon, temperature) from a
>> irregular grid to a regular lat, lon grid using:
>>
>> pro get_gridded_temp_image, ....
>> .
>> .
>> .
>> grid_lat=findgen(31)*2.0+30.0 ;30 to 90 deg @2 deg
>> grid_lon=findgen(181)*2.0 ;0 to 360 deg @2 deg
>> qhull, x, y, tri, /delaunay, sphere = s
>> temp_grid = griddata( x, y, z, /sphere, /deg, $
>> /grid, xout = grid_lon, yout = grid_lat, $
>> method = 'NaturalNeighbor', $
>> triangles=tri, $
>> missing = !values.f_nan)
>>
>> where x,y are longitude, latitude, and z is temperature (patterned
>> after Example 5 in the IDL help for griddata.pro)
>>
>> Usually this procedure works fine, over thousands of different cases.
>> However, today I tried it and got the error message:
>>
>> GRIDDATA: Triangle 652 not in counterclockwise order.
>> Execution halted at: GET_GRIDDED_TEMP_IMAGE 184
>>
>> The ranges of the input variables are (mve is a routine that prints
>> the stats on a variable):
>>
>> IDL> mve,x
>> Variable type mean std dev minimum
>> maximum n_elements NaN or I
>> Float 178.55 102.79 0.070000
>> 358.05 (529) = 529 0
>> IDL> mve,y
>> Variable type mean std dev minimum
>> maximum n_elements NaN or I
>> Float 54.660 19.100 20.340
>> 82.930 (529) = 529 0
>> IDL> mve,z
>> Variable type mean std dev minimum
>> maximum n_elements NaN or I
>> Float 214.63 9.7416 192.56
>> 233.31 (529) = 529 0
>> IDL> mve, tri
>> Variable type mean std dev minimum
>> maximum n_elements NaN or Inf
>> Longword integer 249.43 149.12 0.00000
>> 528.00 (3,966) = 2898 0
>>
>>
>> Note: I tried the routine sph_scat which is also advertised to regrid
>> on a sphere. However, the interpolated values are way off scale:
>>
>> IDL> r=sph_scat(x,y,z,bounds=[0,30.0,360,90],gs=[2,2],bout=bout)
>> IDL> mve,r
>> Variable type mean std dev minimum
>> maximum n_elements NaN or Inf
>> Double float 208.09 96.313 -480.31
>> 869.93 (181,31) = 5611 0
>>
>>
>> Any suggestions on how to trouble shoot, fix?
>>
>> Thanks,
>>
>> Bill Gallery
>>
>
>
Re: Random problem with Delaunay triangulation [message #55824 is a reply to message #55822] Tue, 11 September 2007 11:59 Go to previous messageGo to next message
Haje Korth is currently offline  Haje Korth
Messages: 651
Registered: May 1997
Senior Member
Bill,
you just hit a nerve with me. I thought I was the only one having those
trouble. I would love to find out where this error comes from and how to
prevent it. The problem drove me to going external and using ssrfpack and
stripack from netlib to do spherical interpolation. This method is not fool
proof either but at least this way I have the source code and can find out
why an error occurs and, more important, I can determine what it actually
means.

Anyway, this response won't help you much in solving your problem but
supports your case for better documentation of the interpolation routines (I
previously suggested to ITTVIS to write a tutorial on the subject) or, at
the least, more meaningful error messages. (The folks at ITTVIS do read this
newsgroup.)

Good luck,
Haje


"Bill Gallery" <wgallery@aer.com> wrote in message
news:1189535983.796705.67590@o80g2000hse.googlegroups.com...
> I am interpolating satellite data (lat, lon, temperature) from a
> irregular grid to a regular lat, lon grid using:
>
> pro get_gridded_temp_image, ....
> .
> .
> .
> grid_lat=findgen(31)*2.0+30.0 ;30 to 90 deg @2 deg
> grid_lon=findgen(181)*2.0 ;0 to 360 deg @2 deg
> qhull, x, y, tri, /delaunay, sphere = s
> temp_grid = griddata( x, y, z, /sphere, /deg, $
> /grid, xout = grid_lon, yout = grid_lat, $
> method = 'NaturalNeighbor', $
> triangles=tri, $
> missing = !values.f_nan)
>
> where x,y are longitude, latitude, and z is temperature (patterned
> after Example 5 in the IDL help for griddata.pro)
>
> Usually this procedure works fine, over thousands of different cases.
> However, today I tried it and got the error message:
>
> GRIDDATA: Triangle 652 not in counterclockwise order.
> Execution halted at: GET_GRIDDED_TEMP_IMAGE 184
>
> The ranges of the input variables are (mve is a routine that prints
> the stats on a variable):
>
> IDL> mve,x
> Variable type mean std dev minimum
> maximum n_elements NaN or I
> Float 178.55 102.79 0.070000
> 358.05 (529) = 529 0
> IDL> mve,y
> Variable type mean std dev minimum
> maximum n_elements NaN or I
> Float 54.660 19.100 20.340
> 82.930 (529) = 529 0
> IDL> mve,z
> Variable type mean std dev minimum
> maximum n_elements NaN or I
> Float 214.63 9.7416 192.56
> 233.31 (529) = 529 0
> IDL> mve, tri
> Variable type mean std dev minimum
> maximum n_elements NaN or Inf
> Longword integer 249.43 149.12 0.00000
> 528.00 (3,966) = 2898 0
>
>
> Note: I tried the routine sph_scat which is also advertised to regrid
> on a sphere. However, the interpolated values are way off scale:
>
> IDL> r=sph_scat(x,y,z,bounds=[0,30.0,360,90],gs=[2,2],bout=bout)
> IDL> mve,r
> Variable type mean std dev minimum
> maximum n_elements NaN or Inf
> Double float 208.09 96.313 -480.31
> 869.93 (181,31) = 5611 0
>
>
> Any suggestions on how to trouble shoot, fix?
>
> Thanks,
>
> Bill Gallery
>
Re: Random problem with Delaunay triangulation [message #55930 is a reply to message #55803] Thu, 13 September 2007 06:44 Go to previous message
wgallery is currently offline  wgallery
Messages: 32
Registered: December 1998
Member
On Sep 12, 9:10 am, Kenneth Bowman <k-bow...@tamu.edu> wrote:
> In article <1189545358.026232.78...@i13g2000prf.googlegroups.com>,
> Bill Gallery <wgall...@aer.com> wrote:
>
>> Does anyone has any experience with the relative merits of the
>> following routines for interpolation on a sphere?
>
>> 1. qhull and griddata
>
>> 2. sph_scat.pro
>
>> 3. triangulate and trigrid
>
>> Bill
>
> Have you considered doing least-squares fitting to spherical harmonics
> instead of interpolation?
>
> Ken Bowman

Ken,

No I haven't. I'm not familiar with the technique. Anyway, the problem
was solved with the routine grid_input (see post 9). But thanks for
the suggestion.

Bill
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Congrid/Rebin Conundrum
Next Topic: Re: Congrid/Rebin Conundrum

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 19:25:54 PDT 2025

Total time taken to generate the page: 0.00707 seconds