question on Stray light Landsat 8 data

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Nikos and GRASS users,

I would like to ask if nonetheless the effect due to "stray light" the i.landsat8.swlst code for split window is still applicable to Landsat 8 data and whether these error is specially visible on water bodies? and whether band 10 is better than band 11 in terms of correction processing for Level -1  data products?

Thanks a lot.

Kind regards,
Gabriel


 

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

NikosAlexandris
* Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:

>Dear Nikos and GRASS users,
>
>I would like to ask if nonetheless the effect due to "stray light" the
>*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>data and whether these error is specially visible on water bodies? and
>whether band 10 is better than band 11 in terms of correction processing
>for Level -1  data products?
>
>Thanks a lot.
>
>Kind regards,
>Gabriel
Dear Gabriel,

for details and references, refer to

https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/

Make sure you use the newest Level-1 Collection 1 Landsat 8 products.

I use `i.landsat8.swlst` and plan to improve it further.

However, whether to prefer a Split-Window based approach, or another
Single-Channel one, depends on what you want to do. Think of spatial
extent and coverage of various land (cover) types, temporal extent
and more.

Thermal remote sensing is hard(er) also because it's hard to get
ground-truth data sets so as to validate LST estimations.

Nikos

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Nikos,

Thanks a lot for your answer and the orientation.
The information and the link are very useful.
Kind regards,
Gabriel


On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
* Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:

>Dear Nikos and GRASS users,
>
>I would like to ask if nonetheless the effect due to "stray light" the
>*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>data and whether these error is specially visible on water bodies? and
>whether band 10 is better than band 11 in terms of correction processing
>for Level -1  data products?
>
>Thanks a lot.
>
>Kind regards,
>Gabriel

Dear Gabriel,

for details and references, refer to

https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/

Make sure you use the newest Level-1 Collection 1 Landsat 8 products.

I use `i.landsat8.swlst` and plan to improve it further.

However, whether to prefer a Split-Window based approach, or another
Single-Channel one, depends on what you want to do. Think of spatial
extent and coverage of various land (cover) types, temporal extent
and more.

Thermal remote sensing is hard(er) also because it's hard to get
ground-truth data sets so as to validate LST estimations.

Nikos

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Nikos. 
After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
However in addition my routing also has a for loop which does not work ok as well.
I would appreciate a lot of you can give it a look and tell me how to make it work...
Thanks  a lot in advance
Kind regards,
Gabriel
#####-----------------------------------------------------------------------------------------
# complete routine for intercalliration of DSMP/OLS light stable product

import grass.script as gscript
import os
import os,glob

# get working directory
print os.getcwd()

# change working directory where raster files are
os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')

# see files in directory
ls

# import all raster files to grass --- here is a kind of problem...???
for tif_file in glob.glob("*.tif"):
    new_rast = os.path.splitext(tif_file)[0]
    grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)

# get info of one of the imported raster
r.info map=F121996

# run intercalliration algorithm
i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t

# correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see.... 
g.region raster=F121996

# cerate a list of rasters in the mapset
# rastlist=grass.read_command("g.list",type="rast").split()
 rasters = grass.read_command('g.list', type='raster').splitlines()
 
# change working directory
os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
 
# save rasters in mapset to file
for raster in rasters:
    grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')

On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
Dear Nikos,

Thanks a lot for your answer and the orientation.
The information and the link are very useful.
Kind regards,
Gabriel


On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
* Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:

>Dear Nikos and GRASS users,
>
>I would like to ask if nonetheless the effect due to "stray light" the
>*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>data and whether these error is specially visible on water bodies? and
>whether band 10 is better than band 11 in terms of correction processing
>for Level -1  data products?
>
>Thanks a lot.
>
>Kind regards,
>Gabriel

Dear Gabriel,

for details and references, refer to

https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/

Make sure you use the newest Level-1 Collection 1 Landsat 8 products.

I use `i.landsat8.swlst` and plan to improve it further.

However, whether to prefer a Split-Window based approach, or another
Single-Channel one, depends on what you want to do. Think of spatial
extent and coverage of various land (cover) types, temporal extent
and more.

Thermal remote sensing is hard(er) also because it's hard to get
ground-truth data sets so as to validate LST estimations.

Nikos

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
Thanks a lot.
Gabriel  

On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
Dear Nikos. 
After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
However in addition my routing also has a for loop which does not work ok as well.
I would appreciate a lot of you can give it a look and tell me how to make it work...
Thanks  a lot in advance
Kind regards,
Gabriel
#####-----------------------------------------------------------------------------------------
# complete routine for intercalliration of DSMP/OLS light stable product

import grass.script as gscript
import os
import os,glob

# get working directory
print os.getcwd()

# change working directory where raster files are
os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')

# see files in directory
ls

# import all raster files to grass --- here is a kind of problem...???
for tif_file in glob.glob("*.tif"):
    new_rast = os.path.splitext(tif_file)[0]
    grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)

# get info of one of the imported raster
r.info map=F121996

# run intercalliration algorithm
i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t

# correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see.... 
g.region raster=F121996

# cerate a list of rasters in the mapset
# rastlist=grass.read_command("g.list",type="rast").split()
 rasters = grass.read_command('g.list', type='raster').splitlines()
 
# change working directory
os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
 
# save rasters in mapset to file
for raster in rasters:
    grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')

On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
Dear Nikos,

Thanks a lot for your answer and the orientation.
The information and the link are very useful.
Kind regards,
Gabriel


On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
* Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:

>Dear Nikos and GRASS users,
>
>I would like to ask if nonetheless the effect due to "stray light" the
>*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>data and whether these error is specially visible on water bodies? and
>whether band 10 is better than band 11 in terms of correction processing
>for Level -1  data products?
>
>Thanks a lot.
>
>Kind regards,
>Gabriel

Dear Gabriel,

for details and references, refer to

https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/

Make sure you use the newest Level-1 Collection 1 Landsat 8 products.

I use `i.landsat8.swlst` and plan to improve it further.

However, whether to prefer a Split-Window based approach, or another
Single-Channel one, depends on what you want to do. Think of spatial
extent and coverage of various land (cover) types, temporal extent
and more.

Thermal remote sensing is hard(er) also because it's hard to get
ground-truth data sets so as to validate LST estimations.

Nikos

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Hello, 
My question is how does it influence the fact that it say:
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 1 cells


image.png



while when I loaded a first file I defined a region as 
 
Capture.JPG
which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears: 

360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 1 cells 

Thanks a lot
Gabriel 




On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
Thanks a lot.
Gabriel  

On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
Dear Nikos. 
After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
However in addition my routing also has a for loop which does not work ok as well.
I would appreciate a lot of you can give it a look and tell me how to make it work...
Thanks  a lot in advance
Kind regards,
Gabriel
#####-----------------------------------------------------------------------------------------
# complete routine for intercalliration of DSMP/OLS light stable product

import grass.script as gscript
import os
import os,glob

# get working directory
print os.getcwd()

# change working directory where raster files are
os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')

# see files in directory
ls

# import all raster files to grass --- here is a kind of problem...???
for tif_file in glob.glob("*.tif"):
    new_rast = os.path.splitext(tif_file)[0]
    grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)

# get info of one of the imported raster
r.info map=F121996

# run intercalliration algorithm
i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t

# correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see.... 
g.region raster=F121996

# cerate a list of rasters in the mapset
# rastlist=grass.read_command("g.list",type="rast").split()
 rasters = grass.read_command('g.list', type='raster').splitlines()
 
