Hi James,
Thanks for your great comments. The "gridded data" referred to in the
comments is an outdated comment, sorry for misleading you.
I'm talking about MODIS L1B data in its unsubsetted form (the routine
works for these data) and its channel subsetted form (the routine
doesn't work for these data). So no reprojection was ordered as part
of the post processing, only channel subsetting.
Interesting that the code worked for your reprojected and channel
subsetted data (I've since modified my code to include the endaccess
call, but the error is still present). I've tried the code on two
completely different systems (one windows, one unix, both the same IDL
version, however), and I get identical errors on both. I guess it is
the reprojection of the data which somehow makes the data
fundamentally different so that it works with the provided routine.
Maybe try the test again without reprojection?
As per your other question, the type of newdata is the same as
olddata, and the dimensions are the same also (however, I've checked
with the unsubsetted data, and you are able to write data with
different dimensions than the existing array). For my testing, I've
just been writing a smaller vector e.g., [1,2,3,4] to the existing
SDS, which replaces the first 4 elements in the unsubsetted HDF, but
causes the error in the subsetted HDF.
However, I may have uncovered the source of the error!
Is it possible that somehow the act of subsetting the data somehow
subtly makes the file not fully HDF compliant? I mean that the new
data are still HDF-EOS compliant, but not actually HDF compliant. And,
of course, I've been using IDL's HDF routines to edit these files,
whereas I should possibly have been using EOS_SW_WRITEFIELD (http://
www.astro.princeton.edu/~esirko/idl_html_help/EOS-routines134.html).
What are your thoughts on this?
Cheers,
Alex.
|
