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

[Markus Metz]

On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabiklm01 at 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 at 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 at 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 at 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 at nikosalexandris.net> wrote:
>>>>>
>>>>> * Gabriel Cotlier <gabiklm01 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20190819/f066b57f/attachment.html>