hello,

I have generated L2 SeawiFS products with the msl12 command over the area of
the North Sea  for all 2004 year.
Now, I would like to reproject all these products (nlw, chl...) in the same
projection and grid in order to make my own processes.
What is the easier way to reproject a group of L2 products on the same grid
and for the same min/max latitude and longitude box with seadas ?

Thank you in advance.

Severine

You can write a seadas script and use the bl2map command:

http://oceancolor.gsfc.nasa.gov/seadas/doc/bl2map/bl2map.html

Mark

You will likely want to use the SeaDAS bl2map command within an IDL command file. For example, create a unix text file called "map.cmd":

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
filenames=findfile('S*.L2')

; for embedded IDL you must place "& $"
; at the end of lines that are part of loops
for i=0, n_elements(filenames)-1 do begin  & $
   base=strmid(filenames(i),0,14)  & $
   bl2map, filenames(i), base(0)+'.map', 'chlor_a'  & $
   clear_up  & $
endfor
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

...then running "seadas -b map.cmd" or "seadas -em -b map.cmd" will map every S*.L2 file in the directory.

hello

I have tried the bl2map command but I would like to reproject the data
without any calculation on them. It seems that bl2map reprojects the data and
interpolates or smoothes them when no data correspond to a lat/lon point ?
Is it possible to use bl2map without smoothing the data on the reprojection
area (keeping some gap if necessary) ?

Thank you very much for your help

Severine

Severine,

What you need is binning, not mapping.  The l2bin program
will take Level 2 files and bin them to any of a number of
resolutions.  Once the L2 files are binned, you can map
them to any projection you want.  You have the option of
binning each L2 file individually, then combining these
"daily" L3 bin files in larger temporal groupings (e.g.
weekly, monthly, seasonal, annual...) using the l3bin program.
Alternatively, you can pass the l2bin file multiple L2 files
and skip the l3bin step.  All depends upon your needs.

Regards,
Sean

What is wrong!?

Any body!

I canīt figure what is wrong with this scritp:

f=findfile('/dados2/gustavo/seawifs/2001/S*.L2')

for i=0,n_elements(f)-1 do begin & $

base=strmid(f(i),28,14) & $

out=base(0)+'.l2_mapped' & $

bl2map, f(i), out, ['Rrs_412','Rrs_443','Rrs_490','Rrs_510','Rrs_555','Rrs_670','Rrs_765','Rrs_865','nLw_412','nLw_443','nLw_490','nLw_510','nLw_555','nLw_670','nLw_765','nLw_865','chl_oc4','K_490', 'adg_412_carder','tsm_clark','l2_flags'], iproj=11, xsize=2608,ysize=2778, limit=[-5,-65,20,-40], isotropic=1 & $

endfor

And appears this error message to all my products:

Getting - "tsm_clark" data from HDF file...
BANDDATA        FLOAT     = Array[435, 2405]
HDF_OPEN error on file - /S200100116355.l2_mapped
Error in generating the output for band - tsm_clark

The S*.L2 image that I am using is already subset/subsampled

That maybe the problem?

Your script's syntax seems ok.

You may add a line to check those output file names
    print, 'outfile = ', out      & $

Try to work on fewer files with fewer product names at
beginning stage.

You may send couple sample files to us for test via email.

Long

>> HDF_OPEN error on file - /S200100116355.l2_mapped

Do you really have write access to the root directory (or did you mean to strip off one more leading character and write it to the current directory)?

Yes, you are also missing a digit from your filename.  Maybe if you use 29 instead of 28 you'll catch all of the filename and skip the slash.

Mark

Thanks everybody I have found where I was wrong!

But I have another question.

I want to make a time binning for a period of 7 days for one year of SeaWiFS daily images , but I need them with a projection.

So, when should I map my files?
After I create the level 2, I map and then make time-binning or after I create a time-binning file?

Gust,

Map them after you make the time binned files.  You can use the smigen program to create a Standard Mapped Image out of the binned file.

Mark

Mark,

I followed as you said, I made the mapping after the time-binning processs. But there is something happening when I make the space-binning. The L2 image is Ok, but the image that results from the process of space binning has a lot of "stripes" with no data "dark". 

I am processing GAC images 4km and I am keeping the same resolution for the space binning 4km. That maybe the problem?

I think that the script is ok bacouse it is not showing any error message.

I also have tried to make the same process through the seadas display but it look the same.

Should I make a 9km space bin?

Thanks!

Gustavo Molleri

Mark,

I followed as you said, I made the mapping after the time-binning processs. But there is something happening when I make the space-binning. The L2 image is Ok, but the image that results from the process of space binning has a lot of "stripes" with no data "dark". 

I am processing GAC images 4km and I am keeping the same resolution for the space binning 4km. That maybe the problem?

