[GRASS-user] question on Stray light Landsat 8 data

GRASS GRASS user
1

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

2

* Gabriel Cotlier <gabiklm01@gmail.com> [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

3

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 <nik@nikosalexandris.net> wrote:

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

4

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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

5

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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

6

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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

7

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

8

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 <markus.metz.giswork@gmail.com> wrote:

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

(attachments)

grass_cmd_output_all.txt (181 KB)

9

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

10

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 <markus.metz.giswork@gmail.com> wrote:

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

11

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 <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

12

Dear Gabriel,

On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

13

Dear Markus,
My grass version is : GRASS GIS 7.6.1

On Tue, Aug 20, 2019 at 5:13 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

Dear Gabriel,

On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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

14

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 <gabiklm01@gmail.com> wrote:

Dear Markus,
My grass version is : GRASS GIS 7.6.1

On Tue, Aug 20, 2019 at 5:13 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

Dear Gabriel,

On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <markus.metz.giswork@gmail.com> wrote:

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <gabiklm01@gmail.com> 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 <nik@nikosalexandris.net> wrote:

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