# change working directory
os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
 
# save rasters in mapset to file
for raster in rasters:
    grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')

On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
Dear Nikos,

Thanks a lot for your answer and the orientation.
The information and the link are very useful.
Kind regards,
Gabriel


On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
* Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:

>Dear Nikos and GRASS users,
>
>I would like to ask if nonetheless the effect due to "stray light" the
>*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>data and whether these error is specially visible on water bodies? and
>whether band 10 is better than band 11 in terms of correction processing
>for Level -1  data products?
>
>Thanks a lot.
>
>Kind regards,
>Gabriel

Dear Gabriel,

for details and references, refer to

https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/

Make sure you use the newest Level-1 Collection 1 Landsat 8 products.

I use `i.landsat8.swlst` and plan to improve it further.

However, whether to prefer a Split-Window based approach, or another
Single-Channel one, depends on what you want to do. Think of spatial
extent and coverage of various land (cover) types, temporal extent
and more.

Thermal remote sensing is hard(er) also because it's hard to get
ground-truth data sets so as to validate LST estimations.

Nikos

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Markus Metz-3


On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>
> Hello,
> My question is how does it influence the fact that it say:
> 360 degree EW extent is exceeded by 0.999827 cells

this is caused by the truncated resolution of 0.008333333300000
with a corrected resolution of 00:00:30, the message  is

> 360 degree EW extent is exceeded by 1 cells

considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.

Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.

HTH,

Markus M

>
>

>
>
>
>
> while when I loaded a first file I defined a region as
>  
>
> which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>
> 360 degree EW extent is exceeded by 0.999827 cells
> 360 degree EW extent is exceeded by 1 cells
>
> Thanks a lot
> Gabriel
>
>
>
>
> On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>
>> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>> Thanks a lot.
>> Gabriel  
>>
>> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>>
>>> Dear Nikos.
>>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>>> However in addition my routing also has a for loop which does not work ok as well.
>>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>>> Thanks  a lot in advance
>>> Kind regards,
>>> Gabriel
>>> #####-----------------------------------------------------------------------------------------
>>> # complete routine for intercalliration of DSMP/OLS light stable product
>>>
>>> import grass.script as gscript
>>> import os
>>> import os,glob
>>>
>>> # get working directory
>>> print os.getcwd()
>>>
>>> # change working directory where raster files are
>>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>>>
>>> # see files in directory
>>> ls
>>>
>>> # import all raster files to grass --- here is a kind of problem...???
>>> for tif_file in glob.glob("*.tif"):
>>>     new_rast = os.path.splitext(tif_file)[0]
>>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>>>
>>> # get info of one of the imported raster
>>> r.info map=F121996
>>>
>>> # run intercalliration algorithm
>>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>>>
>>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>>> g.region raster=F121996
>>>
>>> # cerate a list of rasters in the mapset
>>> # rastlist=grass.read_command("g.list",type="rast").split()
>>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>>>  
>>> # change working directory
>>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>>>  
>>> # save rasters in mapset to file
>>> for raster in rasters:
>>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>>>
>>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>>>>
>>>> Dear Nikos,
>>>>
>>>> Thanks a lot for your answer and the orientation.
>>>> The information and the link are very useful.
>>>> Kind regards,
>>>> Gabriel
>>>>
>>>>
>>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>>>>>
>>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>>>>>
>>>>> >Dear Nikos and GRASS users,
>>>>> >
>>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>>>>> >data and whether these error is specially visible on water bodies? and
>>>>> >whether band 10 is better than band 11 in terms of correction processing
>>>>> >for Level -1  data products?
>>>>> >
>>>>> >Thanks a lot.
>>>>> >
>>>>> >Kind regards,
>>>>> >Gabriel
>>>>>
>>>>> Dear Gabriel,
>>>>>
>>>>> for details and references, refer to
>>>>>
>>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>>>>>
>>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>>>>>
>>>>> I use `i.landsat8.swlst` and plan to improve it further.
>>>>>
>>>>> However, whether to prefer a Split-Window based approach, or another
>>>>> Single-Channel one, depends on what you want to do. Think of spatial
>>>>> extent and coverage of various land (cover) types, temporal extent
>>>>> and more.
>>>>>
>>>>> Thermal remote sensing is hard(er) also because it's hard to get
>>>>> ground-truth data sets so as to validate LST estimations.
>>>>>
>>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Markus,

Thanks a lot for the clarification and explanation, your response was indeed helpful.

I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:

r.info map= name_of_raster_map                                       

360 degree EW extent is exceeded by 1 cells
360 degree EW extent is exceeded by 1 cells

Which, following what you said before in your response I understand makes it correct region, right?

Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?


I'm attaching the log of all the files I got from 'r.info' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and  also the min and max value of each intercallibrated raster  layer.

So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?

Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.


Thanks  a lot again for your help.
Kind regards,
Gabriel

Virus-free. www.avast.com

On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <[hidden email]> wrote:


On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>
> Hello,
> My question is how does it influence the fact that it say:
> 360 degree EW extent is exceeded by 0.999827 cells

this is caused by the truncated resolution of 0.008333333300000
with a corrected resolution of 00:00:30, the message  is

> 360 degree EW extent is exceeded by 1 cells

considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.

Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.

HTH,

Markus M

>
>

>
>
>
>
> while when I loaded a first file I defined a region as
>  
>
> which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>
> 360 degree EW extent is exceeded by 0.999827 cells
> 360 degree EW extent is exceeded by 1 cells
>
> Thanks a lot
> Gabriel
>
>
>
>
> On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>
>> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>> Thanks a lot.
>> Gabriel  
>>
>> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>>
>>> Dear Nikos.
>>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>>> However in addition my routing also has a for loop which does not work ok as well.
>>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>>> Thanks  a lot in advance
>>> Kind regards,
>>> Gabriel
>>> #####-----------------------------------------------------------------------------------------
>>> # complete routine for intercalliration of DSMP/OLS light stable product
>>>
>>> import grass.script as gscript
>>> import os
>>> import os,glob
>>>
>>> # get working directory
>>> print os.getcwd()
>>>
>>> # change working directory where raster files are
>>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>>>
>>> # see files in directory
>>> ls
>>>
>>> # import all raster files to grass --- here is a kind of problem...???
>>> for tif_file in glob.glob("*.tif"):
>>>     new_rast = os.path.splitext(tif_file)[0]
>>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>>>
>>> # get info of one of the imported raster
>>> r.info map=F121996
>>>
>>> # run intercalliration algorithm
>>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>>>
>>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>>> g.region raster=F121996
>>>
>>> # cerate a list of rasters in the mapset
>>> # rastlist=grass.read_command("g.list",type="rast").split()
>>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>>>  
>>> # change working directory
>>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>>>  
>>> # save rasters in mapset to file
>>> for raster in rasters:
>>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>>>
>>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>>>>
>>>> Dear Nikos,
>>>>
>>>> Thanks a lot for your answer and the orientation.
>>>> The information and the link are very useful.
>>>> Kind regards,
>>>> Gabriel
>>>>
>>>>
>>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>>>>>
>>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>>>>>
>>>>> >Dear Nikos and GRASS users,
>>>>> >
>>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>>>>> >data and whether these error is specially visible on water bodies? and
>>>>> >whether band 10 is better than band 11 in terms of correction processing
>>>>> >for Level -1  data products?
>>>>> >
>>>>> >Thanks a lot.
>>>>> >
>>>>> >Kind regards,
>>>>> >Gabriel
>>>>>
>>>>> Dear Gabriel,
>>>>>
>>>>> for details and references, refer to
>>>>>
>>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>>>>>
>>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>>>>>
>>>>> I use `i.landsat8.swlst` and plan to improve it further.
>>>>>
>>>>> However, whether to prefer a Split-Window based approach, or another
>>>>> Single-Channel one, depends on what you want to do. Think of spatial
>>>>> extent and coverage of various land (cover) types, temporal extent
>>>>> and more.
>>>>>
>>>>> Thermal remote sensing is hard(er) also because it's hard to get
>>>>> ground-truth data sets so as to validate LST estimations.
>>>>>
>>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user