I think that the script is ok bacouse it is not showing any error message.

I also have tried to make the same process through the seadas display but it look the same.

Should I make a 9km space bin?

Thanks!

Gustavo Molleri

Some stripes and dark no data areas are normal.

You may compare your image with official products
(yearly, monthly, weekly averaged SeaWiFS images):

http://oceancolor.gsfc.nasa.gov/cgi/level3.pl?DAY=20Jan2001&PER=&TYP=swchl&RRW=16

What options you used in binning, all defaults ?

Long

Long,

I saw some weekly images, but the 'stripes' doesnīt appear. That may the projection that I am using?

Here is my command line for the l2 space binning process:

l2bin, ifile=file(i), ofile=out, resolve=4, flaguse='ATMFAIL, LAND, HISATZEN, STRAYLIGHT, CLDICE, COCCOLITH, HISOLZEN, LOWLW, CHLFAIL, NAVWARN, ABSAER, MAXAERITER, ATMWARN, DARKPIXEL', l3bprod='Rrs_412,Rrs_443,Rrs_490,Rrs_510,Rrs_555,Rrs_670,Rrs_765,Rrs_865,nLw_412,nLw_443,nLw_490,nLw_510,nLw_555,nLw_670,nLw_765,nLw_865,chl_oc4,K_490, adg_412_carder,tsm_clark', noext=1  & $

Thanks

Gustavo Molleri

Gustavo,

Yes, I believe when you redisplay this binned file, map projections
tend to enlarge stripes for small regions. You may try
to select a larger area for display to see any improvement.

If possible can you send us this binned file via email to have a look ?

Long

Mark (or anyone),

I am working on the validation of MODIS products (Lnw, Rrs, K490, Chl-a), using COVE and our cruises as ground-truth data. I have concerns that the level of  MODIS data that I am currently using is not suitable for the match-up process as described in the literature (e.g.: Bailey and Werdell, 2006).

The MODIS data  I work on are L2 files, mapped on cylindrical coordinates using the standard SeaDAS map function (with the application of the OBPG standard L2flags, atmospheric correction, BRDF, etc.). I call these file L3_QC-mapped.

Are these files suitable for the match-up process? In other words, does a box of pixels, extracted  around a ground-control-point (GCP), contain the same values when it is extracted from a QC-mapped files as when extracted directly from L2 data?

According to the instructor who provided me with the code, the answer is "yes:  if I use the L3 qc-mapped files for my match-ups, I will get the same results as with the use of level2 data".

In my opinion, instead, I will have different results. In fact, the satellite only sees at 1-km resolution under the flight path, but those pixels viewed from the side are larger than 1-km. As a result, the pixels in the L2 files will represent 1x1-sq.km areas (if looking straight down) or 5x5-sq.km (if views from the side),  When mapped, the 1-km pixel take up one pixel in the mapped image, but the single l2 pixel that represented 5km will be mapped to 5 pixels of equal value in the mapped image. Therefore, if I count a  box of pixels around a given GCP, the values in the box will be different if I am using L2 or QC-mapped files.

What is the truth? Do you compare your ground values with a certain number of the image pixels, no matter what area they cover, or do you compare with mapped files, where a certain number of pixels correspond to the same number of squared kilometers?

If you can shed any light on the matter, I would be immensely grateful.

Your data match-up work is reasonable correct (MODIS L2 image data + cruise in-situ data)

Using unprojected L2 images, you could directly match-up those data. SeaDAS's Shiptrack
and Rline functions are good tools to assist users with graphic and ascii data viewing.

Regard mapped image, the direct comparison method should be still valid. As you mentioned
that 5 pixels of equal value in a mapped image will only represent an in-situ point (with lat/long)
projected on the mapped image (pixel/line).

Be careful to esitmate areas with pixel count, this may not always right. 

Long

I will try to answer you questions and clear up some misconceptions you seem to have.

1) Extracting a 5x5 pixel box from a L2 file is NOT the same as extracting a 5x5 'pixel' box
from a mapped L2 file simple because a satellite pixel is not a map pixel.

2) A satellite sensor with a 1km^2 pixel resolution at nadir will never have a pixel that is
5km^2.   Pixel 'growth' with scan angle produces wedge-like shapes, not squares.  In the case
of SeaWiFS, at the scan edges, the pixels represent ~ 3x7km.  At the edge of the SeaWiFS
GAC swath (56 degree sensor zenith, 45 degree scan angle) the pixels are ~1.5x3km
(or in that neighborhood, brain getting fuzzy with age and numbers getting jumbled...)

3) The number of mapped 'pixels' a satellite pixel will influence depends a LOT on the
map projection and the code used to do the mapping.  If care is not taken when using the
SeaDAS map function, you will not get a one-to-one pixel correspondence between
a satellite pixel and a mapped pixel - even for nadir pixels.

