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

Gabriel Cotlier gabiklm01 at gmail.com
Tue Aug 20 13:36:54 PDT 2019


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: image.png]

On Tue, Aug 20, 2019 at 5:34 PM Gabriel Cotlier <gabiklm01 at 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 at gmail.com>
> wrote:
>
>> Dear Gabriel,
>>
>> On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <gabiklm01 at 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 at 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 at gmail.com> wrote:
>> >>>
>> >>> 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/16cff5ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 56055 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20190820/16cff5ff/attachment-0001.png>


More information about the grass-user mailing list