Welcome to the Earthdata Forum! Here, the scientific user community and subject matter experts from NASA Distributed Active Archive Centers (DAACs), and other contributors, discuss research needs, data, and data applications.
by zhigang » Thu Mar 08, 2018 2:51 am America/New_York
Dear,
I have always used the gpt.sh tool to generate the mapped products in Ubuntu 16.04 (64bit). Recentlly, I found a problem that several mapped products presented dark images, though most of data are normal. Further, an exception was shown here when I used the RGB image to composite by the 'MODIS RHOS LOG' option (see attachments). The L2 file can be normmaly showed in SeaDAS, but the mapped data after mosaicing in gpt.sh were problematic, their minimums seem to be infinity according to the messeage of SeaDAS. The filename of L1A_LAC is A2008209061500.L1A_LAC, L2 product was generated from l2gen with a subset option config(27.65,100.73,27.76,100.85). The file of xml was attached. I don't know why, and how to solve it? :cry:Could someone give me some suggestion?:grin:
I'm rewriting this one, due to it's complexity and I got a few things wrong, so ignore the original post which I deleted (it's not there now anyway).
The best suggestion is to consider using the OCSSW tools instead (l2bin followed by l3mapgen).
You are trying to use a log based RGB profile on bands which contain a number <= 0. Additionally, your technique of mosaic involves no quality control (valid pixel expression). This may be fine for many products as some already have a valid pixel range buried in with the l2gen configuration code and flag masks already applied.
The rhos valid value range is -0.05 to 1.00. This is problematic if you want to use the log scaling. You will either have to convert numbers <= 0 to NaN or some very small value.
For example: ... <variable> <name>rhos_645</name> <expression>(rhos_645 ≥ 0 and rhos_645 ≤ 1 ) ? rhos_645 : 0.00001</expression> </variable> ...
You can add a condition filter, but this will effect all products. For example: ... <conditions> <condition> <name>condition_1</name> <expression>rhos_645 ≥ 0.00001 and rhos_645 ≤ 1</expression> <output>false</output> </condition> </conditions> ...
But you need to be careful as the condition will affect all products. If you combine multiple products under a single condition you can lose data.
If your goal is true color imagery then perhaps do this just using the rhos_469, rhos_555 and rhos 645 bands. Make other files for other products or product groupings if a condition filter needs to be applied which could adversely affect another product. For some products you may choose to add in l2_flags in the condition. There is a Collocation tool which you could possibly use afterwards to combine files.
Also regarding the MODIS RHOS LOG rgb profile, this should ideally be revised to exclude values of zero and below. We will revise this in a future release. The file is in ~/.seadas/beam-core/auxdata/rgb_profiles if you wish to customize it yourself.
But still I highly suggest you consider OCSSW l2bin followed by l3mapgen. You will still need to be careful about putting too many products together when you bin, in this case, if a pixel of one product of the source file l2 files doesn't qualify, then all products of that pixel of the source file are not be binned. Mosaic slightly avoids this issue as it is only filtering on the condition.
by zhigang » Thu Mar 08, 2018 10:27 pm America/New_York
Yes, I appreciate for your so detailed reply. I guess that there are some negtive values (should be anomalies) in some bands of L2 data, and the inappropriate expression in xml didn't handle with it very well and affectted the all data when I map the L2 data via gpt.sh. Therefore, the composite RGB of mapped data showed a 'BLACK' view.
I will rewrite my script according to your suggestions. For the coastal and inland waters, the cloud and land mask doesn't work very well, therefore, I use the technique of mosaic via gpt.sh to map all data, and then to make quality control based on our regional method. Indeed, the tool of OCSSW are better to output l3 product with high quality, and I will try to use this workflow to produce the l3 data again, as I am not very familar with this tool.
by zhigang » Sat May 05, 2018 10:47 am America/New_York
Hi Danny,
I am trying to use l2bin and l3mapgen to map l2 products instead of gpt.sh, but I have some confusions about these. Could you give me some instructions?
Firstly, one file was generated by l2gen in Seadas, as you said, I used the l2bin tool to bin file, but it failed. Only the resolution was set to 500 m (resolve=H), others are the default parameters, the log was attached.
Otherwise, I set the flaguse to NONE, and it worked, but the L3b_DAY_OC file cannot be read by Seadas. I don't know why, could you give me suggestions?
Can you give specific details? Try to explain each step so we can replicate what you are doing. Give the exact input file name. Is your input file a single level2 file or a list of files? Tell us what you are putting in the fields "l3bprod" and "prodtype" (this really matters). What products are you trying to bin?
Yes, SeaDAS cannot display a bin file, you must subsequently create a mapped file using l3mapgen and display that file. However looking at your log file nothing really was binned.
Please post this in a new thread, this is a new topic and is unrelated to the gpt topic of this thread.