grass_cmd_output_all.txt (247K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Markus Metz-3
Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <[hidden email]> wrote:

>
> Dear Markus,
>
> Thanks a lot for the clarification and explanation, your response was indeed helpful.
>
> I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:
>
> r.info map= name_of_raster_map                                      
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
>
> Which, following what you said before in your response I understand makes it correct region, right?

this region is correct considering the resolution with is now exactly 30 arc seconds.

this region is not correct considering that 360 degree EW extent is exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.

Markus M

>
> Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?

>
>
> I'm attaching the log of all the files I got from 'r.info' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and  also the min and max value of each intercallibrated raster  layer.
>
> So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?
>
> Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.
>
>
> Thanks  a lot again for your help.
> Kind regards,
> Gabriel
>
> Virus-free. www.avast.com
>
> On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <[hidden email]> wrote:
>>
>>
>>
>> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>> >
>> > Hello,
>> > My question is how does it influence the fact that it say:
>> > 360 degree EW extent is exceeded by 0.999827 cells
>>
>> this is caused by the truncated resolution of 0.008333333300000
>> with a corrected resolution of 00:00:30, the message  is
>>
>> > 360 degree EW extent is exceeded by 1 cells
>>
>> considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>
>> Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.
>>
>> HTH,
>>
>> Markus M
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > while when I loaded a first file I defined a region as
>> >  
>> >
>> > which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>> >
>> > 360 degree EW extent is exceeded by 0.999827 cells
>> > 360 degree EW extent is exceeded by 1 cells
>> >
>> > Thanks a lot
>> > Gabriel
>> >
>> >
>> >
>> >
>> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>> >>
>> >> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>> >> Thanks a lot.
>> >> Gabriel  
>> >>
>> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>> >>>
>> >>> Dear Nikos.
>> >>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>> >>> However in addition my routing also has a for loop which does not work ok as well.
>> >>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>> >>> Thanks  a lot in advance
>> >>> Kind regards,
>> >>> Gabriel
>> >>> #####-----------------------------------------------------------------------------------------
>> >>> # complete routine for intercalliration of DSMP/OLS light stable product
>> >>>
>> >>> import grass.script as gscript
>> >>> import os
>> >>> import os,glob
>> >>>
>> >>> # get working directory
>> >>> print os.getcwd()
>> >>>
>> >>> # change working directory where raster files are
>> >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>> >>>
>> >>> # see files in directory
>> >>> ls
>> >>>
>> >>> # import all raster files to grass --- here is a kind of problem...???
>> >>> for tif_file in glob.glob("*.tif"):
>> >>>     new_rast = os.path.splitext(tif_file)[0]
>> >>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>> >>>
>> >>> # get info of one of the imported raster
>> >>> r.info map=F121996
>> >>>
>> >>> # run intercalliration algorithm
>> >>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>> >>>
>> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>> >>> g.region raster=F121996
>> >>>
>> >>> # cerate a list of rasters in the mapset
>> >>> # rastlist=grass.read_command("g.list",type="rast").split()
>> >>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>> >>>  
>> >>> # change working directory
>> >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>> >>>  
>> >>> # save rasters in mapset to file
>> >>> for raster in rasters:
>> >>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>> >>>
>> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>> >>>>
>> >>>> Dear Nikos,
>> >>>>
>> >>>> Thanks a lot for your answer and the orientation.
>> >>>> The information and the link are very useful.
>> >>>> Kind regards,
>> >>>> Gabriel
>> >>>>
>> >>>>
>> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>> >>>>>
>> >>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>> >>>>>
>> >>>>> >Dear Nikos and GRASS users,
>> >>>>> >
>> >>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>> >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>> >>>>> >data and whether these error is specially visible on water bodies? and
>> >>>>> >whether band 10 is better than band 11 in terms of correction processing
>> >>>>> >for Level -1  data products?
>> >>>>> >
>> >>>>> >Thanks a lot.
>> >>>>> >
>> >>>>> >Kind regards,
>> >>>>> >Gabriel
>> >>>>>
>> >>>>> Dear Gabriel,
>> >>>>>
>> >>>>> for details and references, refer to
>> >>>>>
>> >>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>> >>>>>
>> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>> >>>>>
>> >>>>> I use `i.landsat8.swlst` and plan to improve it further.
>> >>>>>
>> >>>>> However, whether to prefer a Split-Window based approach, or another
>> >>>>> Single-Channel one, depends on what you want to do. Think of spatial
>> >>>>> extent and coverage of various land (cover) types, temporal extent
>> >>>>> and more.
>> >>>>>
>> >>>>> Thermal remote sensing is hard(er) also because it's hard to get
>> >>>>> ground-truth data sets so as to validate LST estimations.
>> >>>>>
>> >>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Markus,
Thanks a lot for your response and explanation.  
Changing the region to w=179:59:45W e=180:00:15E, am I not only avoiding the warning, but also changing the layers to be physically correct, right?

Thanks again for your help.
regards,
Gabriel
 

On Tue, Aug 20, 2019 at 4:24 PM Markus Metz <[hidden email]> wrote:
Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <[hidden email]> wrote:

>
> Dear Markus,
>
> Thanks a lot for the clarification and explanation, your response was indeed helpful.
>
> I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:
>
> r.info map= name_of_raster_map                                      
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
>
> Which, following what you said before in your response I understand makes it correct region, right?

this region is correct considering the resolution with is now exactly 30 arc seconds.

this region is not correct considering that 360 degree EW extent is exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.

Markus M

>
> Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?

>
>
> I'm attaching the log of all the files I got from 'r.info' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and  also the min and max value of each intercallibrated raster  layer.
>
> So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?
>
> Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.
>
>
> Thanks  a lot again for your help.
> Kind regards,
> Gabriel
>
> Virus-free. www.avast.com
>
> On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <[hidden email]> wrote:
>>
>>
>>
>> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>> >
>> > Hello,
>> > My question is how does it influence the fact that it say:
>> > 360 degree EW extent is exceeded by 0.999827 cells
>>
>> this is caused by the truncated resolution of 0.008333333300000
>> with a corrected resolution of 00:00:30, the message  is
>>
>> > 360 degree EW extent is exceeded by 1 cells
>>
>> considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>
>> Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.
>>
>> HTH,
>>
>> Markus M
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > while when I loaded a first file I defined a region as
>> >  
>> >
>> > which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>> >
>> > 360 degree EW extent is exceeded by 0.999827 cells
>> > 360 degree EW extent is exceeded by 1 cells
>> >
>> > Thanks a lot
>> > Gabriel
>> >
>> >
>> >
>> >
>> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>> >>
>> >> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>> >> Thanks a lot.
>> >> Gabriel  
>> >>
>> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>> >>>
>> >>> Dear Nikos.
>> >>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>> >>> However in addition my routing also has a for loop which does not work ok as well.
>> >>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>> >>> Thanks  a lot in advance
>> >>> Kind regards,
>> >>> Gabriel
>> >>> #####-----------------------------------------------------------------------------------------
>> >>> # complete routine for intercalliration of DSMP/OLS light stable product
>> >>>
>> >>> import grass.script as gscript
>> >>> import os
>> >>> import os,glob
>> >>>
>> >>> # get working directory
>> >>> print os.getcwd()
>> >>>
>> >>> # change working directory where raster files are
>> >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>> >>>
>> >>> # see files in directory
>> >>> ls
>> >>>
>> >>> # import all raster files to grass --- here is a kind of problem...???
>> >>> for tif_file in glob.glob("*.tif"):
>> >>>     new_rast = os.path.splitext(tif_file)[0]
>> >>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>> >>>
>> >>> # get info of one of the imported raster
>> >>> r.info map=F121996
>> >>>
>> >>> # run intercalliration algorithm
>> >>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>> >>>
>> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>> >>> g.region raster=F121996
>> >>>
>> >>> # cerate a list of rasters in the mapset
>> >>> # rastlist=grass.read_command("g.list",type="rast").split()
>> >>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>> >>>  
>> >>> # change working directory
>> >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>> >>>  
>> >>> # save rasters in mapset to file
>> >>> for raster in rasters:
>> >>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>> >>>
>> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>> >>>>
>> >>>> Dear Nikos,
>> >>>>
>> >>>> Thanks a lot for your answer and the orientation.
>> >>>> The information and the link are very useful.
>> >>>> Kind regards,
>> >>>> Gabriel
>> >>>>
>> >>>>
>> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>> >>>>>
>> >>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>> >>>>>
>> >>>>> >Dear Nikos and GRASS users,
>> >>>>> >
>> >>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>> >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>> >>>>> >data and whether these error is specially visible on water bodies? and
>> >>>>> >whether band 10 is better than band 11 in terms of correction processing
>> >>>>> >for Level -1  data products?
>> >>>>> >
>> >>>>> >Thanks a lot.
>> >>>>> >
>> >>>>> >Kind regards,
>> >>>>> >Gabriel
>> >>>>>
>> >>>>> Dear Gabriel,
>> >>>>>
>> >>>>> for details and references, refer to
>> >>>>>
>> >>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>> >>>>>
>> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>> >>>>>
>> >>>>> I use `i.landsat8.swlst` and plan to improve it further.
>> >>>>>
>> >>>>> However, whether to prefer a Split-Window based approach, or another
>> >>>>> Single-Channel one, depends on what you want to do. Think of spatial
>> >>>>> extent and coverage of various land (cover) types, temporal extent
>> >>>>> and more.
>> >>>>>
>> >>>>> Thermal remote sensing is hard(er) also because it's hard to get
>> >>>>> ground-truth data sets so as to validate LST estimations.
>> >>>>>
>> >>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Markus,
So I run the command g.region w=179:59:45W e=180:00:15E

Now my log now before and after the command g.region w=179:59:45W e=180:00:15E is as follows:

360 degree EW extent is exceeded by 1 cells
360 degree EW extent is exceeded by 1 cells
(Tue Aug 20 16:41:45 2019) Command finished (0 sec)                            
(Tue Aug 20 16:43:47 2019)                                                      
g.region w=179:59:45W e=180:00:15E                                              
360 degree EW extent is exceeded by 1.99983 cells
360 degree EW extent is exceeded by 1 cells
(Tue Aug 20 16:43:48 2019) Command finished (0 sec)                            
(Tue Aug 20 16:44:18 2019)                                                      
g.region -p                                                                    
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      75:00:15N
south:      65:00:15S
west:       179:59:45W
east:       180:00:15E
nsres:      0:00:30
ewres:      0:00:30
rows:       16801
cols:       43200
cells:      725803200
360 degree EW extent is exceeded by 1.99983 cells
(Tue Aug 20 16:44:18 2019) Command finished (0 sec)    

Now appears to say that is exceeded by 1.99983 cells.... why could this be happening?
Thanks a lot 

Regards
Gabriel                         












On Tue, Aug 20, 2019 at 4:33 PM Gabriel Cotlier <[hidden email]> wrote:
Dear Markus,
Thanks a lot for your response and explanation.  
Changing the region to w=179:59:45W e=180:00:15E, am I not only avoiding the warning, but also changing the layers to be physically correct, right?

Thanks again for your help.
regards,
Gabriel
 

On Tue, Aug 20, 2019 at 4:24 PM Markus Metz <[hidden email]> wrote:
Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <[hidden email]> wrote:

>
> Dear Markus,
>
> Thanks a lot for the clarification and explanation, your response was indeed helpful.
>
> I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:
>
> r.info map= name_of_raster_map                                      
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
>
> Which, following what you said before in your response I understand makes it correct region, right?

this region is correct considering the resolution with is now exactly 30 arc seconds.

this region is not correct considering that 360 degree EW extent is exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.

Markus M

>
> Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?

>
>
> I'm attaching the log of all the files I got from 'r.info' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and  also the min and max value of each intercallibrated raster  layer.
>
> So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?
>
> Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.
>
>
> Thanks  a lot again for your help.
> Kind regards,
> Gabriel
>
> Virus-free. www.avast.com
>
> On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <[hidden email]> wrote:
>>
>>
>>
>> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>> >
>> > Hello,
>> > My question is how does it influence the fact that it say:
>> > 360 degree EW extent is exceeded by 0.999827 cells
>>
>> this is caused by the truncated resolution of 0.008333333300000
>> with a corrected resolution of 00:00:30, the message  is
>>
>> > 360 degree EW extent is exceeded by 1 cells
>>
>> considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>
>> Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.
>>
>> HTH,
>>
>> Markus M
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > while when I loaded a first file I defined a region as
>> >  
>> >
>> > which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>> >
>> > 360 degree EW extent is exceeded by 0.999827 cells
>> > 360 degree EW extent is exceeded by 1 cells
>> >
>> > Thanks a lot
>> > Gabriel
>> >
>> >
>> >
>> >
>> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>> >>
>> >> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>> >> Thanks a lot.
>> >> Gabriel  
>> >>
>> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>> >>>
>> >>> Dear Nikos.
>> >>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>> >>> However in addition my routing also has a for loop which does not work ok as well.
>> >>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>> >>> Thanks  a lot in advance
>> >>> Kind regards,
>> >>> Gabriel
>> >>> #####-----------------------------------------------------------------------------------------
>> >>> # complete routine for intercalliration of DSMP/OLS light stable product
>> >>>
>> >>> import grass.script as gscript
>> >>> import os
>> >>> import os,glob
>> >>>
>> >>> # get working directory
>> >>> print os.getcwd()
>> >>>
>> >>> # change working directory where raster files are
>> >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>> >>>
>> >>> # see files in directory
>> >>> ls
>> >>>
>> >>> # import all raster files to grass --- here is a kind of problem...???
>> >>> for tif_file in glob.glob("*.tif"):
>> >>>     new_rast = os.path.splitext(tif_file)[0]
>> >>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>> >>>
>> >>> # get info of one of the imported raster
>> >>> r.info map=F121996
>> >>>
>> >>> # run intercalliration algorithm
>> >>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>> >>>
>> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>> >>> g.region raster=F121996
>> >>>
>> >>> # cerate a list of rasters in the mapset
>> >>> # rastlist=grass.read_command("g.list",type="rast").split()
>> >>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>> >>>  
>> >>> # change working directory
>> >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>> >>>  
>> >>> # save rasters in mapset to file
>> >>> for raster in rasters:
>> >>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>> >>>
>> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>> >>>>
>> >>>> Dear Nikos,
>> >>>>
>> >>>> Thanks a lot for your answer and the orientation.
>> >>>> The information and the link are very useful.
>> >>>> Kind regards,
>> >>>> Gabriel
>> >>>>
>> >>>>
>> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>> >>>>>
>> >>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>> >>>>>
>> >>>>> >Dear Nikos and GRASS users,
>> >>>>> >
>> >>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>> >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>> >>>>> >data and whether these error is specially visible on water bodies? and
>> >>>>> >whether band 10 is better than band 11 in terms of correction processing
>> >>>>> >for Level -1  data products?
>> >>>>> >
>> >>>>> >Thanks a lot.
>> >>>>> >
>> >>>>> >Kind regards,
>> >>>>> >Gabriel
>> >>>>>
>> >>>>> Dear Gabriel,
>> >>>>>
>> >>>>> for details and references, refer to
>> >>>>>
>> >>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>> >>>>>
>> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>> >>>>>
>> >>>>> I use `i.landsat8.swlst` and plan to improve it further.
>> >>>>>
>> >>>>> However, whether to prefer a Split-Window based approach, or another
>> >>>>> Single-Channel one, depends on what you want to do. Think of spatial
>> >>>>> extent and coverage of various land (cover) types, temporal extent
>> >>>>> and more.
>> >>>>>
>> >>>>> Thermal remote sensing is hard(er) also because it's hard to get
>> >>>>> ground-truth data sets so as to validate LST estimations.
>> >>>>>
>> >>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Markus Metz-3
Dear Gabriel,

On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <[hidden email]> wrote:

>
> Dear Markus,
> So I run the command g.region w=179:59:45W e=180:00:15E
>
> Now my log now before and after the command g.region w=179:59:45W e=180:00:15E is as follows:
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:41:45 2019) Command finished (0 sec)                            
> (Tue Aug 20 16:43:47 2019)                                                      
> g.region w=179:59:45W e=180:00:15E                                              
> 360 degree EW extent is exceeded by 1.99983 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:43:48 2019) Command finished (0 sec)                            
> (Tue Aug 20 16:44:18 2019)                                                      
> g.region -p                                                                    
> projection: 3 (Latitude-Longitude)
> zone:       0
> datum:      wgs84
> ellipsoid:  wgs84
> north:      75:00:15N
> south:      65:00:15S
> west:       179:59:45W
> east:       180:00:15E
> nsres:      0:00:30
> ewres:      0:00:30
> rows:       16801
> cols:       43200
> cells:      725803200
> 360 degree EW extent is exceeded by 1.99983 cells
> (Tue Aug 20 16:44:18 2019) Command finished (0 sec)    

