Geolocation issue with l2gen

Please enter here to ask a question about any NASA Science related topics!
Post Reply
armin.mehrabian
Posts: 8
Joined: Tue Feb 25, 2020 10:44 am America/New_York

Geolocation issue with l2gen

by armin.mehrabian » Thu Mar 26, 2020 9:26 am America/New_York

Hi All,

I am processing Landsat8 scenes through l2gen. When the processed scenes are overlaid over a base map, the processed scene is slightly offset in longitude.
This is the screenshot of one of the bands of the raw scene:
https://elasticbeanstalk-us-east-1-588893393439.s3.amazonaws.com/raw_scene.png

and this is the overlaid l2gen output (in red mask) over the input raw scene
https://elasticbeanstalk-us-east-1-588893393439.s3.amazonaws.com/l2gen_output.png

Another two examples:
https://elasticbeanstalk-us-east-1-588893393439.s3.amazonaws.com/Lake+Titicaca_v1.png
https://elasticbeanstalk-us-east-1-588893393439.s3.amazonaws.com/Lake+Chacas.png

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?

Thanks,
Armin

Tags:

OB WebDev - norman
Subject Matter Expert
Subject Matter Expert
Posts: 136
Joined: Tue Feb 09, 2021 8:19 am America/New_York

Geolocation issue with l2gen

by OB WebDev - norman » Fri Mar 27, 2020 12:49 pm America/New_York

Hi Armin,

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


Regards,
Norman

armin.mehrabian
Posts: 8
Joined: Tue Feb 25, 2020 10:44 am America/New_York

Geolocation issue with l2gen

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.

Thanks,
Armin

OB WebDev - norman
Subject Matter Expert
Subject Matter Expert
Posts: 136
Joined: Tue Feb 09, 2021 8:19 am America/New_York

Geolocation issue with l2gen

by OB WebDev - norman » Mon Mar 30, 2020 10:03 am America/New_York

Hi Armin,

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.

Norman

OB.DAAC - SeanBailey
User Services
User Services
Posts: 1166
Joined: Wed Sep 18, 2019 6:15 pm America/New_York

Geolocation issue with l2gen

by OB.DAAC - SeanBailey » Thu Apr 16, 2020 12:37 pm America/New_York

Armin, (and Norman),

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.

Sean

Post Reply