l2gen and gpt processing over mid-pacific
l2gen and gpt processing over mid-pacific
I try to process data over the mid-pacific with geographical range across the 180E/180W line. For exapmple, north=22, south=12,east=-175, west=175. But the level2 product from l2gen gave extremly large x dimension. I guess l2gen thought that the longitude is from 175W to 175E. I tried to use 185 as east boudary instead, but seadas would not reconginze boundary values exceeds [-180,180]. How to handle this situation in l2gen and gpt processing?
Tags:
-
- Subject Matter Expert
- Posts: 509
- Joined: Tue Feb 09, 2021 5:42 pm America/New_York
- Been thanked: 1 time
Re: l2gen and gpt processing over mid-pacific
I tired l2gen on AQUA_MODIS.20230220T011000.L1B.hdf with north=22, south=12, east=-175, west=175..
I got the L2 file with the southwest point (176.85, 12.91) and northeast point (-175.47, 23.65). The x dimension is 0 to 682 pixels. I don't understand what you meant by "extremly large x dimension".
I got the L2 file with the southwest point (176.85, 12.91) and northeast point (-175.47, 23.65). The x dimension is 0 to 682 pixels. I don't understand what you meant by "extremly large x dimension".
Re: l2gen and gpt processing over mid-pacific
Thanks! I tried l2gen the same Aqua image and got similar results from you. The issue should come from the GPT processing. Below is the graph xml file I used for mosaic, and the output array was 38500 x 1100.
<graph id="AQUA_MODIS">
<version>1.0</version>
<node id="MosaicNode">
<operator>Mosaic</operator>
<sources>
<sourceProducts>${sourceProducts}</sourceProducts>
</sources>
<parameters>
<variables>
<variable>
<name>chlor_a</name>
<expression>chlor_a</expression>
</variable>
<variable>
<name>Kd_490</name>
<expression>Kd_490</expression>
</variable>
</variables>
<crs>GEOGCS["WGS84(DD)", DATUM["WGS84", SPHEROID["WGS84", 6378137.0, 298.257223563]],PRIMEM["Greenwich", 0.0], UNIT["degree", 0.017453292519943295],AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH]]</crs>
<resampling>Bicubic</resampling>
<westBound>175</westBound>
<northBound>22</northBound>
<eastBound>-175</eastBound>
<southBound>12</southBound>
<pixelSizeX>0.0090909</pixelSizeX>
<pixelSizeY>0.0090909</pixelSizeY>
</parameters>
</node>
</graph>
<graph id="AQUA_MODIS">
<version>1.0</version>
<node id="MosaicNode">
<operator>Mosaic</operator>
<sources>
<sourceProducts>${sourceProducts}</sourceProducts>
</sources>
<parameters>
<variables>
<variable>
<name>chlor_a</name>
<expression>chlor_a</expression>
</variable>
<variable>
<name>Kd_490</name>
<expression>Kd_490</expression>
</variable>
</variables>
<crs>GEOGCS["WGS84(DD)", DATUM["WGS84", SPHEROID["WGS84", 6378137.0, 298.257223563]],PRIMEM["Greenwich", 0.0], UNIT["degree", 0.017453292519943295],AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH]]</crs>
<resampling>Bicubic</resampling>
<westBound>175</westBound>
<northBound>22</northBound>
<eastBound>-175</eastBound>
<southBound>12</southBound>
<pixelSizeX>0.0090909</pixelSizeX>
<pixelSizeY>0.0090909</pixelSizeY>
</parameters>
</node>
</graph>
-
- Subject Matter Expert
- Posts: 509
- Joined: Tue Feb 09, 2021 5:42 pm America/New_York
- Been thanked: 1 time
Re: l2gen and gpt processing over mid-pacific
Yes, gpt seems to have an issue with the geographic area that crosses the date line. The work around is to do mosaic twice, resulting in two files, one for the west and one for the east.
The 1st time for the region west of the date line --
<westBound>175</westBound>
<eastBound>179.9</eastBound>
The 2nd time for the east part --
<westBound>-179.9</westBound>
<eastBound>-175</eastBound>
The 1st time for the region west of the date line --
<westBound>175</westBound>
<eastBound>179.9</eastBound>
The 2nd time for the east part --
<westBound>-179.9</westBound>
<eastBound>-175</eastBound>
Last edited by OB SeaDAS - xuanyang02 on Tue Mar 21, 2023 11:54 am America/New_York, edited 1 time in total.