Hi!
I am working with SMI and Bin Level 3 data daily . I do not have Seadas and I am using Matlab to read and process the HDF files. I've been reading and working with SMI files using Matlab and I am doing fine. Matlab loads into memory a 2160x4320 (=No) matrix and I found in the forum the rule to construct the respective lat/long matrixes.

But because I need to work with many parameters I find that using Bin data is easier because all what I need  is in the same file. However, when I read the Bin file with Matlab, it loads a long vector of length N where N is NOT the product of 2160x4320, that is N<N0. So I assume that all data in the BIN correspond to points in water bodies and there are not points over land (as opposed to a SMI file that has grid points over land with fill values) and this is why N<No. Correct?

In any case, I find that I do not have enough information to assign a lat and long to each of the data points in the Bin file.   I have not found such information in the documentation or FAQ. My objective is to map the BIN data into a 2160x4320 matrix with the VDATA from the BIN and fill or blanks in the grid points that correspond to land.

I found this IDL code which assigns lats/long for bin data. It is found in
http://oceancolor.gsfc.nasa.gov/DOCS/idl/l3bin/ll2bin.pro

I can translate it into Matlab but there are couple of inputs that I do not know: the input parameters  nrows and bins.  What are they and how can I find them in the BIN hdf file?

Second , I need to know a bit about the logic of this IDL code. For the SMI HDF file, I used the following scheme to generate a grid of lats and longs (chunk of Matlab here):
----------------------
incr=360/4320;
mid=incr/2;
lat=[90-mid:-incr:-90]; % generate a vector from 90-mid to -90 in steps of incr
lon=[-180+mid:incr:180-mid]; % generate a vector from -180+mid to 180-mid in
                             % steps of incr
%%% generate a 2160x4320 matrix of latitudes and longitudes
mat_lat = repmat(lat',1,4320);
mat_lon= repmat(lon,2160,1); 
----------------------

Does the BIN data follow this same logic for spacing and size of grid?

Anybody out there can help?

Thanks!

Santiago

Hi Santiago,

I suggest that you have a look at the following references in addition
to our source code to get a better idea of the projection we use for our
binned data.  (It is an integerized variation on the sinusoidal projection.)

A comprehensive overview of binning schemes for different missions
is available from the International Ocean Colour Coordinating Group.
See the link to Report 4 on the following page.
http://www.ioccg.org/reports_ioccg.html

An out-of-date document published before SeaWiFS was launched
still has useful pseudo-code for the bin-number-to-lat-lon conversion.
http://oceancolor.gsfc.nasa.gov/cgi/tech_memo.pl?32
See, in particular, Appendix A in the PDF file.

See also the following forum posting for more code and an image
showing the distribution of 9-kilometer bins around Florida.
http://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?pid=3604#pid3604

I hope this helps,

Norman

There is a user here (but he is currently travelling) who was going to write some Matlab code to read l3 binned data.  I'm not sure how far he got, but will ask when he returns.
As you will see from the IOCCG Report 4, the binned data avoids some potential statistical issues with mapped data that can be important if your region of interest covers a range of latitudes.

SeaDAS is free and can be installed on a wide range of systems.  Even if you end up doing everything in Matlab you will find it helpful to have SeaDAS for checking that you are doing the calculations properly.  SeaDAS also includes sources.  There is a program called l3bindump (.c source) that shows how to extract values from the binned files: $SEADAS/src/build/src/l3bindump.  Since l3bindump uses only the standard hdf libraries, you can tweak it and compile your own version using the system C compiler (e.g., without the complete
SeaDAS build process).

Yet another option is to use the IDL code (readl3bin.pro, etc., from oceancolor.gsfc.nasa.gov DOCS/idl/hdf/) with the open source GNUdatalanguage (GDL).   gdl is available on many linux distros or with systems like macports on Apple, but make sure the version you get has the hdf4 support.   There is a bug in the GDL hdf such that the vdata_id has to be detached and then attached between multiple HDF_VD_READ calls (exercise left to the reader).

See this post:

http://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?pid=13829#pid13829

Sean