partial subscene extraction

By vlance Date 2012-01-03 14:37 Edited 2012-01-03 14:41

Hello, happy new year!

Is there a way allow for a partial subscene extraction in modis_l1a_extract when the satellite file contains only a portion of my area of interest?
I imagine I could open each file and manually determine the file's pixel and line "edges" and substitute them into the l1aextract_modis command, but do you have any examples for automating this?

My example file is A2005277184500.L1A_LAC
My desired subscene is
SWLON=-94
SWLAT=27
NELON=-88
NELAT=30

This file includes SOME of my area of interest, but the area of interest extends BEYOND the satellite file.
so the command for modis_l1a_extract.csh fails on the lonlat2pixline step - see below:
-----------------
bash-3.2$ modis_l1a_extract.csh A2005277184500.L1A_LAC A2005277184500.GEO -94 27 -88 30 A2005277184500.L1A_sub
lonlat2pixline A2005277184500.GEO -94 27 -88 30
modis_l1a_extract.csh: ERROR: lonlat2pixline failed to determine start/end line/pixel. Exiting.
----------------

entering the lonlat2pixline command on it's own gives nothing:
----------------
bash-3.2$ lonlat2pixline A2005277184500.GEO -94 27 -88 30
bash-3.2$
----------------

I am running seadas 6.2.2b on Mac OSX 10.6.8

Thanks, V-

By gwyn Date 2012-01-03 20:57

V -

The immediate answer is that your AOI lies outside the MODIS swath - even though it is inside the lat/lon limits. Since the orbital plane is tilted wrt Earth's axis, the swath is at an angle to the lat/lon rectangle that bounds the data. Your AOI occupies an empty corner of that rectangle. I'm working on a pretty picture to illustrate this.

lonlat2pixline is correct in returning no result. In this case, the exit status is 1 (could be better documented).

As far as scripting goes - modis_l1a_extract.csh is quite old, but should also return an exit status of 1 when there is no overlap.

You should consider upgrading to a recent version of SeaDAS. The latest utilities are written in Python and are much more robust than the older csh tools.

shark> modis_L1A_extract.py -n 30 -s 27 -w -94 -e -88 A2005277184500.L1A_LAC Error locating pixel/line range to extract. shark> echo $status 1

By vlance Date 2012-01-03 21:42

OK, thanks, Gwyn.
I have been holding off on 6.3 because I saw that some folks had some problems with Mac OSX 10.6.8.
Perhaps the issues have all shaken out by now, so I will consider doing at some point, but not anxious to get into rewriting and troubleshooting scripts!

By gwyn Date 2012-01-03 23:15

Here's an illustration of your granule. You AOI (green) lies partly in the lat/lon bounding box (red), but does not intersect with the actual granule (border in yellow).

You might consider SeaDAS 6.2.2, if you're not ready to go to 6.3.

By vlance Date 2012-01-17 20:54

Very nice, Gwyn, but now i'm confused why this particular file was identified as a valid file by the website browser? The answer is probably more technical than I need to know.
Best, V-

By vlance Date 2012-01-17 20:56

ps, i am using 6.2.2b

By @sean Date 2012-01-17 21:44

The answer is simply that the quadsphere binning scheme used by the browser has a granularity of about 72km.
The south-east corner of your region is in the same bin as part of the last scan line of the scene.

Sean

By @norman Date 2012-01-17 22:08

Here's the pictoral version of Sean's reply.

Magenta outlines your region of interest.

Blue outlines the scene, A2005277184500.L1A_LAC.

Green outlines the 15 quadsphere (level-6) bins that
your region of interest gets converted to.

Red outlines the 250 quadsphere bins that are stored
in our database for this scene.

Yellow marks the overlapping quadsphere bin that
causes this scene to "match" your region of interest.

Norman