Earthdata Forum

Hi,

The OCSSW program lonlat2pixline gives incorrect pixel/line values for some MERIS L1B input files.

I used lonlat2pixline to first get the pixel/line values for a bounding box covering Lake Erie and then used the output to subset the MERIS L1B file to what should be Lake Erie.

lonlat2pixline /data/MERIS/FR_4th/2011/EN1_MDSI_MER_FRS_1P_20110618T161228_20110618T162208_048632_0342_20171231T234956_0100.SEN3/xfdumanifest.xml -83.683300 41.275309 -78.614971 43.006608
# 2857 4329 9138 10163
sline=9138
eline=10163
spixl=2857
epixl=4329

l1bextract_safe_nc -v --spixl=2857 --epixl=4329 --sline=9138 --eline=10163 /data/MERIS/FR_4th/2011/EN1_MDSI_MER_FRS_1P_20110618T161228_20110618T162208_048632_0342_20171231T234956_0100.SEN3 EN1_MDSI_MER_FRS_1P_20110618T161228_20110618T162208_048632_0342_20171231T234956_0100.SEN3.LE3

As you can see in the following image the resulting L1B extract file does not cover Lake Erie. In a small sample, I've noticed the error appears to occur when there's a data gap in the source L1B file . I'm running on RHEL linux VM using SeaDAS 8.4 with OCSSW tag V2023.3

Thanks,
Andrew

Andrew,
This is not a lonlat2pixline issue, but rather an issue with the MERIS file. The geolocation is not correct, possibly related to the gap you pointed out. Below are two images created from a subset of the scene you reference. The first is the M13_radiance field, the second shows the same field with a landmask applied based on the file's geolocation information. As you can see, not exactly a good fit

This is something to bring up with folks at ESA.

Sean

Thanks Sean. I will follow up with ESA.

Andrew