Most Blue Skies is progressing nicely! After an incredibly frustrating week or so battling with odd data formats we had a few breakthroughs and we finally have our 'core' data downloading and being used in the sky colour calculations. Josh has also checked in some nice code to convert the spectrum that SMARTS gives us to a RGB value. I hooked it all together today and it looks great!
For those of you who are interested in using MODIS Level 2 data with GIS applications (and can hopefully find this page via Google), I can probably offer some advice. As you'll know most GIS software doesn't support the HDF format that the MODIS data comes in so you need to find some tools to convert it into something you can work with. Finding the right tool, however, is a real pain. Also MODIS use a slightly extended version of HDF (just to make things even more difficult) so you need to find tools that are specially written to support MODIS data. The Level 1 and 2 products store data in 'swath' format. This basically means raw instrument readings each with a longitude and latitude coordinate attached. You need to therefore reproject and interpolate this data into some kind of grid in some projection that your GIS software/libraries can handle. Don't bother trying to use HEG to produce GeoTIFFs unless you are using certain data sets from certain products that don't have fill values and meet a bunch of idea criteria which I can't remember. The problem with HEG is that it doesn't use nearest neighbour interpolation when reprojecting the MODIS 'swath' to a geographically projected grid (even though you might tell it to). So this messes up scientific data sets where the values shouldn't be interpolated, e.g. bitfields (e.g. cloud mask data). On top of that, HEG doesn't honour the fill values and interpolates between these fill values and the actual data so you get even more bad data coming out.
In the end we HDFLook to convert each swath to a gridded linear projection in a new HDF file. It seems to do a very good job (although I'm having some problems with swaths that cross the international date line, not sure why). HDFLook can also produce a GeoTIFF but it seems to do a worse job than HEG at choosing the right data type for the TIFF data (you can store floats in a TIFF apparently). It always produces an RGB tiff which isn't very useful if your SDS uses floats. So I just produce a gridded HDF file with HDFLook. Then I've been using the Java HDF API to read the data directly from the new HDF file and build a coverage with GeoTools. I wanted to avoid calling any JNI code from the main app so I wrote a separate simple program to read the HDF files and spit out the values. Ask me if you want the Java code I used to do this (it's not particularly pretty).
