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

Tue Aug 20 12:24:27 PDT 2019

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabiklm01 at 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 at gmail.com>
wrote:
>>
>>
>>
>> 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/20190820/e0d67d9a/attachment.html>