4) We do our validation work on the L2 files directly in satellite pixel space ( as
is described in Bailey and Werdell, 2006).  Now, this is not to say you can't do validation
on a mapped product.  If care is taken, and it is understood what the mapper is doing to
create the map from the satellite product, results should be comparable.   If you must use
a L3 product and want a more robust L3 product, use the l2bin program.  It will apply,
by default, the flags you'll want to mask (or you can specify them).  The trick then is to
decide how best to get the data out of the bin file.  SeaDAS can read them and will remap
them, or you could look into reading them directly (See the OceanColor IDL Library for
l3bin routines)

Or you could go back to the L2 file directly...

Regards,
Sean

Sean (and  Long),

Thank you so much for these clarifications, I am getting lost out here..

I already obtained the match-ups using the L3 QC-flat files, but I want to now perform the validation using the L2 files (in fact, I am not sure how the SeaDAS mapping tools worked).

I have started this new processing, but the L2 satellite image, displayed in IDL, does not overlay correctly with the continent map outline (the two layers have the same geographic limits and extent). So, I started wondering how I can be sure that I can navigate through the data correctly. If I select a location by certain coordinates (oplot, x,y), the location is mapped on the display according to the continent shapes, rather than to the satellite scene.. I have no problem visualizing the same image+coastline under SeaDAS, though. 

I am sure there is a good approach to this problem, but I do not seem to be able to find it.

Thank you for your availability in discussing this. I wish it were easier to fully describe the problem.

The L2 file is not in a regular projection, IDL's mapping expects a
regular grid.  You will need to use the navigation within the L2
file - it's not a task for the light hearted.  SeaDAS takes care of this
for you, which you've noticed as SeaDAS can correctly display the
coastline on the data. 

There are a number of posts referencing navigation of the satellite
files.  I'd say start looking there.  If you know the lat/lon of the in
situ point, you can use the msscanpixlimits program (provided with
SeaDAS) to get the pixel and line number for the corresponding
satellite pixel.  Then just extract around that pixel.  Working in
pixel/line space is a lot easier than in lat/lon space

Regards,
Sean

msscanpixlimits is a very useful program.

Now I have a question:
To practice matchups with in situ measurements following suggestions described in Bailey and Werdell (2006), I need to extract 5x5 box from native resolution L2.  With msscanpixlimits I can easily figure out the pixel/line of the center lat/lon and then sline/eline/spixl/epixl of this 5x5 box.  However, according to the scripts that Long posted at:

http://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?tid=533

One has to use pt1 and pt2 in *lon/lat* order to extract data into ASCII files when doing batch processing.  So,
1) is there any way to use sline/eline/spixl/epixl to extract L2 data in a batch mode? or,
2) is there any program that can calculate the pt1 pt2 lon/lat for this 5x5 box if I input the center lat/lon?

Thanks for help,
Haili

Haili,

Long's post uses out_ascii with the /ll_flag keyword set.
This will cause out_ascii to interpret the "region=[pt1,pt2]"
to be in lon/lat.  Without the /ll_flag, out_ascii will interpret
the "region=[pt1,pt2]" as pixel/line. 

So, say the output of msscanpixlimits is:

    sline=1104
    spixl=698

A 5x5 pixel box would be:
    lines: 1102 - 1106
    pixels: 696 - 700

For out_ascii, the input to region would be:

pt1=[700,1106] ; bottom right corner
pt2=[696,1102] ; top left corner

Now for the tricky part.  msscanpixlimits returns
pixel/line in satellite coordinates.  SeaDAS 'pixel/line'
is based on the loaded band array.  For SeaWiFS,
which is in a desceneding orbit, scanning from west to east,
the two are the same.  For Aqua, which is in an ascending
orbit and scanning from east to west, the same is not true.
SeaDAS will reorient the Aqua file so that north is at the top.
This effectively inverts the pixel and line numbers.  So if a
1km resolution Aqua file has 203 scans (10 lines per scan),
there are 2030 lines, the SeaDAS equivalent line number for
the above example would be 926 - NOT 1104.  The SeaDAS
equivalent pixel would be 656 - NOT 698 (For the 1km Aqua file,
there are 1354 pixels per scan).  Using the higher resolution
products, more pixels and lines per scan, so the values would
need to be modified accordingly.

Regards,
Sean

Hi,
How can I mapping MODIS L2 images?
Is there a scritp?
Regards,
Carol

Mapping can be done usng the GUI or on the SeaDAS command-line. For the GUI, first load a L2 product and then select Utilities->Data Manipulation->Map Projection. For the command-line use the mapimg command. For scripting help see the FAQ.