With GRASS 7.6, I can not reproduce this message.
g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30

gives me
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      75:00:15N
south:      65:00:15S
west:       179:59:45W
east:       180:00:15E
nsres:      0:00:30
ewres:      0:00:30
rows:       16801
cols:       43200
cells:      725803200

without any messages that 360 degree EW extent is exceeded. Which GASS version are you using? I tested with GRASS 7.6 and GRASS 7.9.

Markus M

>
> Now appears to say that is exceeded by 1.99983 cells.... why could this be happening?

> Thanks a lot
>
> Regards
> Gabriel                        
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 20, 2019 at 4:33 PM Gabriel Cotlier <[hidden email]> wrote:
>>
>> Dear Markus,
>> Thanks a lot for your response and explanation.  
>> Changing the region to w=179:59:45W e=180:00:15E, am I not only avoiding the warning, but also changing the layers to be physically correct, right?
>>
>> Thanks again for your help.
>> regards,
>> Gabriel
>>  
>>
>> On Tue, Aug 20, 2019 at 4:24 PM Markus Metz <[hidden email]> wrote:
>>>
>>> Dear Gabriel,
>>>
>>> On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >
>>> > Dear Markus,
>>> >
>>> > Thanks a lot for the clarification and explanation, your response was indeed helpful.
>>> >
>>> > I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:
>>> >
>>> > r.info map= name_of_raster_map                                      
>>> >
>>> > 360 degree EW extent is exceeded by 1 cells
>>> > 360 degree EW extent is exceeded by 1 cells
>>> >
>>> > Which, following what you said before in your response I understand makes it correct region, right?
>>>
>>> this region is correct considering the resolution with is now exactly 30 arc seconds.
>>>
>>> this region is not correct considering that 360 degree EW extent is exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>>
>>> Markus M
>>>
>>> >
>>> > Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?
>>> >
>>> >
>>> > I'm attaching the log of all the files I got from 'r.info' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and  also the min and max value of each intercallibrated raster  layer.
>>> >
>>> > So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?
>>> >
>>> > Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.
>>> >
>>> >
>>> > Thanks  a lot again for your help.
>>> > Kind regards,
>>> > Gabriel
>>> >
>>> > Virus-free. www.avast.com
>>> >
>>> > On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <[hidden email]> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > My question is how does it influence the fact that it say:
>>> >> > 360 degree EW extent is exceeded by 0.999827 cells
>>> >>
>>> >> this is caused by the truncated resolution of 0.008333333300000
>>> >> with a corrected resolution of 00:00:30, the message  is
>>> >>
>>> >> > 360 degree EW extent is exceeded by 1 cells
>>> >>
>>> >> considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>> >>
>>> >> Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.
>>> >>
>>> >> HTH,
>>> >>
>>> >> Markus M
>>> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > while when I loaded a first file I defined a region as
>>> >> >  
>>> >> >
>>> >> > which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>>> >> >
>>> >> > 360 degree EW extent is exceeded by 0.999827 cells
>>> >> > 360 degree EW extent is exceeded by 1 cells
>>> >> >
>>> >> > Thanks a lot
>>> >> > Gabriel
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>
>>> >> >> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>>> >> >> Thanks a lot.
>>> >> >> Gabriel  
>>> >> >>
>>> >> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>>
>>> >> >>> Dear Nikos.
>>> >> >>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>>> >> >>> However in addition my routing also has a for loop which does not work ok as well.
>>> >> >>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>>> >> >>> Thanks  a lot in advance
>>> >> >>> Kind regards,
>>> >> >>> Gabriel
>>> >> >>> #####-----------------------------------------------------------------------------------------
>>> >> >>> # complete routine for intercalliration of DSMP/OLS light stable product
>>> >> >>>
>>> >> >>> import grass.script as gscript
>>> >> >>> import os
>>> >> >>> import os,glob
>>> >> >>>
>>> >> >>> # get working directory
>>> >> >>> print os.getcwd()
>>> >> >>>
>>> >> >>> # change working directory where raster files are
>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>>> >> >>>
>>> >> >>> # see files in directory
>>> >> >>> ls
>>> >> >>>
>>> >> >>> # import all raster files to grass --- here is a kind of problem...???
>>> >> >>> for tif_file in glob.glob("*.tif"):
>>> >> >>>     new_rast = os.path.splitext(tif_file)[0]
>>> >> >>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>>> >> >>>
>>> >> >>> # get info of one of the imported raster
>>> >> >>> r.info map=F121996
>>> >> >>>
>>> >> >>> # run intercalliration algorithm
>>> >> >>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>>> >> >>>
>>> >> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>>> >> >>> g.region raster=F121996
>>> >> >>>
>>> >> >>> # cerate a list of rasters in the mapset
>>> >> >>> # rastlist=grass.read_command("g.list",type="rast").split()
>>> >> >>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>>> >> >>>  
>>> >> >>> # change working directory
>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>>> >> >>>  
>>> >> >>> # save rasters in mapset to file
>>> >> >>> for raster in rasters:
>>> >> >>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>>> >> >>>
>>> >> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>>>
>>> >> >>>> Dear Nikos,
>>> >> >>>>
>>> >> >>>> Thanks a lot for your answer and the orientation.
>>> >> >>>> The information and the link are very useful.
>>> >> >>>> Kind regards,
>>> >> >>>> Gabriel
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>>> >> >>>>>
>>> >> >>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>>> >> >>>>>
>>> >> >>>>> >Dear Nikos and GRASS users,
>>> >> >>>>> >
>>> >> >>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>>> >> >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>>> >> >>>>> >data and whether these error is specially visible on water bodies? and
>>> >> >>>>> >whether band 10 is better than band 11 in terms of correction processing
>>> >> >>>>> >for Level -1  data products?
>>> >> >>>>> >
>>> >> >>>>> >Thanks a lot.
>>> >> >>>>> >
>>> >> >>>>> >Kind regards,
>>> >> >>>>> >Gabriel
>>> >> >>>>>
>>> >> >>>>> Dear Gabriel,
>>> >> >>>>>
>>> >> >>>>> for details and references, refer to
>>> >> >>>>>
>>> >> >>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>>> >> >>>>>
>>> >> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>>> >> >>>>>
>>> >> >>>>> I use `i.landsat8.swlst` and plan to improve it further.
>>> >> >>>>>
>>> >> >>>>> However, whether to prefer a Split-Window based approach, or another
>>> >> >>>>> Single-Channel one, depends on what you want to do. Think of spatial
>>> >> >>>>> extent and coverage of various land (cover) types, temporal extent
>>> >> >>>>> and more.
>>> >> >>>>>
>>> >> >>>>> Thermal remote sensing is hard(er) also because it's hard to get
>>> >> >>>>> ground-truth data sets so as to validate LST estimations.
>>> >> >>>>>
>>> >> >>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Markus,
My grass version is : GRASS GIS 7.6.1 

