Re: TRIANGULATE/TRIGRID problem in IDL 5.3 (SGI)

[James Kuyper <kuyper(at)wizard.net>]

"Liam E. Gumley" wrote:
...
> swath where I don't want triangles! However it also demonstrates that
> the triangles are created in a very consistent manner for the swath
> itself. The swath dimensions of 1354 x 10 are never going to change
> (yes, it is MODIS data), and I don't believe the connectivity list will
> ever change. So I can probably compute a triangle list manually just
> once (without using TRIANGULATE), and then use it for all cases in
> conjunction with TRIGRID. I'll send an update when I've implemented and
> tested this idea.

That will handle the normal case. However, if you need to be able to
handle data even when things go a little bit wrong, then for each scan
you should:

0) Check the "Geo scan quality" SDS; if the first column for a given
scan has a 1 in it, we got no useful information about how fast the
mirror was moving, making geolocation of that scan impossible.

1) Check the 'EV frames' value for that scan; it doesn't have to be 1354
- occasionally it's 0 due to a long data gap (> 0.5 seconds). Less
frequently, it's a number between 0 and 1354; this happens if a long
data gap starts or finishes during the Earth View segment of a scan.

2) Check the gflags SDS. There are things that can go wrong with
geolocation on a per-pixel basis; in the pixels where gflags is >=64,
either the line of sight could not be calculated, or it didn't intersect
the Earth; either way, the stored values are unusable fill values.

If you follow that advice, it's going to mess up your pre-computed
triangulation. On the other hand, less-than-perfect scans are rare
enough that most users can afford to simply discard them.