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
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
- User Services
- Posts: 1461
- Joined: Wed Sep 18, 2019 6:15 pm America/New_York
- Been thanked: 4 times
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.
- meris_landmask.png (28.76 KiB) Not viewed yet