On Tue, Aug 20, 2019 at 5:13 PM Markus Metz <[hidden email]> wrote:
Dear Gabriel,

On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <[hidden email]> wrote:

>
> Dear Markus,
> So I run the command g.region w=179:59:45W e=180:00:15E
>
> Now my log now before and after the command g.region w=179:59:45W e=180:00:15E is as follows:
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:41:45 2019) Command finished (0 sec)                            
> (Tue Aug 20 16:43:47 2019)                                                      
> g.region w=179:59:45W e=180:00:15E                                              
> 360 degree EW extent is exceeded by 1.99983 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:43:48 2019) Command finished (0 sec)                            
> (Tue Aug 20 16:44:18 2019)                                                      
> g.region -p                                                                    
> projection: 3 (Latitude-Longitude)
> zone:       0
> datum:      wgs84
> ellipsoid:  wgs84
> north:      75:00:15N
> south:      65:00:15S
> west:       179:59:45W
> east:       180:00:15E
> nsres:      0:00:30
> ewres:      0:00:30
> rows:       16801
> cols:       43200
> cells:      725803200
> 360 degree EW extent is exceeded by 1.99983 cells
> (Tue Aug 20 16:44:18 2019) Command finished (0 sec)    

With GRASS 7.6, I can not reproduce this message.
g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30

