| RSI response to CONTOUR problems/questions. [message #1474] |
Mon, 27 September 1993 09:31 |
info
Messages: 14
Registered: April 1993
|
Junior Member |
|
|
A number of news group postings have been about the new CONTOUR, and
in particular about the /SPLINE and /FILL options. Although we do not
normally respond to postings on the news group, we believe that a
response is in order.
In response to Sylvain Korzennik's (Smithsonian Astrophysical
Observatory) points in regard to changes in the CONTOUR procedure:
> 1) the userlib function MIN_CURVE_SURF is NOT equivalent to the
> keyword /spline: indeed, MIN_CURVE_SURF() takes forever to process
> any medium size array (ie a 40x20), while /splines will work fine,
> and. Adding a new userlib function is improvement, but dropping a
> useful keyword definitively isn't
Indeed the MIN_CURVE_SURF is not equivalent to the old keyword
/SPLINE. The spline smoothing was applied to each contour line
individually, rather than to the entire surface globally. One
unfortunate effect of local smoothing was that contour lines
occasionally crossed. This was clearly wrong, and we believed that a global
smoothing technique, such as MIN_CURVE_SURF, would remove an error and
be an improvement.
We hope to write a user library procedure that will take contour paths
as written to a file, and apply spline smoothing to them, duplicating
most of the functionality of the old CONTOUR, /SPLINE routines.
A number of users have complained about the speed of MIN_CURVE_SURF.
Sample timings are included in the function documentation header. The
time required is very roughly proportional to K1 * M^3 + K2 * N * M,
where M is the number of input points and N is the number of output
points, and K1 and K2 are constants. Simply put, for a large number
of input points, the routine is a dog. But, smoothing is normally
only desired when the input sampling is sparse.
> 2) the /fill option is broken when trying to fill only 1 level, why
> so?:
This is clearly a bug. All known bugs with CONTOUR, /FILL have been
fixed and will be available with version 3.5, due in November.
We apologize for these errors, and have learned the hard way that
general contouring and filling is extremely difficult to implement
and test.
There is a simple work-around for the 1 level filling bug: provide a
second level, higher than all valid data values.
Other CONTOUR, /FILL bugs that have found and fixed are:
- Filled contours are now clipped against the plot window.
- Outer contours, which didn't have edge crossings were not drawn.
- The CONTOUR procedure would crash if the difference between a
contour value and a data value was extremely small.
3) We considered orienting the labeling to indicate the downhill
direction but rejected it because: 1) labels could appear upside down,
backwards, etc. making them hard to read; 2) there seems to be no
consensus as to which way the labels should read (uphill or downhill);
and 3) downhill ticks seem more intuitive, are widely accepted in the
geologic sciences.
In response to Patrick Ryan's (NASA/GSFC) requests:
> 1) to "Get rid of /MAX_VALUE. put in code to do real handling of
> missing data."
Ralph Finch (Calif. Dept of Water), and Bill Thompson (NASA/GSFC) also
expressed this opinion. Part of the IDL philosophy is that since IDL
is a full feature language, it is better to solve such problems using
IDL, rather than jam in special purpose features. Providing a
"special missing data value" is trivial within IDL's framework.
Here, is a CONTOUR procedure (in 8 lines of code) that accepts a
special value for missing data:
PRO CONTOUR_MISSING, z, MISSING=missing, _EXTRA=extra
gone = WHERE(z eq missing, count)
if count gt 0 then begin
zz = z
zz(gone) = 1.0E30 ;Assumed to be larger than any valid data
CONTOUR, zz, MAX_VALUE=9.99E29, _EXTRA=extra
endif else CONTOUR, z, _EXTRA=extra ;No missing data
end
This technique may also be used for any other IDL procedure that
accepts the MAX_VALUE keyword for missing data.
> 2) "Put in a really slick irregular data interpolator. NCARG's BIVAR
> code is pretty good."
NCARG's BIVAR uses Akima's method which consists of triangulation
followed by a 5th order polynomial fit. TRIANGULATE, followed by
TRIGRID(/QUINTIC) does exactly the same thing, but with a more
efficient triangulation algorithm.
> 3) "Make MAP_SET more sophisticated. Allow the user to color in the
> continents (another thing NCARG does well)."
We are exploring the acquisition of continental and political boundary
outline data bases that are better organized and that allow polygon
filling. IDL uses the old NCAR SUPMAP.DAT. The database now used
in NCARG is not public domain, and as such, not freely redistributable.
Patrick Ryan also says:
> My solution is: Call RSI! Since we all need support contracts now, we
> can all call them. They won't know what's wrong unless we tell them.
> Don't assume that posting gripes here will make IDL's developers work
> any faster.
YES!!! As the FAQ states, the newsgroup is for communicating with other
users, not the vendors. If you want to say something to RSI, we are happy
to listen. Our phone number (303-786-9900) and E-mail address
(info@rsinc.com, or support@rsinc.com if you have a current support
contract) are well known.
Finally, in her posting, Amara Graps presents a number of examples dealing
with CONTOUR, /FILL and map projections. Contours which are not closed and
which intersect a map edge are not filled. This will be explained in
the next version of the documentation.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
