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 <[email protected]> wrote: > Dear Gabriel, > > On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <[email protected]> > 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 < > [email protected]> wrote: > >> > >> > >> > >> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected]> 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 < > [email protected]> wrote: > >> >>>>> > >> >>>>> * Gabriel Cotlier <[email protected]> [2018-08-21 12:00:24 > -0300]: > >> >>>>> > >> >>>>> >Dear Nikos and GRASS users, > >> >>>>> > > >> >>>>> >I would like to ask if nonetheless the effect due to "stray > light" the > >> >>>>> >*i.landsat8.swlst* code for split window is still applicable to > Landsat 8 > >> >>>>> >data and whether these error is specially visible on water > bodies? and > >> >>>>> >whether band 10 is better than band 11 in terms of correction > processing > >> >>>>> >for Level -1 data products? > >> >>>>> > > >> >>>>> >Thanks a lot. > >> >>>>> > > >> >>>>> >Kind regards, > >> >>>>> >Gabriel > >> >>>>> > >> >>>>> Dear Gabriel, > >> >>>>> > >> >>>>> for details and references, refer to > >> >>>>> > >> >>>>> > https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/ > >> >>>>> > >> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 > products. > >> >>>>> > >> >>>>> I use `i.landsat8.swlst` and plan to improve it further. > >> >>>>> > >> >>>>> However, whether to prefer a Split-Window based approach, or > another > >> >>>>> Single-Channel one, depends on what you want to do. Think of > spatial > >> >>>>> extent and coverage of various land (cover) types, temporal extent > >> >>>>> and more. > >> >>>>> > >> >>>>> Thermal remote sensing is hard(er) also because it's hard to get > >> >>>>> ground-truth data sets so as to validate LST estimations. > >> >>>>> > >> >>>>> Nikos >
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