gives me
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      75:00:15N
south:      65:00:15S
west:       179:59:45W
east:       180:00:15E
nsres:      0:00:30
ewres:      0:00:30
rows:       16801
cols:       43200
cells:      725803200

without any messages that 360 degree EW extent is exceeded. Which GASS version are you using? I tested with GRASS 7.6 and GRASS 7.9.

Markus M

>
> Now appears to say that is exceeded by 1.99983 cells.... why could this be happening?

> Thanks a lot
>
> Regards
> Gabriel                        
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 20, 2019 at 4:33 PM Gabriel Cotlier <[hidden email]> wrote:
>>
>> Dear Markus,
>> Thanks a lot for your response and explanation.  
>> Changing the region to w=179:59:45W e=180:00:15E, am I not only avoiding the warning, but also changing the layers to be physically correct, right?
>>
>> Thanks again for your help.
>> regards,
>> Gabriel
>>  
>>
>> On Tue, Aug 20, 2019 at 4:24 PM Markus Metz <[hidden email]> wrote:
>>>
>>> Dear Gabriel,
>>>
>>> On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >
>>> > Dear Markus,
>>> >
>>> > Thanks a lot for the clarification and explanation, your response was indeed helpful.
>>> >
>>> > I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:
>>> >
>>> > r.info map= name_of_raster_map                                      
>>> >
>>> > 360 degree EW extent is exceeded by 1 cells
>>> > 360 degree EW extent is exceeded by 1 cells
>>> >
>>> > Which, following what you said before in your response I understand makes it correct region, right?
>>>
>>> this region is correct considering the resolution with is now exactly 30 arc seconds.
>>>
>>> this region is not correct considering that 360 degree EW extent is exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>>
>>> Markus M
>>>
>>> >
>>> > Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?
>>> >
>>> >
>>> > I'm attaching the log of all the files I got from 'r.info' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and  also the min and max value of each intercallibrated raster  layer.
>>> >
>>> > So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?
>>> >
>>> > Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.
>>> >
>>> >
>>> > Thanks  a lot again for your help.
>>> > Kind regards,
>>> > Gabriel
>>> >
>>> > Virus-free. www.avast.com
>>> >
>>> > On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <[hidden email]> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > My question is how does it influence the fact that it say:
>>> >> > 360 degree EW extent is exceeded by 0.999827 cells
>>> >>
>>> >> this is caused by the truncated resolution of 0.008333333300000
>>> >> with a corrected resolution of 00:00:30, the message  is
>>> >>
>>> >> > 360 degree EW extent is exceeded by 1 cells
>>> >>
>>> >> considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>> >>
>>> >> Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.
>>> >>
>>> >> HTH,
>>> >>
>>> >> Markus M
>>> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > while when I loaded a first file I defined a region as
>>> >> >  
>>> >> >
>>> >> > which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>>> >> >
>>> >> > 360 degree EW extent is exceeded by 0.999827 cells
>>> >> > 360 degree EW extent is exceeded by 1 cells
>>> >> >
>>> >> > Thanks a lot
>>> >> > Gabriel
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>
>>> >> >> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>>> >> >> Thanks a lot.
>>> >> >> Gabriel  
>>> >> >>
>>> >> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>>
>>> >> >>> Dear Nikos.
>>> >> >>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>>> >> >>> However in addition my routing also has a for loop which does not work ok as well.
>>> >> >>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>>> >> >>> Thanks  a lot in advance
>>> >> >>> Kind regards,
>>> >> >>> Gabriel
>>> >> >>> #####-----------------------------------------------------------------------------------------
>>> >> >>> # complete routine for intercalliration of DSMP/OLS light stable product
>>> >> >>>
>>> >> >>> import grass.script as gscript
>>> >> >>> import os
>>> >> >>> import os,glob
>>> >> >>>
>>> >> >>> # get working directory
>>> >> >>> print os.getcwd()
>>> >> >>>
>>> >> >>> # change working directory where raster files are
>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>>> >> >>>
>>> >> >>> # see files in directory
>>> >> >>> ls
>>> >> >>>
>>> >> >>> # import all raster files to grass --- here is a kind of problem...???
>>> >> >>> for tif_file in glob.glob("*.tif"):
>>> >> >>>     new_rast = os.path.splitext(tif_file)[0]
>>> >> >>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>>> >> >>>
>>> >> >>> # get info of one of the imported raster
>>> >> >>> r.info map=F121996
>>> >> >>>
>>> >> >>> # run intercalliration algorithm
>>> >> >>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>>> >> >>>
>>> >> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>>> >> >>> g.region raster=F121996
>>> >> >>>
>>> >> >>> # cerate a list of rasters in the mapset
>>> >> >>> # rastlist=grass.read_command("g.list",type="rast").split()
>>> >> >>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>>> >> >>>  
>>> >> >>> # change working directory
>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>>> >> >>>  
>>> >> >>> # save rasters in mapset to file
>>> >> >>> for raster in rasters:
>>> >> >>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>>> >> >>>
>>> >> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>>>
>>> >> >>>> Dear Nikos,
>>> >> >>>>
>>> >> >>>> Thanks a lot for your answer and the orientation.
>>> >> >>>> The information and the link are very useful.
>>> >> >>>> Kind regards,
>>> >> >>>> Gabriel
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>>> >> >>>>>
>>> >> >>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>>> >> >>>>>
>>> >> >>>>> >Dear Nikos and GRASS users,
>>> >> >>>>> >
>>> >> >>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>>> >> >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>>> >> >>>>> >data and whether these error is specially visible on water bodies? and
>>> >> >>>>> >whether band 10 is better than band 11 in terms of correction processing
>>> >> >>>>> >for Level -1  data products?
>>> >> >>>>> >
>>> >> >>>>> >Thanks a lot.
>>> >> >>>>> >
>>> >> >>>>> >Kind regards,
>>> >> >>>>> >Gabriel
>>> >> >>>>>
>>> >> >>>>> Dear Gabriel,
>>> >> >>>>>
>>> >> >>>>> for details and references, refer to
>>> >> >>>>>
>>> >> >>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>>> >> >>>>>
>>> >> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>>> >> >>>>>
>>> >> >>>>> I use `i.landsat8.swlst` and plan to improve it further.
>>> >> >>>>>
>>> >> >>>>> However, whether to prefer a Split-Window based approach, or another
>>> >> >>>>> Single-Channel one, depends on what you want to do. Think of spatial
>>> >> >>>>> extent and coverage of various land (cover) types, temporal extent
>>> >> >>>>> and more.
>>> >> >>>>>
>>> >> >>>>> Thermal remote sensing is hard(er) also because it's hard to get
>>> >> >>>>> ground-truth data sets so as to validate LST estimations.
>>> >> >>>>>
>>> >> >>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Dear Markus,
My message to your code: g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30 is in the picture bellow:


