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.
I also noticed that, the CRS and the number of pixels in the raw scene is different from the l2gen product.
Name LC08_L1TP_001071_20190725_20190801_01_T1_B1 Path /LC08_L1TP_001071_20190725_20190801_01_T1/LC08_L1TP_001071_20190725_20190801_01_T1_B1.TIF CRS EPSG:32619 - WGS 84 / UTM zone 19N - Projected Extent 491685.0000000000000000,-1875315.0000000000000000 : 721515.0000000000000000,-1641885.0000000000000000 Unit meters Width 7661 Height 7781 Data type UInt16 - Sixteen bit unsigned integer
l2gen output Name Rrs_443 CRS EPSG:4326 - WGS 84 - Geographic Extent -69.0761608864021071,-16.9621061544385441 : -66.9236402529440255,-14.8417989917037350 Unit degrees Width 7818 Height 7701 Data type Int16 - Sixteen bit signed integer
That said, my question is whether this kind of offset in geolocation is expected or not and possibly how to fix it?
For Landsat, I would suggest that you not use the land-mask that comes along with l2gen; it is just not of high enough resolution or accuracy. When I need to discriminate between land and water in Landsat 8 data, I like to compute rhos_865 from Band 5 and choose a threshold reflectance to generate a radiometric land/cloud mask.
To avoid the supplied land-mask, I pass these two options to l2gen. land=$OCDATAROOT/common/landmask_null.dat maskland=0
by armin.mehrabian » Mon Mar 30, 2020 9:44 am America/New_York
Hi Norman,
You're right, in fact I had disabled the land-mask as you pointed out. land=$OCDATAROOT/common/landmask_null.dat maskland=0
At this point I'm not sure whether this is a land-mask problem or geolocation problem. Because, not that the output L2 product looks coarse, but also seems to be slightly offset in longitude.
I have generally found the geolocation provided by the orthorectified Landsat 8 data from USGS to be pretty good. I would suspect the land mask you are using is the problem. The l2gen software does not change the original projection supplied by USGS.
There is an issue, but only for higher elevation data. The l2gen OLI reader does not set the internal record's "terrain_corrected" flag, so l2gen will apply a terrain correction to the geolocation information. Well, the data are already terrain corrected, so this introduces an error where the altitude is above zero, which is the case for the scene you're playing with.
If you have the ability to recompile the code, the fix is simple: add the following line to l1_oli.c in the "openl1_oli function (I put it just before the end of the function, but it could go anywhere):
file->terrain_corrected = 1;
If not, you'll have to wait until our next release.