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 <gabikl...@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.gisw...@gmail.com> > wrote: > >> Dear Gabriel, >> >> On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <gabikl...@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 <gabikl...@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.gisw...@gmail.com> wrote: >> >>> >> >>> Dear Gabriel, >> >>> >> >>> On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <gabikl...@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.gisw...@gmail.com> wrote: >> >>> >> >> >>> >> >> >>> >> >> >>> >> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier < >> gabikl...@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 < >> gabikl...@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 < >> gabikl...@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 < >> gabikl...@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 < >> n...@nikosalexandris.net> wrote: >> >>> >> >>>>> >> >>> >> >>>>> * Gabriel Cotlier <gabikl...@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 >> >
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user