image.png

On Tue, Aug 20, 2019 at 5:34 PM Gabriel Cotlier <[hidden email]> wrote:
Dear Markus,
My grass version is : GRASS GIS 7.6.1 

On Tue, Aug 20, 2019 at 5:13 PM Markus Metz <[hidden email]> wrote:
Dear Gabriel,

On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <[hidden email]> wrote:

>
> Dear Markus,
> So I run the command g.region w=179:59:45W e=180:00:15E
>
> Now my log now before and after the command g.region w=179:59:45W e=180:00:15E is as follows:
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:41:45 2019) Command finished (0 sec)                            
> (Tue Aug 20 16:43:47 2019)                                                      
> g.region w=179:59:45W e=180:00:15E                                              
> 360 degree EW extent is exceeded by 1.99983 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:43:48 2019) Command finished (0 sec)                            
> (Tue Aug 20 16:44:18 2019)                                                      
> g.region -p                                                                    
> projection: 3 (Latitude-Longitude)
> zone:       0
> datum:      wgs84
> ellipsoid:  wgs84
> north:      75:00:15N
> south:      65:00:15S
> west:       179:59:45W
> east:       180:00:15E
> nsres:      0:00:30
> ewres:      0:00:30
> rows:       16801
> cols:       43200
> cells:      725803200
> 360 degree EW extent is exceeded by 1.99983 cells
> (Tue Aug 20 16:44:18 2019) Command finished (0 sec)    

With GRASS 7.6, I can not reproduce this message.
g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30

gives me
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      75:00:15N
south:      65:00:15S
west:       179:59:45W
east:       180:00:15E
nsres:      0:00:30
ewres:      0:00:30
rows:       16801
cols:       43200
cells:      725803200

without any messages that 360 degree EW extent is exceeded. Which GASS version are you using? I tested with GRASS 7.6 and GRASS 7.9.

Markus M

>
> Now appears to say that is exceeded by 1.99983 cells.... why could this be happening?

> Thanks a lot
>
> Regards
> Gabriel                        
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 20, 2019 at 4:33 PM Gabriel Cotlier <[hidden email]> wrote:
>>
>> Dear Markus,
>> Thanks a lot for your response and explanation.  
>> Changing the region to w=179:59:45W e=180:00:15E, am I not only avoiding the warning, but also changing the layers to be physically correct, right?
>>
>> Thanks again for your help.
>> regards,
>> Gabriel
>>  
>>
>> On Tue, Aug 20, 2019 at 4:24 PM Markus Metz <[hidden email]> wrote:
>>>
>>> Dear Gabriel,
>>>
>>> On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >
>>> > Dear Markus,
>>> >
>>> > Thanks a lot for the clarification and explanation, your response was indeed helpful.
>>> >
>>> > I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:
>>> >
>>> > r.info map= name_of_raster_map                                      
>>> >
>>> > 360 degree EW extent is exceeded by 1 cells
>>> > 360 degree EW extent is exceeded by 1 cells
>>> >
>>> > Which, following what you said before in your response I understand makes it correct region, right?
>>>
>>> this region is correct considering the resolution with is now exactly 30 arc seconds.
>>>
>>> this region is not correct considering that 360 degree EW extent is exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>>
>>> Markus M
>>>
>>> >
>>> > Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?
>>> >
>>> >
>>> > I'm attaching the log of all the files I got from 'r.info' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and  also the min and max value of each intercallibrated raster  layer.
>>> >
>>> > So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?
>>> >
>>> > Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.
>>> >
>>> >
>>> > Thanks  a lot again for your help.
>>> > Kind regards,
>>> > Gabriel
>>> >
>>> > Virus-free. www.avast.com
>>> >
>>> > On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <[hidden email]> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > My question is how does it influence the fact that it say:
>>> >> > 360 degree EW extent is exceeded by 0.999827 cells
>>> >>
>>> >> this is caused by the truncated resolution of 0.008333333300000
>>> >> with a corrected resolution of 00:00:30, the message  is
>>> >>
>>> >> > 360 degree EW extent is exceeded by 1 cells
>>> >>
>>> >> considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>> >>
>>> >> Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.
>>> >>
>>> >> HTH,
>>> >>
>>> >> Markus M
>>> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > while when I loaded a first file I defined a region as
>>> >> >  
>>> >> >
>>> >> > which is exactly I suppose the correct region for the DMSP data.... then after loading the  other layers it appears:
>>> >> >
>>> >> > 360 degree EW extent is exceeded by 0.999827 cells
>>> >> > 360 degree EW extent is exceeded by 1 cells
>>> >> >
>>> >> > Thanks a lot
>>> >> > Gabriel
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>
>>> >> >> Hello, another question, regarding  i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient  way to install   i.nightlights.intercalibration in python using Spyder?
>>> >> >> Thanks a lot.
>>> >> >> Gabriel  
>>> >> >>
>>> >> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>>
>>> >> >>> Dear Nikos.
>>> >> >>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.
>>> >> >>> However in addition my routing also has a for loop which does not work ok as well.
>>> >> >>> I would appreciate a lot of you can give it a look and tell me how to make it work...
>>> >> >>> Thanks  a lot in advance
>>> >> >>> Kind regards,
>>> >> >>> Gabriel
>>> >> >>> #####-----------------------------------------------------------------------------------------
>>> >> >>> # complete routine for intercalliration of DSMP/OLS light stable product
>>> >> >>>
>>> >> >>> import grass.script as gscript
>>> >> >>> import os
>>> >> >>> import os,glob
>>> >> >>>
>>> >> >>> # get working directory
>>> >> >>> print os.getcwd()
>>> >> >>>
>>> >> >>> # change working directory where raster files are
>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>>> >> >>>
>>> >> >>> # see files in directory
>>> >> >>> ls
>>> >> >>>
>>> >> >>> # import all raster files to grass --- here is a kind of problem...???
>>> >> >>> for tif_file in glob.glob("*.tif"):
>>> >> >>>     new_rast = os.path.splitext(tif_file)[0]
>>> >> >>>     grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)
>>> >> >>>
>>> >> >>> # get info of one of the imported raster
>>> >> >>> r.info map=F121996
>>> >> >>>
>>> >> >>> # run intercalliration algorithm
>>> >> >>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t
>>> >> >>>
>>> >> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....
>>> >> >>> g.region raster=F121996
>>> >> >>>
>>> >> >>> # cerate a list of rasters in the mapset
>>> >> >>> # rastlist=grass.read_command("g.list",type="rast").split()
>>> >> >>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>>> >> >>>  
>>> >> >>> # change working directory
>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>>> >> >>>  
>>> >> >>> # save rasters in mapset to file
>>> >> >>> for raster in rasters:
>>> >> >>>     grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')
>>> >> >>>
>>> >> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <[hidden email]> wrote:
>>> >> >>>>
>>> >> >>>> Dear Nikos,
>>> >> >>>>
>>> >> >>>> Thanks a lot for your answer and the orientation.
>>> >> >>>> The information and the link are very useful.
>>> >> >>>> Kind regards,
>>> >> >>>> Gabriel
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <[hidden email]> wrote:
>>> >> >>>>>
>>> >> >>>>> * Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:
>>> >> >>>>>
>>> >> >>>>> >Dear Nikos and GRASS users,
>>> >> >>>>> >
>>> >> >>>>> >I would like to ask if nonetheless the effect due to "stray light" the
>>> >> >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>>> >> >>>>> >data and whether these error is specially visible on water bodies? and
>>> >> >>>>> >whether band 10 is better than band 11 in terms of correction processing
>>> >> >>>>> >for Level -1  data products?
>>> >> >>>>> >
>>> >> >>>>> >Thanks a lot.
>>> >> >>>>> >
>>> >> >>>>> >Kind regards,
>>> >> >>>>> >Gabriel
>>> >> >>>>>
>>> >> >>>>> Dear Gabriel,
>>> >> >>>>>
>>> >> >>>>> for details and references, refer to
>>> >> >>>>>
>>> >> >>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/
>>> >> >>>>>
>>> >> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.
>>> >> >>>>>
>>> >> >>>>> I use `i.landsat8.swlst` and plan to improve it further.
>>> >> >>>>>
>>> >> >>>>> However, whether to prefer a Split-Window based approach, or another
>>> >> >>>>> Single-Channel one, depends on what you want to do. Think of spatial
>>> >> >>>>> extent and coverage of various land (cover) types, temporal extent
>>> >> >>>>> and more.
>>> >> >>>>>
>>> >> >>>>> Thermal remote sensing is hard(er) also because it's hard to get
>>> >> >>>>> ground-truth data sets so as to validate LST estimations.
>>> >> >>>>>
>>> >> >>>>> Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

NikosAlexandris
In reply to this post by Gabriel Cotlier
* Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:

>I would like to ask if nonetheless the effect due to "stray light" the
>*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>data and whether these error is specially visible on water bodies?

The implemented algorithm (Du, 2015) bases upon the generalized
split-window algorithm proposed by Wan (2014). The 'stray light' issue
is not dealt upfront with this approach.  The 'stray light' issue is
dealt with an algorithmic correction introduced in the Collection 1
products.  And, of course, there might be more questions that relate to
the quality and performance of the algorithm by Du.

Regarding "water bodies", I don't know.


>whether band 10 is better than band 11 in terms of correction processing
>for Level -1  data products?

Band 10 is the one selected for the single-channel based LST products
that span across all Landsat sensors. See: "Landsat Provisional Surface
Temperature (ST) Digital Object Identification (DOI):
doi.org/10.5066/F7J38RTH".  Band 11 is the one with large calibration
uncertainties.

A good reference is this publication:

Malakar, N. K., Hulley, G. C., Hook, S. J., Laraby, K., Cook, M., &
Schott, J. R. (2018). An Operational Land Surface Temperature Product
for Landsat Thermal Data: Methodology and Validation. IEEE Transactions
on Geoscience and Remote Sensing, (99), 1-19.
http://dx.doi.org/10.1109/TGRS.2018.2824828.

Nikos
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: question on Stray light Landsat 8 data

Gabriel Cotlier
Thanks a lot very good information and guidance.
Thanks
Gabriel

On Wed, Aug 21, 2019 at 3:31 AM Nikos Alexandris <[hidden email]> wrote:
* Gabriel Cotlier <[hidden email]> [2018-08-21 12:00:24 -0300]:

>I would like to ask if nonetheless the effect due to "stray light" the
>*i.landsat8.swlst* code for split window is still applicable to Landsat 8
>data and whether these error is specially visible on water bodies?

The implemented algorithm (Du, 2015) bases upon the generalized
split-window algorithm proposed by Wan (2014). The 'stray light' issue
is not dealt upfront with this approach.  The 'stray light' issue is
dealt with an algorithmic correction introduced in the Collection 1
products.  And, of course, there might be more questions that relate to
the quality and performance of the algorithm by Du.

Regarding "water bodies", I don't know.


>whether band 10 is better than band 11 in terms of correction processing
>for Level -1  data products?

Band 10 is the one selected for the single-channel based LST products
that span across all Landsat sensors. See: "Landsat Provisional Surface
Temperature (ST) Digital Object Identification (DOI):
doi.org/10.5066/F7J38RTH".  Band 11 is the one with large calibration
uncertainties.

A good reference is this publication:

Malakar, N. K., Hulley, G. C., Hook, S. J., Laraby, K., Cook, M., &
Schott, J. R. (2018). An Operational Land Surface Temperature Product
for Landsat Thermal Data: Methodology and Validation. IEEE Transactions
on Geoscience and Remote Sensing, (99), 1-19.
http://dx.doi.org/10.1109/TGRS.2018.2824828.

Nikos

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user